| Message ID | 1491212673-13476-6-git-send-email-bhupinder.thakur@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | pl011 emulation support in Xen | expand |
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.
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
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.
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.
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.
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,
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
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,
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:
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(-)