[Xen-devel,05/10] xen/arm: vpl011: Allocate a new PFN in the toolstack for the virtual console

Message ID 1491212673-13476-6-git-send-email-bhupinder.thakur@linaro.org
State New
Headers show
Series
  • pl011 emulation support in Xen
Related show

Commit Message

Bhupinder Thakur April 3, 2017, 9:44 a.m.
1. Allocate a new pfn and pass on to Xen using a hvm call.

2. Change in xc_hvm_param_deprecated_check () to allow new vpl011 HVM params,
which are reusing some deprecated x86 HVM params.

Signed-off-by: Bhupinder Thakur <bhupinder.thakur@linaro.org>
---
 tools/libxc/include/xc_dom.h | 3 +++
 tools/libxc/xc_dom_arm.c     | 7 ++++++-
 tools/libxc/xc_dom_boot.c    | 3 +++
 tools/libxc/xc_domain.c      | 7 +++++++
 4 files changed, 19 insertions(+), 1 deletion(-)

Comments

Wei Liu April 12, 2017, 4:33 p.m. | #1
On Mon, Apr 03, 2017 at 03:14:28PM +0530, Bhupinder Thakur wrote:
> 1. Allocate a new pfn and pass on to Xen using a hvm call.
> 
> 2. Change in xc_hvm_param_deprecated_check () to allow new vpl011 HVM params,
> which are reusing some deprecated x86 HVM params.
> 
> Signed-off-by: Bhupinder Thakur <bhupinder.thakur@linaro.org>
> ---
>  tools/libxc/include/xc_dom.h | 3 +++
>  tools/libxc/xc_dom_arm.c     | 7 ++++++-
>  tools/libxc/xc_dom_boot.c    | 3 +++
>  tools/libxc/xc_domain.c      | 7 +++++++
>  4 files changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index 608cbc2..c93d98c 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -218,6 +218,9 @@ struct xc_dom_image {
>  
>      /* Extra SMBIOS structures passed to HVMLOADER */
>      struct xc_hvm_firmware_module smbios_module;
> +
> +	/* Virtual console pfn. */
> +    xen_pfn_t vconsole_pfn;
>  };
>  
>  /* --- pluggable kernel loader ------------------------------------- */
> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> index a7e839e..157381e 100644
> --- a/tools/libxc/xc_dom_arm.c
> +++ b/tools/libxc/xc_dom_arm.c
> @@ -26,10 +26,11 @@
>  #include "xg_private.h"
>  #include "xc_dom.h"
>  
> -#define NR_MAGIC_PAGES 3
> +#define NR_MAGIC_PAGES 4
>  #define CONSOLE_PFN_OFFSET 0
>  #define XENSTORE_PFN_OFFSET 1
>  #define MEMACCESS_PFN_OFFSET 2
> +#define VCONSOLE_PFN_OFFSET 3
>  
>  #define LPAE_SHIFT 9
>  
> @@ -85,6 +86,7 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
>  
>      dom->console_pfn = base + CONSOLE_PFN_OFFSET;
>      dom->xenstore_pfn = base + XENSTORE_PFN_OFFSET;
> +    dom->vconsole_pfn = base + VCONSOLE_PFN_OFFSET;
>  
>      xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn);
>      xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn);
> @@ -95,6 +97,9 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
>              dom->xenstore_pfn);
>      xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_MONITOR_RING_PFN,
>              base + MEMACCESS_PFN_OFFSET);
> +    xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_VCONSOLE_PFN,
> +                     base + VCONSOLE_PFN_OFFSET);
> +

Here is something I don't quite understand (sorry I haven't been
following the conversation closely): if pl011 is emulated, why would the
guest need to know its PFN?

Wei.
Bhupinder Thakur April 13, 2017, 8:37 a.m. | #2
Hi Wei,


>>  /* --- pluggable kernel loader ------------------------------------- */
>> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
>> index a7e839e..157381e 100644
>> --- a/tools/libxc/xc_dom_arm.c
>> +++ b/tools/libxc/xc_dom_arm.c
>> @@ -26,10 +26,11 @@
>>  #include "xg_private.h"
>>  #include "xc_dom.h"
>>
>> -#define NR_MAGIC_PAGES 3
>> +#define NR_MAGIC_PAGES 4
>>  #define CONSOLE_PFN_OFFSET 0
>>  #define XENSTORE_PFN_OFFSET 1
>>  #define MEMACCESS_PFN_OFFSET 2
>> +#define VCONSOLE_PFN_OFFSET 3
>>
>>  #define LPAE_SHIFT 9
>>
>> @@ -85,6 +86,7 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
>>
>>      dom->console_pfn = base + CONSOLE_PFN_OFFSET;
>>      dom->xenstore_pfn = base + XENSTORE_PFN_OFFSET;
>> +    dom->vconsole_pfn = base + VCONSOLE_PFN_OFFSET;
>>
>>      xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn);
>>      xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn);
>> @@ -95,6 +97,9 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
>>              dom->xenstore_pfn);
>>      xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_MONITOR_RING_PFN,
>>              base + MEMACCESS_PFN_OFFSET);
>> +    xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_VCONSOLE_PFN,
>> +                     base + VCONSOLE_PFN_OFFSET);
>> +
>
> Here is something I don't quite understand (sorry I haven't been
> following the conversation closely): if pl011 is emulated, why would the
> guest need to know its PFN?

This PFN is used by Xen to setup a ring-buffer between xenconsole and itself.
Xen reads/writes data from/to this ring buffer when it gets a mmio
read/write request from the guest.

Here using the hvm call, we are passing the PFN to Xen so that it can
setup the ring buffers.

Regards,
Bhupinder
Wei Liu April 13, 2017, 8:53 a.m. | #3
On Thu, Apr 13, 2017 at 02:07:54PM +0530, Bhupinder Thakur wrote:
> Hi Wei,
> 
> 
> >>  /* --- pluggable kernel loader ------------------------------------- */
> >> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> >> index a7e839e..157381e 100644
> >> --- a/tools/libxc/xc_dom_arm.c
> >> +++ b/tools/libxc/xc_dom_arm.c
> >> @@ -26,10 +26,11 @@
> >>  #include "xg_private.h"
> >>  #include "xc_dom.h"
> >>
> >> -#define NR_MAGIC_PAGES 3
> >> +#define NR_MAGIC_PAGES 4
> >>  #define CONSOLE_PFN_OFFSET 0
> >>  #define XENSTORE_PFN_OFFSET 1
> >>  #define MEMACCESS_PFN_OFFSET 2
> >> +#define VCONSOLE_PFN_OFFSET 3
> >>
> >>  #define LPAE_SHIFT 9
> >>
> >> @@ -85,6 +86,7 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
> >>
> >>      dom->console_pfn = base + CONSOLE_PFN_OFFSET;
> >>      dom->xenstore_pfn = base + XENSTORE_PFN_OFFSET;
> >> +    dom->vconsole_pfn = base + VCONSOLE_PFN_OFFSET;
> >>
> >>      xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn);
> >>      xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn);
> >> @@ -95,6 +97,9 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
> >>              dom->xenstore_pfn);
> >>      xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_MONITOR_RING_PFN,
> >>              base + MEMACCESS_PFN_OFFSET);
> >> +    xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_VCONSOLE_PFN,
> >> +                     base + VCONSOLE_PFN_OFFSET);
> >> +
> >
> > Here is something I don't quite understand (sorry I haven't been
> > following the conversation closely): if pl011 is emulated, why would the
> > guest need to know its PFN?
> 
> This PFN is used by Xen to setup a ring-buffer between xenconsole and itself.
> Xen reads/writes data from/to this ring buffer when it gets a mmio
> read/write request from the guest.
> 

What I was getting at was "does the *guest* need to know the PFN"?  The
hypervisor and xenconsole daemon / client aren't the guest. Does the
guest need to know the exact PFN in order to setup MMIO?

Ultimately this is going to be decided by ARM maintainers. I'm just
curious about why it is done like this.

Wei.
Stefano Stabellini April 19, 2017, 12:36 a.m. | #4
On Thu, 13 Apr 2017, Wei Liu wrote:
> On Thu, Apr 13, 2017 at 02:07:54PM +0530, Bhupinder Thakur wrote:
> > Hi Wei,
> > 
> > 
> > >>  /* --- pluggable kernel loader ------------------------------------- */
> > >> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> > >> index a7e839e..157381e 100644
> > >> --- a/tools/libxc/xc_dom_arm.c
> > >> +++ b/tools/libxc/xc_dom_arm.c
> > >> @@ -26,10 +26,11 @@
> > >>  #include "xg_private.h"
> > >>  #include "xc_dom.h"
> > >>
> > >> -#define NR_MAGIC_PAGES 3
> > >> +#define NR_MAGIC_PAGES 4
> > >>  #define CONSOLE_PFN_OFFSET 0
> > >>  #define XENSTORE_PFN_OFFSET 1
> > >>  #define MEMACCESS_PFN_OFFSET 2
> > >> +#define VCONSOLE_PFN_OFFSET 3
> > >>
> > >>  #define LPAE_SHIFT 9
> > >>
> > >> @@ -85,6 +86,7 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
> > >>
> > >>      dom->console_pfn = base + CONSOLE_PFN_OFFSET;
> > >>      dom->xenstore_pfn = base + XENSTORE_PFN_OFFSET;
> > >> +    dom->vconsole_pfn = base + VCONSOLE_PFN_OFFSET;
> > >>
> > >>      xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn);
> > >>      xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn);
> > >> @@ -95,6 +97,9 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
> > >>              dom->xenstore_pfn);
> > >>      xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_MONITOR_RING_PFN,
> > >>              base + MEMACCESS_PFN_OFFSET);
> > >> +    xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_VCONSOLE_PFN,
> > >> +                     base + VCONSOLE_PFN_OFFSET);
> > >> +
> > >
> > > Here is something I don't quite understand (sorry I haven't been
> > > following the conversation closely): if pl011 is emulated, why would the
> > > guest need to know its PFN?
> > 
> > This PFN is used by Xen to setup a ring-buffer between xenconsole and itself.
> > Xen reads/writes data from/to this ring buffer when it gets a mmio
> > read/write request from the guest.
> > 
> 
> What I was getting at was "does the *guest* need to know the PFN"?  The
> hypervisor and xenconsole daemon / client aren't the guest. Does the
> guest need to know the exact PFN in order to setup MMIO?
> 
> Ultimately this is going to be decided by ARM maintainers. I'm just
> curious about why it is done like this.

hvm_params are commonly used to pass parameters from Xen or from libxl
to guests. In this case, they are used to pass parameters from the
toolstack to Xen.

The guest does not need to know the pfn, and in fact it cannot: Xen
refuses to return the value of HVM_PARAM_VCONSOLE_PFN to guests (see
patch #2).

Honestly, I don't particularly care about how the pfn is passed from
libxc to Xen. hvm_param is an option, or we could introduce a new
domctl.
Wei Liu April 19, 2017, 10:28 a.m. | #5
On Tue, Apr 18, 2017 at 05:36:41PM -0700, Stefano Stabellini wrote:
> On Thu, 13 Apr 2017, Wei Liu wrote:
> > On Thu, Apr 13, 2017 at 02:07:54PM +0530, Bhupinder Thakur wrote:
> > > Hi Wei,
> > > 
> > > 
> > > >>  /* --- pluggable kernel loader ------------------------------------- */
> > > >> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> > > >> index a7e839e..157381e 100644
> > > >> --- a/tools/libxc/xc_dom_arm.c
> > > >> +++ b/tools/libxc/xc_dom_arm.c
> > > >> @@ -26,10 +26,11 @@
> > > >>  #include "xg_private.h"
> > > >>  #include "xc_dom.h"
> > > >>
> > > >> -#define NR_MAGIC_PAGES 3
> > > >> +#define NR_MAGIC_PAGES 4
> > > >>  #define CONSOLE_PFN_OFFSET 0
> > > >>  #define XENSTORE_PFN_OFFSET 1
> > > >>  #define MEMACCESS_PFN_OFFSET 2
> > > >> +#define VCONSOLE_PFN_OFFSET 3
> > > >>
> > > >>  #define LPAE_SHIFT 9
> > > >>
> > > >> @@ -85,6 +86,7 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
> > > >>
> > > >>      dom->console_pfn = base + CONSOLE_PFN_OFFSET;
> > > >>      dom->xenstore_pfn = base + XENSTORE_PFN_OFFSET;
> > > >> +    dom->vconsole_pfn = base + VCONSOLE_PFN_OFFSET;
> > > >>
> > > >>      xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn);
> > > >>      xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn);
> > > >> @@ -95,6 +97,9 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
> > > >>              dom->xenstore_pfn);
> > > >>      xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_MONITOR_RING_PFN,
> > > >>              base + MEMACCESS_PFN_OFFSET);
> > > >> +    xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_VCONSOLE_PFN,
> > > >> +                     base + VCONSOLE_PFN_OFFSET);
> > > >> +
> > > >
> > > > Here is something I don't quite understand (sorry I haven't been
> > > > following the conversation closely): if pl011 is emulated, why would the
> > > > guest need to know its PFN?
> > > 
> > > This PFN is used by Xen to setup a ring-buffer between xenconsole and itself.
> > > Xen reads/writes data from/to this ring buffer when it gets a mmio
> > > read/write request from the guest.
> > > 
> > 
> > What I was getting at was "does the *guest* need to know the PFN"?  The
> > hypervisor and xenconsole daemon / client aren't the guest. Does the
> > guest need to know the exact PFN in order to setup MMIO?
> > 
> > Ultimately this is going to be decided by ARM maintainers. I'm just
> > curious about why it is done like this.
> 
> hvm_params are commonly used to pass parameters from Xen or from libxl
> to guests. In this case, they are used to pass parameters from the
> toolstack to Xen.
> 
> The guest does not need to know the pfn, and in fact it cannot: Xen
> refuses to return the value of HVM_PARAM_VCONSOLE_PFN to guests (see
> patch #2).
> 

Ah, I missed the new restriction in #2.

> Honestly, I don't particularly care about how the pfn is passed from
> libxc to Xen. hvm_param is an option, or we could introduce a new
> domctl.

No opinion from me either. I think using HVM params is fine.
Julien Grall April 19, 2017, 11:01 a.m. | #6
Hi,

On 19/04/17 11:28, Wei Liu wrote:
> On Tue, Apr 18, 2017 at 05:36:41PM -0700, Stefano Stabellini wrote:
>> On Thu, 13 Apr 2017, Wei Liu wrote:
>>> On Thu, Apr 13, 2017 at 02:07:54PM +0530, Bhupinder Thakur wrote:
>>>> Hi Wei,
>>>>
>>>>
>>>>>>  /* --- pluggable kernel loader ------------------------------------- */
>>>>>> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
>>>>>> index a7e839e..157381e 100644
>>>>>> --- a/tools/libxc/xc_dom_arm.c
>>>>>> +++ b/tools/libxc/xc_dom_arm.c
>>>>>> @@ -26,10 +26,11 @@
>>>>>>  #include "xg_private.h"
>>>>>>  #include "xc_dom.h"
>>>>>>
>>>>>> -#define NR_MAGIC_PAGES 3
>>>>>> +#define NR_MAGIC_PAGES 4
>>>>>>  #define CONSOLE_PFN_OFFSET 0
>>>>>>  #define XENSTORE_PFN_OFFSET 1
>>>>>>  #define MEMACCESS_PFN_OFFSET 2
>>>>>> +#define VCONSOLE_PFN_OFFSET 3
>>>>>>
>>>>>>  #define LPAE_SHIFT 9
>>>>>>
>>>>>> @@ -85,6 +86,7 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
>>>>>>
>>>>>>      dom->console_pfn = base + CONSOLE_PFN_OFFSET;
>>>>>>      dom->xenstore_pfn = base + XENSTORE_PFN_OFFSET;
>>>>>> +    dom->vconsole_pfn = base + VCONSOLE_PFN_OFFSET;
>>>>>>
>>>>>>      xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn);
>>>>>>      xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn);
>>>>>> @@ -95,6 +97,9 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
>>>>>>              dom->xenstore_pfn);
>>>>>>      xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_MONITOR_RING_PFN,
>>>>>>              base + MEMACCESS_PFN_OFFSET);
>>>>>> +    xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_VCONSOLE_PFN,
>>>>>> +                     base + VCONSOLE_PFN_OFFSET);
>>>>>> +
>>>>>
>>>>> Here is something I don't quite understand (sorry I haven't been
>>>>> following the conversation closely): if pl011 is emulated, why would the
>>>>> guest need to know its PFN?
>>>>
>>>> This PFN is used by Xen to setup a ring-buffer between xenconsole and itself.
>>>> Xen reads/writes data from/to this ring buffer when it gets a mmio
>>>> read/write request from the guest.
>>>>
>>>
>>> What I was getting at was "does the *guest* need to know the PFN"?  The
>>> hypervisor and xenconsole daemon / client aren't the guest. Does the
>>> guest need to know the exact PFN in order to setup MMIO?
>>>
>>> Ultimately this is going to be decided by ARM maintainers. I'm just
>>> curious about why it is done like this.
>>
>> hvm_params are commonly used to pass parameters from Xen or from libxl
>> to guests. In this case, they are used to pass parameters from the
>> toolstack to Xen.
>>
>> The guest does not need to know the pfn, and in fact it cannot: Xen
>> refuses to return the value of HVM_PARAM_VCONSOLE_PFN to guests (see
>> patch #2).
>>
>
> Ah, I missed the new restriction in #2.
>
>> Honestly, I don't particularly care about how the pfn is passed from
>> libxc to Xen. hvm_param is an option, or we could introduce a new
>> domctl.
>
> No opinion from me either. I think using HVM params is fine.

There were some concerns on the first version about using HVM params 
because this is tying the virtual UART to HVM and only allow us to have 
one virtual console.

HVM params are part of the stable ABI, so this would restrict ourselves 
to future extension.

It was suggested to look at the DOMCTL way, I would have expected to 
some investigation and a summary in the cover letter. So why do we keep 
HVM PARAM?

Cheers,
Bhupinder Thakur April 19, 2017, 1:05 p.m. | #7
Hi,

On 19 April 2017 at 16:31, Julien Grall <julien.grall@arm.com> wrote:
> There were some concerns on the first version about using HVM params because
> this is tying the virtual UART to HVM and only allow us to have one virtual
> console.
>
> HVM params are part of the stable ABI, so this would restrict ourselves to
> future extension.
>
> It was suggested to look at the DOMCTL way, I would have expected to some
> investigation and a summary in the cover letter. So why do we keep HVM
> PARAM?

It is more flexible to use DOMCTL interface in terms of supporting
multiple vUARTs in future without changing the interface. This DOMCTL
interface cannot be called from xenconsoled though because xenconsoled
does not know the PFN to be passed to Xen. It is ok to call this
DOMCTL interface from the toolstack since it knows the PFN and can
pass it on to Xen.

Regards,
Bhupinder
Julien Grall April 19, 2017, 1:35 p.m. | #8
On 19/04/17 14:05, Bhupinder Thakur wrote:
> Hi,

Hi Bhupinder,

> On 19 April 2017 at 16:31, Julien Grall <julien.grall@arm.com> wrote:
>> There were some concerns on the first version about using HVM params because
>> this is tying the virtual UART to HVM and only allow us to have one virtual
>> console.
>>
>> HVM params are part of the stable ABI, so this would restrict ourselves to
>> future extension.
>>
>> It was suggested to look at the DOMCTL way, I would have expected to some
>> investigation and a summary in the cover letter. So why do we keep HVM
>> PARAM?
>
> It is more flexible to use DOMCTL interface in terms of supporting
> multiple vUARTs in future without changing the interface. This DOMCTL
> interface cannot be called from xenconsoled though because xenconsoled
> does not know the PFN to be passed to Xen. It is ok to call this
> DOMCTL interface from the toolstack since it knows the PFN and can
> pass it on to Xen.

I am not sure to understand what you mean. The DOMCTL could be used to 
set the PFN by the toolstack and then retrieved by the console.

You could also use xenstore to pass the PFN. So what is the problem?

Cheers,

Patch hide | download patch | download mbox

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 608cbc2..c93d98c 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -218,6 +218,9 @@  struct xc_dom_image {
 
     /* Extra SMBIOS structures passed to HVMLOADER */
     struct xc_hvm_firmware_module smbios_module;
+
+	/* Virtual console pfn. */
+    xen_pfn_t vconsole_pfn;
 };
 
 /* --- pluggable kernel loader ------------------------------------- */
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index a7e839e..157381e 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -26,10 +26,11 @@ 
 #include "xg_private.h"
 #include "xc_dom.h"
 
-#define NR_MAGIC_PAGES 3
+#define NR_MAGIC_PAGES 4
 #define CONSOLE_PFN_OFFSET 0
 #define XENSTORE_PFN_OFFSET 1
 #define MEMACCESS_PFN_OFFSET 2
+#define VCONSOLE_PFN_OFFSET 3
 
 #define LPAE_SHIFT 9
 
@@ -85,6 +86,7 @@  static int alloc_magic_pages(struct xc_dom_image *dom)
 
     dom->console_pfn = base + CONSOLE_PFN_OFFSET;
     dom->xenstore_pfn = base + XENSTORE_PFN_OFFSET;
+    dom->vconsole_pfn = base + VCONSOLE_PFN_OFFSET;
 
     xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn);
     xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn);
@@ -95,6 +97,9 @@  static int alloc_magic_pages(struct xc_dom_image *dom)
             dom->xenstore_pfn);
     xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_MONITOR_RING_PFN,
             base + MEMACCESS_PFN_OFFSET);
+    xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_VCONSOLE_PFN,
+                     base + VCONSOLE_PFN_OFFSET);
+
     /* allocated by toolstack */
     xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_EVTCHN,
             dom->console_evtchn);
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 791041b..ec91b15 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -227,6 +227,9 @@  int xc_dom_boot_image(struct xc_dom_image *dom)
     if ( (rc = clear_page(dom, dom->xenstore_pfn)) != 0 )
         return rc;
 
+    if ( (rc = clear_page(dom, dom->vconsole_pfn)) != 0 )
+        return rc;
+
     /* start info page */
     if ( dom->arch_hooks->start_info )
         dom->arch_hooks->start_info(dom);
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index fa1daeb..8ac7d4f 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1337,9 +1337,16 @@  static inline int xc_hvm_param_deprecated_check(uint32_t param)
 {
     switch ( param )
     {
+        /*
+         * For Aarch64 the following three parameters are reused and hence this
+         * empty check to avoid returning an error.
+         */
+#if defined (__arm__) || defined(__aarch64__)
+#else
         case HVM_PARAM_MEMORY_EVENT_CR0:
         case HVM_PARAM_MEMORY_EVENT_CR3:
         case HVM_PARAM_MEMORY_EVENT_CR4:
+#endif
         case HVM_PARAM_MEMORY_EVENT_INT3:
         case HVM_PARAM_MEMORY_EVENT_SINGLE_STEP:
         case HVM_PARAM_MEMORY_EVENT_MSR: