Re: [Xen-devel] [PATCH] VMX: use non-atomic bitops to manage MSR state
> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Monday, June 20, 2016 7:31 PM > > All host_msr_state accesses are solely on the owning CPU, and all > guest_msr_state ones solely when the vCPU is current or being switched > to. This, btw, is also in line with the use of find_first_set_bit() > (which would be bogus if ->flags could get updated behind its back). > > Signed-off-by: Jan Beulich > Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.
On 6/22/2016 7:33 PM, George Dunlap wrote: On 22/06/16 11:07, Yu Zhang wrote: On 6/22/2016 5:47 PM, George Dunlap wrote: On 22/06/16 10:29, Jan Beulich wrote: On 22.06.16 at 11:16, wrote: On 22/06/16 07:39, Jan Beulich wrote: On 21.06.16 at 16:38, wrote: On 21/06/16 10:47, Jan Beulich wrote: And then - didn't we mean to disable that part of XenGT during migration, i.e. temporarily accept the higher performance overhead without the p2m_ioreq_server entries? In which case flipping everything back to p2m_ram_rw after (completed or canceled) migration would be exactly what we want. The (new or previous) ioreq server should attach only afterwards, and can then freely re-establish any p2m_ioreq_server entries it deems necessary. Well, I agree this part of XenGT should be disabled during migration. But in such case I think it's device model's job to trigger the p2m type flipping(i.e. by calling HVMOP_set_mem_type). I agree - this would seem to be the simpler model here, despite (as George validly says) the more consistent model would be for the hypervisor to do the cleanup. Such cleanup would imo be reasonable only if there was an easy way for the hypervisor to enumerate all p2m_ioreq_server pages. Well, for me, the "easy way" means we should avoid traversing the whole ept paging structure all at once, right? Yes. Does calling p2m_change_entry_type_global() not satisfy this requirement? Not really - that addresses the "low overhead" aspect, but not the "enumerate all such entries" one. I'm sorry, I think I'm missing something here. What do we need the enumeration for? We'd need that if we were to do the cleanup in the hypervisor (as we can't rely on all p2m entry re-calculation to have happened by the time a new ioreq server registers for the type). So you're afraid of this sequence of events? 1) Server A de-registered, triggering a ioreq_server -> ram_rw type change 2) gfn N is marked as misconfigured 3) Server B registers and marks gfn N as ioreq_server 4) When N is accessed, the misconfiguration is resolved incorrectly to ram_rw But that can't happen, because misconfigured entries are resolved before setting a p2m entry; so at step 3, gfn N will be first set to (non-misconfigured) ram_rw, then changed to (non-misconfigured) ioreq_server. Or is there another sequence of events that I'm missing? Thanks for your reply, George. :) If no log dirty is triggered during this process, your sequence is correct. However, if log dirty is triggered, we'll met problems. I have described this in previous mails : http://lists.xenproject.org/archives/html/xen-devel/2016-06/msg02426.html on Jun 20 and http://lists.xenproject.org/archives/html/xen-devel/2016-06/msg02575.html on Jun 21 Right -- sorry, now I see the issue: 1. Server A marks gfn X as ioreq_server 2. Server A deregisters, gfn X misconfigured 3. Server B registers, marks gfn Y as ioreq_server 4. Logdirty mode enabled; gfn Y misconfigured 5. When X or Y are accessed, resolve_misconfigure() has no way of telling whether the entry is from server A (which should be set to logdirty) or from server B (which should be left as ioreq_server). Exactly. :) Another simpler scenario would be 1. Server A marks gfn X as p2m_ioreq_server; 2. Logdirty mode enabled; gfn X misconfigured; 3. When X is written, it will not cause ept vioalation, but ept misconfig, and the resolve_misconfig() would set gfn X back to p2m_ram_rw, thereafter we can not track access to X; Note: Not resetting the p2m type for p2m_ioreq_server when p2m->ioreq_server is not NULL is suitable for this simpler scenario, but is not correct if take your scenario into account. The core reason is I could not find a simple solution in resolve_misconfig() to handle handle both the outdated p2m_ioreq_server entries, the in-use ones and to support the logdirty feature at the same time. In a sense this is a deficiency in the change_entry_type_global() interface. A common OS principle is "make the common case fast, and the uncommon case correct". The scenario described above seems to me to be an uncommon case which is handled quickly but incorrectly; ideally we should handle it correctly, even if it's not very quick. Synchronously resolving a previous misconfig is probably the most straightforward thing to do. It could be done at point #3, when an M->N type change is not complete and a new p2m entry of type M is written; it could be at point #4, when an N->O type change is initiated while an M->N type change hasn't completed. Or it could be when an N->O type change happens while there are unfinished M->N transitions *and* post-type-change M entries. Sorry, I did not quite get it. Could you please elaborate more? Thanks! :) But, that's a lot of somewhat complicated work for a scenario that is unlikely to happen in practice, and I can see why Yu Zhang would feel reluctant to do it. Yes, that's part of my reasons. :) For the time being though, this will fail at #4,
Re: [Xen-devel] [PATCH] VMX: ensure MSR index enum and array remain in sync
> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Monday, June 20, 2016 7:32 PM > > ... by using dedicated initializers. Also add an ASSERT() to make sure > unintentional addition of holes to the array gets noticed. Ditch > MSR_INDEX_SIZE as redundant with VMX_MSR_COUNT. > > Signed-off-by: Jan Beulich Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 96148: regressions - FAIL
flight 96148 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/96148/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 94748 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 94748 version targeted for testing: ovmf 3460c75dfe951c50d1d16eb2bb54b4790d49a91d baseline version: ovmf dc99315b8732b6e3032d01319d3f534d440b43d0 Last test of basis94748 2016-05-24 22:43:25 Z 29 days Failing since 94750 2016-05-25 03:43:08 Z 29 days 52 attempts Testing same since96148 2016-06-22 21:44:07 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Chao Zhang Cinnamon Shia Cohen, Eugene Dandan Bi Darbin Reyes Eric Dong Eugene Cohen Evan Lloyd Fu Siyuan Fu, Siyuan Gary Li Gary Lin Giri P Mudusuru Hao Wu Hegde Nagaraj P hegdenag Heyi Guo Jan D?bro? Jan Dabros Jeff Fan Jiaxin Wu Jiewen Yao Katie Dellaquila Laszlo Ersek Liming Gao Lu, ShifeiX A lushifex Marcin Wojtas Marvin H?user Marvin Haeuser Maurice Ma Michael Zimmermann Qiu Shumin Ruiyu Ni Ryan Harkin Sami Mujawar Satya Yarlagadda Sriram Subramanian Star Zeng Tapan Shah Thomas Palmer Yonghong Zhu Zhang, Chao B jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 2751 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"
>>> On 22.06.16 at 20:24, wrote:
> On 06/22/2016 11:23 AM, Jan Beulich wrote:
> On 22.06.16 at 16:13, wrote:
>>> On Wed, Jun 22, 2016 at 07:50:09AM -0600, Jan Beulich wrote:
>>> On 22.06.16 at 15:03, wrote:
> I've finally found what was causing long standing issue of not working
> PCI passthrough for HVM domains with qemu in stubdomain (only - without
> the other one in dom0). It looks to be this patch:
>
>>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=c428c9f162895cb3473f
>>>
> ab26d23ffbf41a6f293d;hp=dcccaf806a92eabb95929a67c344ac1e9ead6257
>
> It calls xc_domain_getinfo from xc_domain_memory_mapping (to check if
> the target domain is auto-translated), but xc_domain_getinfo fails with
> EPERM in stubdomain.
>
> What would be the best solution for this? Allowing xc_domain_getinfo
> from stubdomain in xen/include/xsm/dummy.h? Currently it is uses policy
> XSM_XS_PRIV in unstable and just XSM_PRIV in 4.6 - so, maybe have some
> combination of XSM_XS_PRIV and XSM_DM_PRIV? Or maybe fix this by
> removing xc_domain_getinfo call in xc_domain_memory_mapping, possibly
> implementing the logic from that commit solely in libxl?
Once we fixed the quirky behavior of the current implementation
(allowing information to be returned for other than the requested
domain), I see no reason why this couldn't become XSM_DM_PRIV.
>>>
>>> Can you explain this more? Is this fix backported to 4.6 and/or 4.4?
>>
>> Which fix? I talked of one to be made.
>>
But let's ask Daniel explicitly. And in that context I then also wonder
whether the xsm_getdomaininfo() invocation shouldn't be limited to
the respective sysctl.
>>>
>>> Actually getdomaininfo is handled in two places in xsm/dummy.h:
>>> - xsm_getdomaininfo (which does nothing when XSM is disabled)
>>> - xsm_domctl (which enforce actual policy)
>>>
>>> Also reading commit message of XSM_XS_PRIV introduction, it may be
>>> useful to be able to just check if given domain is alive, without
>>> getting all the information returned by XEN_DOMCTL_getdomaininfo. I find
>>> this useful also for any other inter-domain communication (for example
>>> libxenvchan connection).
>>>
>>> But for now, XEN_DOMCTL_getdomaininfo should be allowed either when
>>> device-model domain is asking about its target domain, or calling domain
>>> is xenstore domain/privileged domain. Right?
>>
>> Yes, that's what I think too.
>>
>>> How to combine those
>>> types? Change XSM_XS_PRIV to XSM_XS_DM_PRIV (it looks like the only
>>> usage of XSM_XS_PRIV)?
>
> Changing the definition of XSM_XS_PRIV seems like the best solution, since
> this is the only use. I don't think it matters if the constant is renamed
> to XSM_XS_DM_PRIV or not. In fact, since the constant isn't ever used by a
> caller, it could be removed and the actual logic placed in the switch
> statement - that way it's clear this is a special case for getdomaininfo
> instead of attempting to make this generic.
>
> Either method works, and I agree allowing DM to invoke this domctl is both
> useful and not going to introduce problems. The getdomaininfo permission
> will also need to be added to the device_model macro in xen.if.
What exactly this last sentence means I need to add I'm not sure
about. Apart from that, how about the change below?
Jan
domctl: relax getdomaininfo permissions
Qemu needs access to this for the domain it controls, both due to it
being used by xc_domain_memory_mapping() (which qemu calls) and the
explicit use in hw/xenpv/xen_domainbuild.c:xen_domain_poll().
This at once avoids a for_each_domain() loop when the ID of an
existing domain gets passed in.
Reported-by: Marek Marczykowski-Górecki
---
I wonder what good the duplication of the returned domain ID does: I'm
tempted to remove the one in the command-specific structure. Does
anyone have insight into why it was done that way?
I further wonder why we have XSM_OTHER: The respective conversion into
other XSM_* values in xsm/dummy.h could as well move into the callers,
making intentions more obvious when looking at the actual code.
--- unstable.orig/xen/common/domctl.c
+++ unstable/xen/common/domctl.c
@@ -442,14 +442,13 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
switch ( op->cmd )
{
case XEN_DOMCTL_createdomain:
-case XEN_DOMCTL_getdomaininfo:
case XEN_DOMCTL_test_assign_device:
case XEN_DOMCTL_gdbsx_guestmemio:
d = NULL;
break;
default:
d = rcu_lock_domain_by_id(op->domain);
-if ( d == NULL )
+if ( !d && op->cmd != XEN_DOMCTL_getdomaininfo )
return -ESRCH;
}
@@ -863,14 +862,22 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
case XEN_DOMCTL_getdomaininfo:
{
-domid_t dom = op->domain;
-
-rcu_read_lock(&domlist_read_lock);
+domid_t dom = DOMID_INVALID;
-for_each_domain ( d )
-if ( d->domain_id >
Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"
>>> On 23.06.16 at 10:32, wrote:
On 22.06.16 at 20:24, wrote:
>> Either method works, and I agree allowing DM to invoke this domctl is both
>> useful and not going to introduce problems. The getdomaininfo permission
>> will also need to be added to the device_model macro in xen.if.
>
> What exactly this last sentence means I need to add I'm not sure
> about.
Perhaps this?
--- unstable.orig/tools/flask/policy/policy/modules/xen/xen.if
+++ unstable/tools/flask/policy/policy/modules/xen/xen.if
@@ -148,7 +148,7 @@ define(`device_model', `
create_channel($2, $1, $2_channel)
allow $1 $2_channel:event create;
- allow $1 $2_target:domain shutdown;
+ allow $1 $2_target:domain { getdomaininfo shutdown };
allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack
};
allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl
irqlevel pciroute pcilevel cacheattr send_irq };
')
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"
On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote:
> >>> On 22.06.16 at 20:24, wrote:
> > On 06/22/2016 11:23 AM, Jan Beulich wrote:
> > On 22.06.16 at 16:13, wrote:
> >>> On Wed, Jun 22, 2016 at 07:50:09AM -0600, Jan Beulich wrote:
> >>> On 22.06.16 at 15:03, wrote:
> > I've finally found what was causing long standing issue of not working
> > PCI passthrough for HVM domains with qemu in stubdomain (only - without
> > the other one in dom0). It looks to be this patch:
> >
> >>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=c428c9f162895cb3473f
> >>>
> > ab26d23ffbf41a6f293d;hp=dcccaf806a92eabb95929a67c344ac1e9ead6257
> >
> > It calls xc_domain_getinfo from xc_domain_memory_mapping (to check if
> > the target domain is auto-translated), but xc_domain_getinfo fails with
> > EPERM in stubdomain.
> >
> > What would be the best solution for this? Allowing xc_domain_getinfo
> > from stubdomain in xen/include/xsm/dummy.h? Currently it is uses policy
> > XSM_XS_PRIV in unstable and just XSM_PRIV in 4.6 - so, maybe have some
> > combination of XSM_XS_PRIV and XSM_DM_PRIV? Or maybe fix this by
> > removing xc_domain_getinfo call in xc_domain_memory_mapping, possibly
> > implementing the logic from that commit solely in libxl?
>
> Once we fixed the quirky behavior of the current implementation
> (allowing information to be returned for other than the requested
> domain), I see no reason why this couldn't become XSM_DM_PRIV.
> >>>
> >>> Can you explain this more? Is this fix backported to 4.6 and/or 4.4?
> >>
> >> Which fix? I talked of one to be made.
> >>
> But let's ask Daniel explicitly. And in that context I then also wonder
> whether the xsm_getdomaininfo() invocation shouldn't be limited to
> the respective sysctl.
> >>>
> >>> Actually getdomaininfo is handled in two places in xsm/dummy.h:
> >>> - xsm_getdomaininfo (which does nothing when XSM is disabled)
> >>> - xsm_domctl (which enforce actual policy)
> >>>
> >>> Also reading commit message of XSM_XS_PRIV introduction, it may be
> >>> useful to be able to just check if given domain is alive, without
> >>> getting all the information returned by XEN_DOMCTL_getdomaininfo. I find
> >>> this useful also for any other inter-domain communication (for example
> >>> libxenvchan connection).
> >>>
> >>> But for now, XEN_DOMCTL_getdomaininfo should be allowed either when
> >>> device-model domain is asking about its target domain, or calling domain
> >>> is xenstore domain/privileged domain. Right?
> >>
> >> Yes, that's what I think too.
> >>
> >>> How to combine those
> >>> types? Change XSM_XS_PRIV to XSM_XS_DM_PRIV (it looks like the only
> >>> usage of XSM_XS_PRIV)?
> >
> > Changing the definition of XSM_XS_PRIV seems like the best solution, since
> > this is the only use. I don't think it matters if the constant is renamed
> > to XSM_XS_DM_PRIV or not. In fact, since the constant isn't ever used by a
> > caller, it could be removed and the actual logic placed in the switch
> > statement - that way it's clear this is a special case for getdomaininfo
> > instead of attempting to make this generic.
> >
> > Either method works, and I agree allowing DM to invoke this domctl is both
> > useful and not going to introduce problems. The getdomaininfo permission
> > will also need to be added to the device_model macro in xen.if.
>
> What exactly this last sentence means I need to add I'm not sure
> about. Apart from that, how about the change below?
>
> Jan
>
> domctl: relax getdomaininfo permissions
>
> Qemu needs access to this for the domain it controls, both due to it
> being used by xc_domain_memory_mapping() (which qemu calls) and the
> explicit use in hw/xenpv/xen_domainbuild.c:xen_domain_poll().
>
> This at once avoids a for_each_domain() loop when the ID of an
> existing domain gets passed in.
>
> Reported-by: Marek Marczykowski-Górecki
> ---
> I wonder what good the duplication of the returned domain ID does: I'm
> tempted to remove the one in the command-specific structure. Does
> anyone have insight into why it was done that way?
Isn't XEN_DOMCTL_getdomaininfo supposed to return info about first
existing domain with ID >= passed one? Reading various comments in code
it looks to be used to domain enumeration. This patch changes this
behaviour.
> I further wonder why we have XSM_OTHER: The respective conversion into
> other XSM_* values in xsm/dummy.h could as well move into the callers,
> making intentions more obvious when looking at the actual code.
>
> --- unstable.orig/xen/common/domctl.c
> +++ unstable/xen/common/domctl.c
> @@ -442,14 +442,13 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
> switch ( op->cmd )
> {
> case XEN_DOMCTL_createdomain:
> -case XEN_DOMCTL_getdomaininfo:
> case XEN_DOMCTL_test_assign_device:
> case XEN_DOMCTL_gdbsx_guestmemio:
> d = NULL;
> br
Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"
>>> On 23.06.16 at 10:57, wrote: > On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote: >> >>> On 22.06.16 at 20:24, wrote: >> > On 06/22/2016 11:23 AM, Jan Beulich wrote: >> > On 22.06.16 at 16:13, wrote: >> >>> On Wed, Jun 22, 2016 at 07:50:09AM -0600, Jan Beulich wrote: >> >>> On 22.06.16 at 15:03, wrote: >> > I've finally found what was causing long standing issue of not working >> > PCI passthrough for HVM domains with qemu in stubdomain (only - without >> > the other one in dom0). It looks to be this patch: >> > >> >>> > http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=c428c9f162895cb3473f >> > ab26d23ffbf41a6f293d;hp=dcccaf806a92eabb95929a67c344ac1e9ead6257 >> > >> > It calls xc_domain_getinfo from xc_domain_memory_mapping (to check if >> > the target domain is auto-translated), but xc_domain_getinfo fails with >> > EPERM in stubdomain. >> > >> > What would be the best solution for this? Allowing xc_domain_getinfo >> > from stubdomain in xen/include/xsm/dummy.h? Currently it is uses policy >> > XSM_XS_PRIV in unstable and just XSM_PRIV in 4.6 - so, maybe have some >> > combination of XSM_XS_PRIV and XSM_DM_PRIV? Or maybe fix this by >> > removing xc_domain_getinfo call in xc_domain_memory_mapping, possibly >> > implementing the logic from that commit solely in libxl? >> >> Once we fixed the quirky behavior of the current implementation >> (allowing information to be returned for other than the requested >> domain), I see no reason why this couldn't become XSM_DM_PRIV. >> >>> >> >>> Can you explain this more? Is this fix backported to 4.6 and/or 4.4? >> >> >> >> Which fix? I talked of one to be made. >> >> >> But let's ask Daniel explicitly. And in that context I then also wonder >> whether the xsm_getdomaininfo() invocation shouldn't be limited to >> the respective sysctl. >> >>> >> >>> Actually getdomaininfo is handled in two places in xsm/dummy.h: >> >>> - xsm_getdomaininfo (which does nothing when XSM is disabled) >> >>> - xsm_domctl (which enforce actual policy) >> >>> >> >>> Also reading commit message of XSM_XS_PRIV introduction, it may be >> >>> useful to be able to just check if given domain is alive, without >> >>> getting all the information returned by XEN_DOMCTL_getdomaininfo. I find >> >>> this useful also for any other inter-domain communication (for example >> >>> libxenvchan connection). >> >>> >> >>> But for now, XEN_DOMCTL_getdomaininfo should be allowed either when >> >>> device-model domain is asking about its target domain, or calling domain >> >>> is xenstore domain/privileged domain. Right? >> >> >> >> Yes, that's what I think too. >> >> >> >>> How to combine those >> >>> types? Change XSM_XS_PRIV to XSM_XS_DM_PRIV (it looks like the only >> >>> usage of XSM_XS_PRIV)? >> > >> > Changing the definition of XSM_XS_PRIV seems like the best solution, since >> > this is the only use. I don't think it matters if the constant is renamed >> > to XSM_XS_DM_PRIV or not. In fact, since the constant isn't ever used by a >> > caller, it could be removed and the actual logic placed in the switch >> > statement - that way it's clear this is a special case for getdomaininfo >> > instead of attempting to make this generic. >> > >> > Either method works, and I agree allowing DM to invoke this domctl is both >> > useful and not going to introduce problems. The getdomaininfo permission >> > will also need to be added to the device_model macro in xen.if. >> >> What exactly this last sentence means I need to add I'm not sure >> about. Apart from that, how about the change below? >> >> Jan >> >> domctl: relax getdomaininfo permissions >> >> Qemu needs access to this for the domain it controls, both due to it >> being used by xc_domain_memory_mapping() (which qemu calls) and the >> explicit use in hw/xenpv/xen_domainbuild.c:xen_domain_poll(). >> >> This at once avoids a for_each_domain() loop when the ID of an >> existing domain gets passed in. >> >> Reported-by: Marek Marczykowski-Górecki >> --- >> I wonder what good the duplication of the returned domain ID does: I'm >> tempted to remove the one in the command-specific structure. Does >> anyone have insight into why it was done that way? > > Isn't XEN_DOMCTL_getdomaininfo supposed to return info about first > existing domain with ID >= passed one? Reading various comments in code > it looks to be used to domain enumeration. This patch changes this > behaviour. No, it doesn't. It adjusts the behavior only for the DM case (which isn't supposed to get information on other than the target domain, i.e. in this one specific case the very domain ID needs to be passed in). Also, how is this comment of yours related to the remark above? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"
On Thu, Jun 23, 2016 at 03:12:47AM -0600, Jan Beulich wrote: > >>> On 23.06.16 at 10:57, wrote: > > On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote: > >> >>> On 22.06.16 at 20:24, wrote: > >> > On 06/22/2016 11:23 AM, Jan Beulich wrote: > >> > On 22.06.16 at 16:13, wrote: > >> >>> On Wed, Jun 22, 2016 at 07:50:09AM -0600, Jan Beulich wrote: > >> >>> On 22.06.16 at 15:03, wrote: > >> > I've finally found what was causing long standing issue of not > >> > working > >> > PCI passthrough for HVM domains with qemu in stubdomain (only - > >> > without > >> > the other one in dom0). It looks to be this patch: > >> > > >> >>> > > http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=c428c9f162895cb3473f > > > >> > ab26d23ffbf41a6f293d;hp=dcccaf806a92eabb95929a67c344ac1e9ead6257 > >> > > >> > It calls xc_domain_getinfo from xc_domain_memory_mapping (to check if > >> > the target domain is auto-translated), but xc_domain_getinfo fails > >> > with > >> > EPERM in stubdomain. > >> > > >> > What would be the best solution for this? Allowing xc_domain_getinfo > >> > from stubdomain in xen/include/xsm/dummy.h? Currently it is uses > >> > policy > >> > XSM_XS_PRIV in unstable and just XSM_PRIV in 4.6 - so, maybe have > >> > some > >> > combination of XSM_XS_PRIV and XSM_DM_PRIV? Or maybe fix this by > >> > removing xc_domain_getinfo call in xc_domain_memory_mapping, possibly > >> > implementing the logic from that commit solely in libxl? > >> > >> Once we fixed the quirky behavior of the current implementation > >> (allowing information to be returned for other than the requested > >> domain), I see no reason why this couldn't become XSM_DM_PRIV. > >> >>> > >> >>> Can you explain this more? Is this fix backported to 4.6 and/or 4.4? > >> >> > >> >> Which fix? I talked of one to be made. > >> >> > >> But let's ask Daniel explicitly. And in that context I then also > >> wonder > >> whether the xsm_getdomaininfo() invocation shouldn't be limited to > >> the respective sysctl. > >> >>> > >> >>> Actually getdomaininfo is handled in two places in xsm/dummy.h: > >> >>> - xsm_getdomaininfo (which does nothing when XSM is disabled) > >> >>> - xsm_domctl (which enforce actual policy) > >> >>> > >> >>> Also reading commit message of XSM_XS_PRIV introduction, it may be > >> >>> useful to be able to just check if given domain is alive, without > >> >>> getting all the information returned by XEN_DOMCTL_getdomaininfo. I > >> >>> find > >> >>> this useful also for any other inter-domain communication (for example > >> >>> libxenvchan connection). > >> >>> > >> >>> But for now, XEN_DOMCTL_getdomaininfo should be allowed either when > >> >>> device-model domain is asking about its target domain, or calling > >> >>> domain > >> >>> is xenstore domain/privileged domain. Right? > >> >> > >> >> Yes, that's what I think too. > >> >> > >> >>> How to combine those > >> >>> types? Change XSM_XS_PRIV to XSM_XS_DM_PRIV (it looks like the only > >> >>> usage of XSM_XS_PRIV)? > >> > > >> > Changing the definition of XSM_XS_PRIV seems like the best solution, > >> > since > >> > this is the only use. I don't think it matters if the constant is > >> > renamed > >> > to XSM_XS_DM_PRIV or not. In fact, since the constant isn't ever used > >> > by a > >> > caller, it could be removed and the actual logic placed in the switch > >> > statement - that way it's clear this is a special case for getdomaininfo > >> > instead of attempting to make this generic. > >> > > >> > Either method works, and I agree allowing DM to invoke this domctl is > >> > both > >> > useful and not going to introduce problems. The getdomaininfo permission > >> > will also need to be added to the device_model macro in xen.if. > >> > >> What exactly this last sentence means I need to add I'm not sure > >> about. Apart from that, how about the change below? > >> > >> Jan > >> > >> domctl: relax getdomaininfo permissions > >> > >> Qemu needs access to this for the domain it controls, both due to it > >> being used by xc_domain_memory_mapping() (which qemu calls) and the > >> explicit use in hw/xenpv/xen_domainbuild.c:xen_domain_poll(). > >> > >> This at once avoids a for_each_domain() loop when the ID of an > >> existing domain gets passed in. > >> > >> Reported-by: Marek Marczykowski-Górecki > >> --- > >> I wonder what good the duplication of the returned domain ID does: I'm > >> tempted to remove the one in the command-specific structure. Does > >> anyone have insight into why it was done that way? > > > > Isn't XEN_DOMCTL_getdomaininfo supposed to return info about first > > existing domain with ID >= passed one? Reading various comments in code > > it looks to be used to domain enumeration. This patch changes this > > behaviour. > > No, it doesn't. It adjusts the behavior only for the DM case (which > isn't s
Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"
On Thu, Jun 23, 2016 at 11:18:24AM +0200, Marek Marczykowski-Górecki wrote: > On Thu, Jun 23, 2016 at 03:12:47AM -0600, Jan Beulich wrote: > > >>> On 23.06.16 at 10:57, wrote: > > > On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote: > > >> >>> On 22.06.16 at 20:24, wrote: > > >> > On 06/22/2016 11:23 AM, Jan Beulich wrote: > > >> > On 22.06.16 at 16:13, wrote: > > >> >>> On Wed, Jun 22, 2016 at 07:50:09AM -0600, Jan Beulich wrote: > > >> >>> On 22.06.16 at 15:03, wrote: > > >> > I've finally found what was causing long standing issue of not > > >> > working > > >> > PCI passthrough for HVM domains with qemu in stubdomain (only - > > >> > without > > >> > the other one in dom0). It looks to be this patch: > > >> > > > >> >>> > > > http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=c428c9f162895cb3473f > > > > > >> > ab26d23ffbf41a6f293d;hp=dcccaf806a92eabb95929a67c344ac1e9ead6257 > > >> > > > >> > It calls xc_domain_getinfo from xc_domain_memory_mapping (to check > > >> > if > > >> > the target domain is auto-translated), but xc_domain_getinfo fails > > >> > with > > >> > EPERM in stubdomain. > > >> > > > >> > What would be the best solution for this? Allowing > > >> > xc_domain_getinfo > > >> > from stubdomain in xen/include/xsm/dummy.h? Currently it is uses > > >> > policy > > >> > XSM_XS_PRIV in unstable and just XSM_PRIV in 4.6 - so, maybe have > > >> > some > > >> > combination of XSM_XS_PRIV and XSM_DM_PRIV? Or maybe fix this by > > >> > removing xc_domain_getinfo call in xc_domain_memory_mapping, > > >> > possibly > > >> > implementing the logic from that commit solely in libxl? > > >> > > >> Once we fixed the quirky behavior of the current implementation > > >> (allowing information to be returned for other than the requested > > >> domain), I see no reason why this couldn't become XSM_DM_PRIV. > > >> >>> > > >> >>> Can you explain this more? Is this fix backported to 4.6 and/or 4.4? > > >> >> > > >> >> Which fix? I talked of one to be made. > > >> >> > > >> But let's ask Daniel explicitly. And in that context I then also > > >> wonder > > >> whether the xsm_getdomaininfo() invocation shouldn't be limited to > > >> the respective sysctl. > > >> >>> > > >> >>> Actually getdomaininfo is handled in two places in xsm/dummy.h: > > >> >>> - xsm_getdomaininfo (which does nothing when XSM is disabled) > > >> >>> - xsm_domctl (which enforce actual policy) > > >> >>> > > >> >>> Also reading commit message of XSM_XS_PRIV introduction, it may be > > >> >>> useful to be able to just check if given domain is alive, without > > >> >>> getting all the information returned by XEN_DOMCTL_getdomaininfo. I > > >> >>> find > > >> >>> this useful also for any other inter-domain communication (for > > >> >>> example > > >> >>> libxenvchan connection). > > >> >>> > > >> >>> But for now, XEN_DOMCTL_getdomaininfo should be allowed either when > > >> >>> device-model domain is asking about its target domain, or calling > > >> >>> domain > > >> >>> is xenstore domain/privileged domain. Right? > > >> >> > > >> >> Yes, that's what I think too. > > >> >> > > >> >>> How to combine those > > >> >>> types? Change XSM_XS_PRIV to XSM_XS_DM_PRIV (it looks like the only > > >> >>> usage of XSM_XS_PRIV)? > > >> > > > >> > Changing the definition of XSM_XS_PRIV seems like the best solution, > > >> > since > > >> > this is the only use. I don't think it matters if the constant is > > >> > renamed > > >> > to XSM_XS_DM_PRIV or not. In fact, since the constant isn't ever used > > >> > by a > > >> > caller, it could be removed and the actual logic placed in the switch > > >> > statement - that way it's clear this is a special case for > > >> > getdomaininfo > > >> > instead of attempting to make this generic. > > >> > > > >> > Either method works, and I agree allowing DM to invoke this domctl is > > >> > both > > >> > useful and not going to introduce problems. The getdomaininfo > > >> > permission > > >> > will also need to be added to the device_model macro in xen.if. > > >> > > >> What exactly this last sentence means I need to add I'm not sure > > >> about. Apart from that, how about the change below? > > >> > > >> Jan > > >> > > >> domctl: relax getdomaininfo permissions > > >> > > >> Qemu needs access to this for the domain it controls, both due to it > > >> being used by xc_domain_memory_mapping() (which qemu calls) and the > > >> explicit use in hw/xenpv/xen_domainbuild.c:xen_domain_poll(). > > >> > > >> This at once avoids a for_each_domain() loop when the ID of an > > >> existing domain gets passed in. > > >> > > >> Reported-by: Marek Marczykowski-Górecki > > >> --- > > >> I wonder what good the duplication of the returned domain ID does: I'm > > >> tempted to remove the one in the command-specific structure. Does > > >> anyone have insig
Re: [Xen-devel] [PATCH] OvmfPkg: Add ACPI support for Virt Xen ARM
On 2016/5/31 18:35, Laszlo Ersek wrote: > On 05/31/16 06:59, Shannon Zhao wrote: >> > From: Shannon Zhao >> > >> > Add ACPI support for Virt Xen ARM and it gets the ACPI tables through >> > Xen ARM multiboot protocol. >> > >> > Contributed-under: TianoCore Contribution Agreement 1.0 >> > Signed-off-by: Shannon Zhao >> > --- >> > The corresponding Xen patches can be fetched from: >> > http://git.linaro.org/people/shannon.zhao/xen.git/shortlog/refs/heads/domu_acpi >> > --- >> > ArmVirtPkg/ArmVirtXen.dsc | 6 + >> > ArmVirtPkg/ArmVirtXen.fdf | 6 + >> > OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h| 6 + >> > OvmfPkg/AcpiPlatformDxe/XenArmAcpi.c | 207 >> > ++ >> > OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatform.c | 38 >> > OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatformDxe.inf | 59 ++ >> > 6 files changed, 322 insertions(+) >> > create mode 100644 OvmfPkg/AcpiPlatformDxe/XenArmAcpi.c >> > create mode 100644 OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatform.c >> > create mode 100644 OvmfPkg/AcpiPlatformDxe/XenArmAcpiPlatformDxe.inf > Jordan and I might disagree about this patch, but here's my comments > about it: > > I don't think this patch belongs under OvmfPkg. Namely, the only file > that XenArmAcpiPlatformDxe reuses from the existing > OvmfPkg/AcpiPlatformDxe/ directory is "EntryPoint.c", which is (a) > trivial, (b) its conditions and branches should be possible to evaluate > statically for aarch64 Xen. (PcdPciDisableBusEnumeration should be set > to TRUE in ArmVirtXen.dsc.) > > Second, the new code uses the FDT library directly (from EmbeddedPkg), > and accesses QEMU's DTB directly (with the fdt_*() APIs). However, in > ArmVirtPkg we have moved away from this, and now we have a custom > (edk2-only, non-standard) FdtClient protocol for accessing the FDT. > Please see: > - ArmVirtPkg/Include/Protocol/FdtClient.h > - ArmVirtPkg/FdtClientDxe/ > > In order to rebase this patch to the FDT Client Protocol, while keeping > it under OvmfPkg, the "XenArmAcpiPlatformDxe.inf" file would have to > list "ArmVirtPkg/ArmVirtPkg.dec" in the [Packages] section. I think that > would be very ugly. Thus far we have managed to avoid mutual references > between OvmfPkg and ArmVirtPkg: OvmfPkg doesn't consume anything from > ArmVirtPkg, and that's how things should stay in my opinion. > > Which is why I suggest to implement this functionality entirely under > ArmVirtPkg, and using the FDT Client Protocol at that. > Thanks for your explanation. I will move this into ArmVirtPkg. > If a non-trivial chunk of functionality can be identified between > OvmfPkg and ArmVirtPkg in this regard (that currently exists under > OvmfPkg/AcpiPlatformDxe/), then it should be extracted into a library > (under OvmfPkg/Include/Library and OvmfPkg/Library), and the ArmVirtPkg > code should become a client of that library. (You can find many similar > OvmfPkg/Library/ resolutions in the ArmVirtPkg/ DSC files.) > > NB: Ard is going to be on vacation for a while, and I think we should > definitely await his feedback on this. First, my participation in > ArmVirtXen matters is quite minimal. Second, Ard designed the FDT Client > Protocol; in case you need extensions to the current APIs for > implementing the feature, then Ard is the one to review them. I think it will only use the existing FindCompatibleNodeReg() function of FDT Client. So I'll move on next version. Thanks, -- Shannon ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] OvmfPkg: Add ACPI support for Virt Xen ARM
On 2016/6/7 21:50, Julien Grall wrote:
>
> On 31/05/16 05:59, Shannon Zhao wrote:
>> +EFI_STATUS
>> +EFIAPI
>> +GetXenArmAcpiRsdp (
>> + OUT EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER **RsdpPtr
>> + )
>> +{
>> + VOID *Hob;
>> + EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *RsdpStructurePtr;
>> + VOID *DeviceTreeBase;
>> + INT32 Node, Depth, Len;
>> + CONST CHAR8*Type;
>> + CONST VOID *RegProp;
>> +
>> + RsdpStructurePtr = NULL;
>> + //
>> + // Get the RSDP structure address from DeviceTree
>> + //
>> + Hob = GetFirstGuidHob(&gFdtHobGuid);
>> + if (Hob == NULL || GET_GUID_HOB_DATA_SIZE (Hob) != sizeof (UINT64)) {
>> +DEBUG ((EFI_D_ERROR, "%a: Failed to get Fdt Hob\n", __FUNCTION__));
>> +return EFI_NOT_FOUND;
>> + }
>> + DeviceTreeBase = (VOID *)(UINTN)*(UINT64 *)GET_GUID_HOB_DATA (Hob);
>> +
>> + if (fdt_check_header (DeviceTreeBase) != 0) {
>> +DEBUG ((EFI_D_ERROR, "%a: No DTB found @ 0x%p\n", __FUNCTION__,
>> DeviceTreeBase));
>> +return EFI_NOT_FOUND;
>> + }
>> +
>> + Node = fdt_path_offset(DeviceTreeBase, "/chosen/modules");
>
> I am not sure if we want to mandate the modules to live in "/chosen".
> Would it be possible to look by compatible instead?
Sure, I will use the compatible string to find the DT node at next version.
Thanks,
--
Shannon
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"
On 23/06/16 09:32, Jan Beulich wrote: On 22.06.16 at 20:24, wrote: >> On 06/22/2016 11:23 AM, Jan Beulich wrote: >> On 22.06.16 at 16:13, wrote: On Wed, Jun 22, 2016 at 07:50:09AM -0600, Jan Beulich wrote: On 22.06.16 at 15:03, wrote: >> I've finally found what was causing long standing issue of not working >> PCI passthrough for HVM domains with qemu in stubdomain (only - without >> the other one in dom0). It looks to be this patch: >> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=c428c9f162895cb3473f >> ab26d23ffbf41a6f293d;hp=dcccaf806a92eabb95929a67c344ac1e9ead6257 >> >> It calls xc_domain_getinfo from xc_domain_memory_mapping (to check if >> the target domain is auto-translated), but xc_domain_getinfo fails with >> EPERM in stubdomain. >> >> What would be the best solution for this? Allowing xc_domain_getinfo >> from stubdomain in xen/include/xsm/dummy.h? Currently it is uses policy >> XSM_XS_PRIV in unstable and just XSM_PRIV in 4.6 - so, maybe have some >> combination of XSM_XS_PRIV and XSM_DM_PRIV? Or maybe fix this by >> removing xc_domain_getinfo call in xc_domain_memory_mapping, possibly >> implementing the logic from that commit solely in libxl? > Once we fixed the quirky behavior of the current implementation > (allowing information to be returned for other than the requested > domain), I see no reason why this couldn't become XSM_DM_PRIV. Can you explain this more? Is this fix backported to 4.6 and/or 4.4? >>> Which fix? I talked of one to be made. >>> > But let's ask Daniel explicitly. And in that context I then also wonder > whether the xsm_getdomaininfo() invocation shouldn't be limited to > the respective sysctl. Actually getdomaininfo is handled in two places in xsm/dummy.h: - xsm_getdomaininfo (which does nothing when XSM is disabled) - xsm_domctl (which enforce actual policy) Also reading commit message of XSM_XS_PRIV introduction, it may be useful to be able to just check if given domain is alive, without getting all the information returned by XEN_DOMCTL_getdomaininfo. I find this useful also for any other inter-domain communication (for example libxenvchan connection). But for now, XEN_DOMCTL_getdomaininfo should be allowed either when device-model domain is asking about its target domain, or calling domain is xenstore domain/privileged domain. Right? >>> Yes, that's what I think too. >>> How to combine those types? Change XSM_XS_PRIV to XSM_XS_DM_PRIV (it looks like the only usage of XSM_XS_PRIV)? >> Changing the definition of XSM_XS_PRIV seems like the best solution, since >> this is the only use. I don't think it matters if the constant is renamed >> to XSM_XS_DM_PRIV or not. In fact, since the constant isn't ever used by a >> caller, it could be removed and the actual logic placed in the switch >> statement - that way it's clear this is a special case for getdomaininfo >> instead of attempting to make this generic. >> >> Either method works, and I agree allowing DM to invoke this domctl is both >> useful and not going to introduce problems. The getdomaininfo permission >> will also need to be added to the device_model macro in xen.if. > What exactly this last sentence means I need to add I'm not sure > about. Apart from that, how about the change below? > > Jan > > domctl: relax getdomaininfo permissions > > Qemu needs access to this for the domain it controls, both due to it > being used by xc_domain_memory_mapping() (which qemu calls) and the > explicit use in hw/xenpv/xen_domainbuild.c:xen_domain_poll(). > > This at once avoids a for_each_domain() loop when the ID of an > existing domain gets passed in. > > Reported-by: Marek Marczykowski-Górecki > --- > I wonder what good the duplication of the returned domain ID does: I'm > tempted to remove the one in the command-specific structure. Does > anyone have insight into why it was done that way? This hypercall, and its sibling XEN_SYSCTL_getdomaininfolist have crazy semantics, which go out of their way to make it easy to get wrong. It is important that you always check the returned domid, as it may not be the domain you asked for. In particular, if a domain you are looking after dies, the adjacent domain's information will be returnned. Also, noone has yet addressed the issue that, strictly speaking, xen_domctl_getdomaininfo_t is versioned by both the DOMCTL and the SYSCTL interface version. This in particular makes things interesting for valgrind support. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"
>>> On 23.06.16 at 11:18, wrote: > On Thu, Jun 23, 2016 at 03:12:47AM -0600, Jan Beulich wrote: >> >>> On 23.06.16 at 10:57, wrote: >> > On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote: >> >> >>> On 22.06.16 at 20:24, wrote: >> >> > On 06/22/2016 11:23 AM, Jan Beulich wrote: >> >> > On 22.06.16 at 16:13, wrote: >> >> >>> On Wed, Jun 22, 2016 at 07:50:09AM -0600, Jan Beulich wrote: >> >> >>> On 22.06.16 at 15:03, wrote: >> >> > I've finally found what was causing long standing issue of not >> >> > working >> >> > PCI passthrough for HVM domains with qemu in stubdomain (only - >> >> > without >> >> > the other one in dom0). It looks to be this patch: >> >> > >> >> >>> >> > > http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=c428c9f162895cb3473f >> >> > ab26d23ffbf41a6f293d;hp=dcccaf806a92eabb95929a67c344ac1e9ead6257 >> >> > >> >> > It calls xc_domain_getinfo from xc_domain_memory_mapping (to check >> >> > if >> >> > the target domain is auto-translated), but xc_domain_getinfo fails >> >> > with >> >> > EPERM in stubdomain. >> >> > >> >> > What would be the best solution for this? Allowing xc_domain_getinfo >> >> > from stubdomain in xen/include/xsm/dummy.h? Currently it is uses >> >> > policy >> >> > XSM_XS_PRIV in unstable and just XSM_PRIV in 4.6 - so, maybe have >> >> > some >> >> > combination of XSM_XS_PRIV and XSM_DM_PRIV? Or maybe fix this by >> >> > removing xc_domain_getinfo call in xc_domain_memory_mapping, >> >> > possibly >> >> > implementing the logic from that commit solely in libxl? >> >> >> >> Once we fixed the quirky behavior of the current implementation >> >> (allowing information to be returned for other than the requested >> >> domain), I see no reason why this couldn't become XSM_DM_PRIV. >> >> >>> >> >> >>> Can you explain this more? Is this fix backported to 4.6 and/or 4.4? >> >> >> >> >> >> Which fix? I talked of one to be made. >> >> >> >> >> But let's ask Daniel explicitly. And in that context I then also >> >> wonder >> >> whether the xsm_getdomaininfo() invocation shouldn't be limited to >> >> the respective sysctl. >> >> >>> >> >> >>> Actually getdomaininfo is handled in two places in xsm/dummy.h: >> >> >>> - xsm_getdomaininfo (which does nothing when XSM is disabled) >> >> >>> - xsm_domctl (which enforce actual policy) >> >> >>> >> >> >>> Also reading commit message of XSM_XS_PRIV introduction, it may be >> >> >>> useful to be able to just check if given domain is alive, without >> >> >>> getting all the information returned by XEN_DOMCTL_getdomaininfo. I >> >> >>> find >> >> >>> this useful also for any other inter-domain communication (for example >> >> >>> libxenvchan connection). >> >> >>> >> >> >>> But for now, XEN_DOMCTL_getdomaininfo should be allowed either when >> >> >>> device-model domain is asking about its target domain, or calling >> >> >>> domain >> >> >>> is xenstore domain/privileged domain. Right? >> >> >> >> >> >> Yes, that's what I think too. >> >> >> >> >> >>> How to combine those >> >> >>> types? Change XSM_XS_PRIV to XSM_XS_DM_PRIV (it looks like the only >> >> >>> usage of XSM_XS_PRIV)? >> >> > >> >> > Changing the definition of XSM_XS_PRIV seems like the best solution, >> >> > since >> >> > this is the only use. I don't think it matters if the constant is >> >> > renamed >> >> > to XSM_XS_DM_PRIV or not. In fact, since the constant isn't ever used >> >> > by > a >> >> > caller, it could be removed and the actual logic placed in the switch >> >> > statement - that way it's clear this is a special case for getdomaininfo >> >> > instead of attempting to make this generic. >> >> > >> >> > Either method works, and I agree allowing DM to invoke this domctl is >> >> > both >> >> > useful and not going to introduce problems. The getdomaininfo >> >> > permission >> >> > will also need to be added to the device_model macro in xen.if. >> >> >> >> What exactly this last sentence means I need to add I'm not sure >> >> about. Apart from that, how about the change below? >> >> >> >> Jan >> >> >> >> domctl: relax getdomaininfo permissions >> >> >> >> Qemu needs access to this for the domain it controls, both due to it >> >> being used by xc_domain_memory_mapping() (which qemu calls) and the >> >> explicit use in hw/xenpv/xen_domainbuild.c:xen_domain_poll(). >> >> >> >> This at once avoids a for_each_domain() loop when the ID of an >> >> existing domain gets passed in. >> >> >> >> Reported-by: Marek Marczykowski-Górecki >> >> --- >> >> I wonder what good the duplication of the returned domain ID does: I'm >> >> tempted to remove the one in the command-specific structure. Does >> >> anyone have insight into why it was done that way? >> > >> > Isn't XEN_DOMCTL_getdomaininfo supposed to return info about first >> > existing domain with ID >= passed one? Reading various comments i
Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"
>>> On 23.06.16 at 11:23, wrote:
> On Thu, Jun 23, 2016 at 11:18:24AM +0200, Marek Marczykowski-Górecki wrote:
>> On Thu, Jun 23, 2016 at 03:12:47AM -0600, Jan Beulich wrote:
>> > >>> On 23.06.16 at 10:57, wrote:
>> > > On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote:
>> > >> I wonder what good the duplication of the returned domain ID does: I'm
>> > >> tempted to remove the one in the command-specific structure. Does
>> > >> anyone have insight into why it was done that way?
>> > >
>> > > Isn't XEN_DOMCTL_getdomaininfo supposed to return info about first
>> > > existing domain with ID >= passed one? Reading various comments in code
>> > > it looks to be used to domain enumeration. This patch changes this
>> > > behaviour.
>> >
>> > No, it doesn't. It adjusts the behavior only for the DM case (which
>> > isn't supposed to get information on other than the target domain,
>> > i.e. in this one specific case the very domain ID needs to be passed
>> > in).
>>
>> int xc_domain_getinfo(xc_interface *xch,
>> uint32_t first_domid,
>> unsigned int max_doms,
>> xc_dominfo_t *info)
>> {
>> unsigned int nr_doms;
>> uint32_t next_domid = first_domid;
>> DECLARE_DOMCTL;
>> int rc = 0;
>>
>> memset(info, 0, max_doms*sizeof(xc_dominfo_t));
>>
>> for ( nr_doms = 0; nr_doms < max_doms; nr_doms++ )
>> {
>> domctl.cmd = XEN_DOMCTL_getdomaininfo;
>> domctl.domain = (domid_t)next_domid;
>> if ( (rc = do_domctl(xch, &domctl)) < 0 )
>> break;
>> info->domid = (uint16_t)domctl.domain;
>> (...)
>> next_domid = (uint16_t)domctl.domain + 1;
>>
>>
>> Looks like heavily dependent on XEN_DOMCTL_getdomaininfo returning next
> valid
>> domain.
>
> Hmm, looks like I've misread you patch. Reading again...
>
> But now I see rcu_read_lock(&domlist_read_lock) is gets called only when
> looping over domains, but rcu_read_unlock is called in any case. Is it
> correct?
How that? There is this third hunk:
@@ -885,6 +892,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe
copyback = 1;
getdomaininfo_out:
+if ( dom == DOMID_INVALID )
+break;
+
rcu_read_unlock(&domlist_read_lock);
d = NULL;
break;
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"
>>> On 23.06.16 at 11:44, wrote: > On 23/06/16 09:32, Jan Beulich wrote: >> I wonder what good the duplication of the returned domain ID does: I'm >> tempted to remove the one in the command-specific structure. Does >> anyone have insight into why it was done that way? > > This hypercall, and its sibling XEN_SYSCTL_getdomaininfolist have crazy > semantics, which go out of their way to make it easy to get wrong. > > It is important that you always check the returned domid, as it may not > be the domain you asked for. In particular, if a domain you are looking > after dies, the adjacent domain's information will be returnned. Same question as to Marek: How is this related to my remark? > Also, noone has yet addressed the issue that, strictly speaking, > xen_domctl_getdomaininfo_t is versioned by both the DOMCTL and the > SYSCTL interface version. This in particular makes things interesting > for valgrind support. True, and afaict also the case for XEN_SCHEDULER_*. No idea how to cleanly address this other than by folding the two versions. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv3] x86/xen: avoid m2p lookup when setting early page table entries
When page tables entries are set using xen_set_pte_init() during early
boot there is no page fault handler that could handle a fault when
performing an M2P lookup.
In 64 bit guests (usually dom0) early_ioremap() would fault in
xen_set_pte_init() because an M2P lookup faults because the MFN is in
MMIO space and not mapped in the M2P. This lookup is done to see if
the PFN in in the range used for the initial page table pages, so that
the PTE may be set as read-only.
The M2P lookup can be avoided by moving the check (and clear of RW)
earlier when the PFN is still available.
Signed-off-by: David Vrabel
---
Cc: Kevin Moraga
v3:
- fold mask_rw_pte()/mask_rw_pteval() into their callers.
v2:
- Remove __init annotation from xen_make_pte_init() since
PV_CALLEE_SAVE_REGS_THUNK always puts the thunk in .text.
- mask_rw_pte() -> mask_rw_pteval() for x86-64.
---
arch/x86/xen/mmu.c | 76 +-
1 file changed, 35 insertions(+), 41 deletions(-)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 478a2de..64d8f0b 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1551,41 +1551,6 @@ static void xen_pgd_free(struct mm_struct *mm, pgd_t
*pgd)
#endif
}
-#ifdef CONFIG_X86_32
-static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
-{
- /* If there's an existing pte, then don't allow _PAGE_RW to be set */
- if (pte_val_ma(*ptep) & _PAGE_PRESENT)
- pte = __pte_ma(((pte_val_ma(*ptep) & _PAGE_RW) | ~_PAGE_RW) &
- pte_val_ma(pte));
-
- return pte;
-}
-#else /* CONFIG_X86_64 */
-static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
-{
- unsigned long pfn;
-
- if (xen_feature(XENFEAT_writable_page_tables) ||
- xen_feature(XENFEAT_auto_translated_physmap) ||
- xen_start_info->mfn_list >= __START_KERNEL_map)
- return pte;
-
- /*
-* Pages belonging to the initial p2m list mapped outside the default
-* address range must be mapped read-only. This region contains the
-* page tables for mapping the p2m list, too, and page tables MUST be
-* mapped read-only.
-*/
- pfn = pte_pfn(pte);
- if (pfn >= xen_start_info->first_p2m_pfn &&
- pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_frames)
- pte = __pte_ma(pte_val_ma(pte) & ~_PAGE_RW);
-
- return pte;
-}
-#endif /* CONFIG_X86_64 */
-
/*
* Init-time set_pte while constructing initial pagetables, which
* doesn't allow RO page table pages to be remapped RW.
@@ -1600,13 +1565,41 @@ static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
* so always write the PTE directly and rely on Xen trapping and
* emulating any updates as necessary.
*/
-static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
+__visible pte_t xen_make_pte_init(pteval_t pte)
{
- if (pte_mfn(pte) != INVALID_P2M_ENTRY)
- pte = mask_rw_pte(ptep, pte);
- else
- pte = __pte_ma(0);
+#ifdef CONFIG_X86_64
+ unsigned long pfn;
+
+ /*
+* Pages belonging to the initial p2m list mapped outside the default
+* address range must be mapped read-only. This region contains the
+* page tables for mapping the p2m list, too, and page tables MUST be
+* mapped read-only.
+*/
+ pfn = (pte & PTE_PFN_MASK) >> PAGE_SHIFT;
+ if (xen_start_info->mfn_list < __START_KERNEL_map &&
+ pfn >= xen_start_info->first_p2m_pfn &&
+ pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_frames)
+ pte &= ~_PAGE_RW;
+#endif
+ pte = pte_pfn_to_mfn(pte);
+ if ((pte & PTE_PFN_MASK) >> PAGE_SHIFT == INVALID_P2M_ENTRY)
+ pte = 0;
+
+ return native_make_pte(pte);
+}
+PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte_init);
+
+static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
+{
+#ifdef CONFIG_X86_32
+ /* If there's an existing pte, then don't allow _PAGE_RW to be set */
+ if (pte_mfn(pte) != INVALID_P2M_ENTRY
+ && pte_val_ma(*ptep) & _PAGE_PRESENT)
+ pte = __pte_ma(((pte_val_ma(*ptep) & _PAGE_RW) | ~_PAGE_RW) &
+ pte_val_ma(pte));
+#endif
native_set_pte(ptep, pte);
}
@@ -2407,6 +2400,7 @@ static void __init xen_post_allocator_init(void)
pv_mmu_ops.alloc_pud = xen_alloc_pud;
pv_mmu_ops.release_pud = xen_release_pud;
#endif
+ pv_mmu_ops.make_pte = PV_CALLEE_SAVE(xen_make_pte);
#ifdef CONFIG_X86_64
pv_mmu_ops.write_cr3 = &xen_write_cr3;
@@ -2455,7 +2449,7 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
.pte_val = PV_CALLEE_SAVE(xen_pte_val),
.pgd_val = PV_CALLEE_SAVE(xen_pgd_val),
- .make_pte = PV_CALLEE_SAVE(xen_make_pte),
+ .make_pte = PV_CALLEE_SAVE(xen_make_pte_init),
.make_pgd = PV_CALLEE_SAVE(xen_make_pgd),
#ifdef CONFIG_X86_PAE
--
2.1
Re: [Xen-devel] [PATCH] xen/pciback: Fix conf_space read/write overlap check.
On 21/06/16 19:26, Andrey Grodzovsky wrote: > Current overlap check is evaluating to false a case where a filter field > is fully contained (proper subset) of a r/w request. > This change applies classical overlap check instead to include > all the scenarios. > > More specifically, for (Hilscher GmbH CIFX 50E-DP(M/S)) device > driver the logic is such that the entire confspace is read and > written in 4 byte chunks.In this case as an example, CACHE_LINE_SIZE, > LATENCY_TIMER and PCI_BIST are arriving together in one call to > xen_pcibk_config_write with offset == 0xc and size == 4. > With the exsisting overlap check LATENCY_TIMER field > (offset == 0xd, length == 1) is fully contained in the write request > and hence is excluded from write, which is incorrect. Applied to for-linus-4.7b, thanks. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: fix upper bound of pmd loop in xen_cleanhighmap()
On 23/06/16 06:12, Juergen Gross wrote: > xen_cleanhighmap() is operating on level2_kernel_pgt only. The upper > bound of the loop setting non-kernel-image entries to zero should not > exceed the size of level2_kernel_pgt. Applied to for-linus-4.7b, thanks. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86/HVM: use available linear->phys translations in REP MOVS/STOS handling
On 22/06/16 08:19, Jan Beulich wrote: On 21.06.16 at 21:50, wrote: >> On 20/06/16 12:29, Jan Beulich wrote: >>> If we have the translation result available already, we should also use >>> it here. In my tests with Linux guests this eliminates all calls to >>> hvmemul_linear_to_phys() from the STOS path and most from the MOVS one. >>> >>> Also record the translation for re-use at least during response >>> processing. >>> >>> Signed-off-by: Jan Beulich >> This patch is still broken. All XenServer HVM guests (both windows and >> linux) are dying, with Qemu citing > _All_? That contradicts both my own testing and osstest's smoke > one having succeeded. Apologies for the noise. This was actually caused by the DOMCTL interface bump, but manifests itself as hvmloader getting stuck while performing IO to Qemu. After fixing up a local change we have, everything is back to full working order. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 1/8] xen/arm: Rename gmfn_to_mfn to gfn_to_mfn and use gfn/mfn typesafe
On Tue, 21 Jun 2016, Julien Grall wrote:
> The correct acronym for a guest physical frame is gfn. Also use
> the recently introduced typesafe gfn/mfn to avoid mixing the two
> different kind of frame.
>
> Signed-off-by: Julien Grall
> Acked-by: Jan Beulich
Acked-by: Stefano Stabellini
> ---
> Cc: Stefano Stabellini
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Konrad Rzeszutek Wilk
> Cc: Tim Deegan
> Cc: Wei Liu
>
> Changes in v2:
> - Add Jan's acked-by
> - CCed the relevant maintainers
> ---
> xen/arch/arm/p2m.c| 6 +++---
> xen/common/grant_table.c | 4 ++--
> xen/common/memory.c | 4 ++--
> xen/include/asm-arm/p2m.h | 2 +-
> 4 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 65d8f1a..ab0cb41 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1481,10 +1481,10 @@ int p2m_cache_flush(struct domain *d, xen_pfn_t
> start_mfn, xen_pfn_t end_mfn)
> d->arch.p2m.default_access);
> }
>
> -unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn)
> +mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn)
> {
> -paddr_t p = p2m_lookup(d, pfn_to_paddr(gpfn), NULL);
> -return p >> PAGE_SHIFT;
> +paddr_t p = p2m_lookup(d, pfn_to_paddr(gfn_x(gfn)), NULL);
> +return _mfn(p >> PAGE_SHIFT);
> }
>
> /*
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index 8b22299..3c304f4 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -256,7 +256,7 @@ static int __get_paged_frame(unsigned long gfn, unsigned
> long *frame, struct pag
> }
> *frame = page_to_mfn(*page);
> #else
> -*frame = gmfn_to_mfn(rd, gfn);
> +*frame = mfn_x(gfn_to_mfn(rd, _gfn(gfn)));
> *page = mfn_valid(*frame) ? mfn_to_page(*frame) : NULL;
> if ( (!(*page)) || (!get_page(*page, rd)) )
> {
> @@ -1788,7 +1788,7 @@ gnttab_transfer(
> mfn = INVALID_MFN;
> }
> #else
> -mfn = gmfn_to_mfn(d, gop.mfn);
> +mfn = mfn_x(gfn_to_mfn(d, _gfn(gop.mfn)));
> #endif
>
> /* Check the passed page frame for basic validity. */
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index 46b1d9f..b54b076 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -264,7 +264,7 @@ int guest_remove_page(struct domain *d, unsigned long
> gmfn)
> return 1;
> }
> #else
> -mfn = gmfn_to_mfn(d, gmfn);
> +mfn = mfn_x(gfn_to_mfn(d, _gfn(gmfn)));
> #endif
> if ( unlikely(!mfn_valid(mfn)) )
> {
> @@ -488,7 +488,7 @@ static long
> memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
> goto fail;
> }
> #else /* !CONFIG_X86 */
> -mfn = gmfn_to_mfn(d, gmfn + k);
> +mfn = mfn_x(gfn_to_mfn(d, _gfn(gmfn + k)));
> #endif
> if ( unlikely(!mfn_valid(mfn)) )
> {
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index d240d1e..75c65a8 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -178,7 +178,7 @@ void guest_physmap_remove_page(struct domain *d,
> unsigned long gpfn,
> unsigned long mfn, unsigned int page_order);
>
> -unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
> +mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn);
>
> /*
> * Populate-on-demand
> --
> 1.9.1
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 3/8] xen: Use typesafe gfn/mfn in guest_physmap_* helpers
On Tue, 21 Jun 2016, Julien Grall wrote:
> Also rename some variables to gfn or mfn when it does not require much
> rework.
>
> Finally replace %hu with %d when printing the domain id in
> guest_physmap_add_entry (arch/x86/mm/p2m.c).
>
> Signed-off-by: Julien Grall
> Acked-by: Jan Beulich
Acked-by: Stefano Stabellini
> ---
> Cc: Stefano Stabellini
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Paul Durrant
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Konrad Rzeszutek Wilk
> Cc: Tim Deegan
> Cc: Wei Liu
>
> Changes in v3:
> - Use %d to print the domain id rather than %hu
> - Add Jan's Acked-by for non-ARM bits
>
> Changes in v2:
> - Don't use a wrapper for x86. Instead use mfn_* to make
> the change simpler.
> ---
> xen/arch/arm/domain_build.c| 2 +-
> xen/arch/arm/mm.c | 10 ++---
> xen/arch/arm/p2m.c | 20 +-
> xen/arch/x86/domain.c | 5 ++-
> xen/arch/x86/domain_build.c| 6 +--
> xen/arch/x86/hvm/ioreq.c | 8 ++--
> xen/arch/x86/mm.c | 12 +++---
> xen/arch/x86/mm/p2m.c | 78
> --
> xen/common/grant_table.c | 7 ++--
> xen/common/memory.c| 32
> xen/drivers/passthrough/arm/smmu.c | 4 +-
> xen/include/asm-arm/p2m.h | 12 +++---
> xen/include/asm-x86/p2m.h | 11 +++---
> xen/include/xen/mm.h | 2 +-
> 14 files changed, 110 insertions(+), 99 deletions(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 410bb4f..9035486 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -117,7 +117,7 @@ static bool_t insert_11_bank(struct domain *d,
> goto fail;
> }
>
> -res = guest_physmap_add_page(d, spfn, spfn, order);
> +res = guest_physmap_add_page(d, _gfn(spfn), _mfn(spfn), order);
> if ( res )
> panic("Failed map pages to DOM0: %d", res);
>
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 2ec211b..5ab9b75 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1153,7 +1153,7 @@ int xenmem_add_to_physmap_one(
> }
>
> /* Map at new location. */
> -rc = guest_physmap_add_entry(d, gpfn, mfn, 0, t);
> +rc = guest_physmap_add_entry(d, _gfn(gpfn), _mfn(mfn), 0, t);
>
> /* If we fail to add the mapping, we need to drop the reference we
> * took earlier on foreign pages */
> @@ -1282,8 +1282,8 @@ int create_grant_host_mapping(unsigned long addr,
> unsigned long frame,
> if ( flags & GNTMAP_readonly )
> t = p2m_grant_map_ro;
>
> -rc = guest_physmap_add_entry(current->domain, addr >> PAGE_SHIFT,
> - frame, 0, t);
> +rc = guest_physmap_add_entry(current->domain, _gfn(addr >> PAGE_SHIFT),
> + _mfn(frame), 0, t);
>
> if ( rc )
> return GNTST_general_error;
> @@ -1294,13 +1294,13 @@ int create_grant_host_mapping(unsigned long addr,
> unsigned long frame,
> int replace_grant_host_mapping(unsigned long addr, unsigned long mfn,
> unsigned long new_addr, unsigned int flags)
> {
> -unsigned long gfn = (unsigned long)(addr >> PAGE_SHIFT);
> +gfn_t gfn = _gfn(addr >> PAGE_SHIFT);
> struct domain *d = current->domain;
>
> if ( new_addr != 0 || (flags & GNTMAP_contains_pte) )
> return GNTST_general_error;
>
> -guest_physmap_remove_page(d, gfn, mfn, 0);
> +guest_physmap_remove_page(d, gfn, _mfn(mfn), 0);
>
> return GNTST_okay;
> }
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index ab0cb41..aa4e774 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1292,26 +1292,26 @@ int map_dev_mmio_region(struct domain *d,
> }
>
> int guest_physmap_add_entry(struct domain *d,
> -unsigned long gpfn,
> -unsigned long mfn,
> +gfn_t gfn,
> +mfn_t mfn,
> unsigned long page_order,
> p2m_type_t t)
> {
> return apply_p2m_changes(d, INSERT,
> - pfn_to_paddr(gpfn),
> - pfn_to_paddr(gpfn + (1 << page_order)),
> - pfn_to_paddr(mfn), MATTR_MEM, 0, t,
> + pfn_to_paddr(gfn_x(gfn)),
> + pfn_to_paddr(gfn_x(gfn) + (1 << page_order)),
> + pfn_to_paddr(mfn_x(mfn)), MATTR_MEM, 0, t,
> d->arch.p2m.default_access);
> }
>
> void guest_physmap_remove_page(struct domain *d,
> - unsigned long gpfn,
> - unsigned long mfn, unsigned int page_order)
> + gfn_t gfn,
> +
[Xen-devel] [PATCH v3 3/4] xen/init: Move initcall infrastructure into .init.data
Its contents is constant.
The ALIGN(32) is also dropped. On x86, there is nothing between it and a
larger alignment. On ARM, __init_end_efi is between the two, but its sole use
is to fill SizeOfRawData in the PE Section Table, and doesn't require any
specific alignment.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
v3:
* Expand the commit message
v2:
* New
---
xen/arch/arm/xen.lds.S | 14 ++
xen/arch/x86/xen.lds.S | 14 ++
xen/include/xen/init.h | 4 ++--
3 files changed, 14 insertions(+), 18 deletions(-)
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index b00ee81..b18c9c2 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -145,6 +145,12 @@ SECTIONS
*(.init.proc.info)
__proc_info_end = .;
+ __initcall_start = .;
+ *(.initcallpresmp.init)
+ __presmp_initcall_end = .;
+ *(.initcall1.init)
+ __initcall_end = .;
+
*(.init.data)
*(.init.data.rel)
*(.init.data.rel.*)
@@ -154,14 +160,6 @@ SECTIONS
*(.init_array)
__ctors_end = .;
} :text
- . = ALIGN(32);
- .initcall.init : {
- __initcall_start = .;
- *(.initcallpresmp.init)
- __presmp_initcall_end = .;
- *(.initcall1.init)
- __initcall_end = .;
- } :text
__init_end_efi = .;
. = ALIGN(STACK_SIZE);
__init_end = .;
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 2443b93..a1678d8 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -158,6 +158,12 @@ SECTIONS
*(.init.setup)
__setup_end = .;
+ __initcall_start = .;
+ *(.initcallpresmp.init)
+ __presmp_initcall_end = .;
+ *(.initcall1.init)
+ __initcall_end = .;
+
*(.init.data)
*(.init.data.rel)
*(.init.data.rel.*)
@@ -183,14 +189,6 @@ SECTIONS
*(.ctors)
__ctors_end = .;
} :text
- . = ALIGN(32);
- .initcall.init : {
- __initcall_start = .;
- *(.initcallpresmp.init)
- __presmp_initcall_end = .;
- *(.initcall1.init)
- __initcall_end = .;
- } :text
. = ALIGN(PAGE_SIZE);
__init_end = .;
diff --git a/xen/include/xen/init.h b/xen/include/xen/init.h
index b04bcf9..0afc430 100644
--- a/xen/include/xen/init.h
+++ b/xen/include/xen/init.h
@@ -61,9 +61,9 @@ typedef int (*initcall_t)(void);
typedef void (*exitcall_t)(void);
#define presmp_initcall(fn) \
-static initcall_t __initcall_##fn __init_call("presmp") = fn
+const static initcall_t __initcall_##fn __init_call("presmp") = fn
#define __initcall(fn) \
-static initcall_t __initcall_##fn __init_call("1") = fn
+const static initcall_t __initcall_##fn __init_call("1") = fn
#define __exitcall(fn) \
static exitcall_t __exitcall_##fn __exit_call = fn
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PULL 0/3] xen-20160622-tag
On 22 June 2016 at 12:47, Stefano Stabellini wrote: > The following changes since commit 6f1d2d1c5ad20d464705b17318cb7ca495f8078a: > > Merge remote-tracking branch 'remotes/stsquad/tags/pull-travis-20160621-1' > into staging (2016-06-21 15:19:58 +0100) > > are available in the git repository at: > > > git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160622-tag > > for you to fetch changes up to 25f8f6b4c295940ae5d83c19509353afc1dbc9a4: > > xen: move xen_sysdev to xen_backend.c (2016-06-22 11:28:42 +0100) > > > xen-20160622 Applied, thanks. -- PMM ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 4/8] xen: Use typesafe gfn in xenmem_add_to_physmap_one
On Tue, 21 Jun 2016, Julien Grall wrote:
> The x86 version of the function xenmem_add_to_physmap_one contains
> variable name gpfn and gfn which make the code very confusing.
> I have left unchanged for now.
>
> Also, rename gpfn to gfn in the ARM version as the latter is the correct
> acronym for a guest physical frame.
>
> Finally, remove the trailing whitespace around the changes.
>
> Signed-off-by: Julien Grall
> Acked-by: Jan Beulich
>
> ---
> Cc: Stefano Stabellini
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Konrad Rzeszutek Wilk
> Cc: Tim Deegan
> Cc: Wei Liu
>
> Changes in v3:
> - Add Jan's acked-by for non-ARM bits
> ---
> xen/arch/arm/mm.c| 10 +-
> xen/arch/x86/mm.c| 15 +++
> xen/common/memory.c | 6 +++---
> xen/include/xen/mm.h | 2 +-
> 4 files changed, 16 insertions(+), 17 deletions(-)
>
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 5ab9b75..6882d54 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1046,7 +1046,7 @@ int xenmem_add_to_physmap_one(
> unsigned int space,
> union xen_add_to_physmap_batch_extra extra,
> unsigned long idx,
> -xen_pfn_t gpfn)
> +gfn_t gfn)
I think there is a possible loss of information here: xen_pfn_t is
always uint64_t on both ARM and ARM64, while gfn_t is unsigned long with
its current definition. Or am I missing something?
In fact, given that ARM supports LPAE, shouldn't gfn by defined as
xen_pfn_t in terms of storage size (TYPE_SAFE(xen_pfn_t, gfn)) ?
> {
> unsigned long mfn = 0;
> int rc;
> @@ -1081,8 +1081,8 @@ int xenmem_add_to_physmap_one(
> else
> return -EINVAL;
> }
> -
> -d->arch.grant_table_gpfn[idx] = gpfn;
> +
> +d->arch.grant_table_gpfn[idx] = gfn_x(gfn);
Similarly grant_table_gpfn is an array of xen_pfn_t (uint64_t), while
gfn_x unboxes to the storage size of gfn (unsigned long).
> t = p2m_ram_rw;
>
> @@ -1145,7 +1145,7 @@ int xenmem_add_to_physmap_one(
> if ( extra.res0 )
> return -EOPNOTSUPP;
>
> -rc = map_dev_mmio_region(d, gpfn, 1, idx);
> +rc = map_dev_mmio_region(d, gfn_x(gfn), 1, idx);
> return rc;
>
> default:
> @@ -1153,7 +1153,7 @@ int xenmem_add_to_physmap_one(
> }
>
> /* Map at new location. */
> -rc = guest_physmap_add_entry(d, _gfn(gpfn), _mfn(mfn), 0, t);
> +rc = guest_physmap_add_entry(d, gfn, _mfn(mfn), 0, t);
>
> /* If we fail to add the mapping, we need to drop the reference we
> * took earlier on foreign pages */
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 7fbc94e..dbcf6cb 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4775,7 +4775,7 @@ int xenmem_add_to_physmap_one(
> unsigned int space,
> union xen_add_to_physmap_batch_extra extra,
> unsigned long idx,
> -xen_pfn_t gpfn)
> +gfn_t gpfn)
> {
> struct page_info *page = NULL;
> unsigned long gfn = 0; /* gcc ... */
> @@ -4834,7 +4834,7 @@ int xenmem_add_to_physmap_one(
> break;
> }
> case XENMAPSPACE_gmfn_foreign:
> -return p2m_add_foreign(d, idx, gpfn, extra.foreign_domid);
> +return p2m_add_foreign(d, idx, gfn_x(gpfn), extra.foreign_domid);
> default:
> break;
> }
> @@ -4849,19 +4849,18 @@ int xenmem_add_to_physmap_one(
> }
>
> /* Remove previously mapped page if it was present. */
> -prev_mfn = mfn_x(get_gfn(d, gpfn, &p2mt));
> +prev_mfn = mfn_x(get_gfn(d, gfn_x(gpfn), &p2mt));
> if ( mfn_valid(prev_mfn) )
> {
> if ( is_xen_heap_mfn(prev_mfn) )
> /* Xen heap frames are simply unhooked from this phys slot. */
> -guest_physmap_remove_page(d, _gfn(gpfn), _mfn(prev_mfn),
> - PAGE_ORDER_4K);
> +guest_physmap_remove_page(d, gpfn, _mfn(prev_mfn),
> PAGE_ORDER_4K);
> else
> /* Normal domain memory is freed, to avoid leaking memory. */
> -guest_remove_page(d, gpfn);
> +guest_remove_page(d, gfn_x(gpfn));
> }
> /* In the XENMAPSPACE_gmfn case we still hold a ref on the old page. */
> -put_gfn(d, gpfn);
> +put_gfn(d, gfn_x(gpfn));
>
> /* Unmap from old location, if any. */
> old_gpfn = get_gpfn_from_mfn(mfn);
> @@ -4872,7 +4871,7 @@ int xenmem_add_to_physmap_one(
> guest_physmap_remove_page(d, _gfn(old_gpfn), _mfn(mfn),
> PAGE_ORDER_4K);
>
> /* Map at new location. */
> -rc = guest_physmap_add_page(d, _gfn(gpfn), _mfn(mfn), PAGE_ORDER_4K);
> +rc = guest_physmap_add_page(d, gpfn, _mfn(mfn), PAGE_ORDER_4K);
>
> /* In the XENMAPSPACE_gmfn, we took a ref of the gfn at the top */
> if ( space == XENMAPSPACE_gmfn || space == XENMAPSPACE_gmfn_range )
> diff --git a/xen/common/memory.c b/xen/common/me
Re: [Xen-devel] [PATCH RESEND 1/4] x86emul: support MOVBE and CRC32
On 20/06/16 12:57, Jan Beulich wrote: > The former in an attempt to at least gradually support all simple data > movement instructions. The latter just because it shares the opcode > with the former. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] x86emul: fold local variables
On 20/06/16 12:59, Jan Beulich wrote: > Declare some variables to they can be used by multiple pieces of code, > allowing some figure braces to be dropped (which don't align nicely > when used inside of case labeled statements). > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.
On 23/06/16 08:37, Yu Zhang wrote: > On 6/22/2016 7:33 PM, George Dunlap wrote: >> On 22/06/16 11:07, Yu Zhang wrote: >>> >>> On 6/22/2016 5:47 PM, George Dunlap wrote: On 22/06/16 10:29, Jan Beulich wrote: On 22.06.16 at 11:16, wrote: >> On 22/06/16 07:39, Jan Beulich wrote: >> On 21.06.16 at 16:38, wrote: On 21/06/16 10:47, Jan Beulich wrote: > And then - didn't we mean to disable that part of XenGT during > migration, i.e. temporarily accept the higher performance > overhead without the p2m_ioreq_server entries? In which case > flipping everything back to p2m_ram_rw after (completed or > canceled) migration would be exactly what we want. The (new > or previous) ioreq server should attach only afterwards, and > can then freely re-establish any p2m_ioreq_server entries it > deems necessary. > Well, I agree this part of XenGT should be disabled during migration. But in such case I think it's device model's job to trigger the p2m type flipping(i.e. by calling HVMOP_set_mem_type). >>> I agree - this would seem to be the simpler model here, despite >>> (as >>> George validly says) the more consistent model would be for the >>> hypervisor to do the cleanup. Such cleanup would imo be >>> reasonable >>> only if there was an easy way for the hypervisor to enumerate >>> all >>> p2m_ioreq_server pages. >> Well, for me, the "easy way" means we should avoid traversing >> the whole ept >> paging structure all at once, right? > Yes. Does calling p2m_change_entry_type_global() not satisfy this requirement? >>> Not really - that addresses the "low overhead" aspect, but not the >>> "enumerate all such entries" one. >> I'm sorry, I think I'm missing something here. What do we need the >> enumeration for? > We'd need that if we were to do the cleanup in the hypervisor (as > we can't rely on all p2m entry re-calculation to have happened by > the time a new ioreq server registers for the type). So you're afraid of this sequence of events? 1) Server A de-registered, triggering a ioreq_server -> ram_rw type change 2) gfn N is marked as misconfigured 3) Server B registers and marks gfn N as ioreq_server 4) When N is accessed, the misconfiguration is resolved incorrectly to ram_rw But that can't happen, because misconfigured entries are resolved before setting a p2m entry; so at step 3, gfn N will be first set to (non-misconfigured) ram_rw, then changed to (non-misconfigured) ioreq_server. Or is there another sequence of events that I'm missing? >>> Thanks for your reply, George. :) >>> If no log dirty is triggered during this process, your sequence is >>> correct. >>> However, if log dirty is triggered, we'll met problems. I have described >>> this >>> in previous mails : >>> >>> http://lists.xenproject.org/archives/html/xen-devel/2016-06/msg02426.html >>> >>> on Jun 20 >>> >>> and >>> >>> http://lists.xenproject.org/archives/html/xen-devel/2016-06/msg02575.html >>> >>> on Jun 21 >> Right -- sorry, now I see the issue: >> >> 1. Server A marks gfn X as ioreq_server >> 2. Server A deregisters, gfn X misconfigured >> 3. Server B registers, marks gfn Y as ioreq_server >> 4. Logdirty mode enabled; gfn Y misconfigured >> 5. When X or Y are accessed, resolve_misconfigure() has no way of >> telling whether the entry is from server A (which should be set to >> logdirty) or from server B (which should be left as ioreq_server). > > Exactly. :) > Another simpler scenario would be > 1. Server A marks gfn X as p2m_ioreq_server; > 2. Logdirty mode enabled; gfn X misconfigured; > 3. When X is written, it will not cause ept vioalation, but ept > misconfig, and the > resolve_misconfig() would set gfn X back to p2m_ram_rw, thereafter we > can not > track access to X; Right, so this is a reason that simply making misconfigurations always resolve ioreq_server into ram_rw isn't compatible with logdirty. > Note: Not resetting the p2m type for p2m_ioreq_server when > p2m->ioreq_server is > not NULL is suitable for this simpler scenario, but is not correct if > take your scenario > into account. > > The core reason is I could not find a simple solution in > resolve_misconfig() to handle > handle both the outdated p2m_ioreq_server entries, the in-use ones and > to support > the logdirty feature at the same time. Indeed; and as I said, the real problem is that p2m_change_entry_type_global() isn't really properly abstracted; in order to use it you need to know how it works and be careful not to use it at the wrong time. Short-term, thinking through a handful of the scenarios we want to support should be good enough.
[Xen-devel] [qemu-mainline test] 96146: regressions - FAIL
flight 96146 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/96146/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 94856 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 94856 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 94856 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 94856 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 94856 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 94856 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 94856 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 94856 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94856 test-amd64-amd64-xl-rtds 9 debian-install fail like 94856 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass version targeted for testing: qemuu6f1d2d1c5ad20d464705b17318cb7ca495f8078a baseline version: qemuud6550e9ed2e1a60d889dfb721de00d9a4e3bafbe Last test of basis94856 2016-05-27 20:14:49 Z 26 days Failing since 94983 2016-05-31 09:40:12 Z 23 days 31 attempts Testing same since96109 2016-06-22 09:00:26 Z1 days2 attempts People who touched revisions under test: Alberto Garcia Alex Bennée Alex Bligh Alex Williamson Alexander Graf Alexey Kardashevskiy Alistair Francis Amit Shah Andrea Arcangeli Andrew Jeffery Andrew Jones Anthony PERARD Anton Blanchard Ard Biesheuvel Artyom Tarasenko Benjamin Herrenschmidt Bharata B Rao Cao jin Changlong Xie Chao Peng Chen Fan Christian Borntraeger Christophe Lyon Cole Robinson Colin Lord Corey Minyard Cornelia Huck Cédric Le Goater Daniel P. Berrange David Gibson David Hildenbrand Denis V. Lunev Dmitry Fleytman Dmitry Fleytman Dmitry Osipenko Dr. David Alan Gilbert Drew Jones Edgar E. Iglesias Eduardo Habkost Emilio G. Cota Eric Blake Fam Zheng Gavin Shan Gerd H
Re: [Xen-devel] [PATCH 2/4] x86emul: use (locally) consistent exit mechanisms
On 20/06/16 12:58, Jan Beulich wrote: > At least similar code should use similar exit mechanisms (return vs > goto). > > Signed-off-by: Jan Beulich > --- > RFC reason: There are many more paths where we could return directly, > avoiding the _put_fpu() and put_stub(). Otoh arguably the > two existing return-s around the changes below could also > be changed to "goto done" to restore consistency. > > Subsequently we may then want to consider to reduce the number of > "goto done" by checking rc right after at least the main switch() > statements. I think this patch goes in the wrong direction. Mixing exit mechanisms makes code harder to interpret, and x86_emulate() isn't the easiest function to edit. Using "goto done;" consistently would be a better option. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 1/3] xen: add warning infrastructure
On Wed, Jun 22, 2016 at 09:35:51AM -0600, Jan Beulich wrote:
> >>> On 20.06.16 at 18:30, wrote:
> > @@ -1582,6 +1583,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> >
> > init_constructors();
> >
> > +warning_print();
> > +
> > console_endboot();
>
> What about an ARM equivalent? Perhaps put this in console_endboot()?
>
Fine with putting this in console_endboot.
> > --- a/xen/common/Makefile
> > +++ b/xen/common/Makefile
> > @@ -59,6 +59,7 @@ obj-y += vm_event.o
> > obj-y += vmap.o
> > obj-y += vsprintf.o
> > obj-y += wait.o
> > +obj-y += warning.o
>
> And perhaps better to put the new code into the console code too?
> In any event if you want to keep this in a separate file, considering
> that all of it is code/data contributions to .init.*, this wants to be
>
I will keep a separate file, and ...
> obj-bin-y += warning.init.o
>
... use this.
> so that namely string literals get moved to .init.* too.
>
> > --- /dev/null
> > +++ b/xen/common/warning.c
> > @@ -0,0 +1,50 @@
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define WARNING_ARRAY_SIZE 20
> > +static unsigned int __initdata nr_warnings;
> > +static const char __initdata *warnings[WARNING_ARRAY_SIZE];
>
> The __initdata belongs after the *.
>
Fixed.
> > +void __init warning_add(const char *warning)
> > +{
> > +if ( nr_warnings >= WARNING_ARRAY_SIZE )
> > +panic("Too many pieces of warning text.");
>
> panic() seems a bit harsh, but this shouldn't trigger anyway.
>
> > +warnings[nr_warnings] = warning;
> > +nr_warnings++;
> > +}
> > +
> > +void __init warning_print(void)
> > +{
> > +unsigned int i, j;
> > +
> > +if ( !nr_warnings )
> > +return;
>
> Perhaps a single instance of the * separators could be printed
> here ...
>
> > +for ( i = 0; i < nr_warnings; i++ )
> > +printk("%s", warnings[i]);
>
> ... and here, avoiding each caller to add such?
>
The warning text (multiple lines) is added as one single string, which
means we can't trivially add leading stars at the beginning of each
line.
I don't feel like arguing over how the text would look like, so if
something like:
WARNING 1
WARNING 2
...
WARNING N
is ok to you, I'm fine with using that format, too.
Wei.
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 4/8] xen: Use typesafe gfn in xenmem_add_to_physmap_one
Hi Stefano,
On 23/06/16 11:20, Stefano Stabellini wrote:
On Tue, 21 Jun 2016, Julien Grall wrote:
The x86 version of the function xenmem_add_to_physmap_one contains
variable name gpfn and gfn which make the code very confusing.
I have left unchanged for now.
Also, rename gpfn to gfn in the ARM version as the latter is the correct
acronym for a guest physical frame.
Finally, remove the trailing whitespace around the changes.
Signed-off-by: Julien Grall
Acked-by: Jan Beulich
---
Cc: Stefano Stabellini
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Konrad Rzeszutek Wilk
Cc: Tim Deegan
Cc: Wei Liu
Changes in v3:
- Add Jan's acked-by for non-ARM bits
---
xen/arch/arm/mm.c| 10 +-
xen/arch/x86/mm.c| 15 +++
xen/common/memory.c | 6 +++---
xen/include/xen/mm.h | 2 +-
4 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 5ab9b75..6882d54 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1046,7 +1046,7 @@ int xenmem_add_to_physmap_one(
unsigned int space,
union xen_add_to_physmap_batch_extra extra,
unsigned long idx,
-xen_pfn_t gpfn)
+gfn_t gfn)
I think there is a possible loss of information here: xen_pfn_t is
always uint64_t on both ARM and ARM64, while gfn_t is unsigned long with
its current definition. Or am I missing something?
In fact, given that ARM supports LPAE, shouldn't gfn by defined as
xen_pfn_t in terms of storage size (TYPE_SAFE(xen_pfn_t, gfn)) ?
With LPAE, ARM32 supports up to 40-bit PA so the frame will be encoded
on 28-bit. So unsigned long is perfectly fine here.
Note that the truncation already occurs in subsequent caller because we
are using unsigned long for the P2M parameters.
{
unsigned long mfn = 0;
int rc;
@@ -1081,8 +1081,8 @@ int xenmem_add_to_physmap_one(
else
return -EINVAL;
}
-
-d->arch.grant_table_gpfn[idx] = gpfn;
+
+d->arch.grant_table_gpfn[idx] = gfn_x(gfn);
Similarly grant_table_gpfn is an array of xen_pfn_t (uint64_t), while
gfn_x unboxes to the storage size of gfn (unsigned long).
Patch #5 will switch grant_table_gpfn to an array of gfn_t.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] xen: sched: rtds refactor code
On 22/06/16 17:16, Meng Xu wrote:
> On Wed, Jun 22, 2016 at 11:51 AM, George Dunlap
> wrote:
>> On Mon, May 16, 2016 at 12:54 AM, Tianyang Chen wrote:
>>> No functional change:
>>> -Various coding style fix
>>> -Added comments for UPDATE_LIMIT_SHIFT.
>>>
>>> Signed-off-by: Tianyang Chen
>>
>> Hey Tianyang,
>>
>> The changes here for the most part look good (with a few comments --
>> see below), but the title and changelog could use some work.
>>
>> For one, you're not actually doing any refactoring -- I'd call this
>> patch a "clean-up" patch.
>>
>> Secondly, you should go through and enumerate the different clean-ups
>> you do. For instance, you mention why you remove the __ at the head
>> of functions in your cover letter, but you don't mention it here.
>>
>>> ---
>>> xen/common/sched_rt.c | 106
>>> ++---
>>> 1 file changed, 56 insertions(+), 50 deletions(-)
>>>
>>> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
>>> index 7f8f411..1584d53 100644
>>> --- a/xen/common/sched_rt.c
>>> +++ b/xen/common/sched_rt.c
>>> @@ -80,7 +80,7 @@
>>> * in schedule.c
>>> *
>>> * The functions involes RunQ and needs to grab locks are:
>>> - *vcpu_insert, vcpu_remove, context_saved, __runq_insert
>>> + *vcpu_insert, vcpu_remove, context_saved, runq_insert
>>> */
>>>
>>>
>>> @@ -107,6 +107,12 @@
>>> */
>>> #define RTDS_MIN_BUDGET (MICROSECS(10))
>>>
>>> +/*
>>> + * UPDATE_LIMIT_SHIT: a constant used in rt_update_deadline(). When finding
>>
>> Missing an 'F'. :-)
>
> Ah, my bad.. I should have caught these typos. :-(
>
>>
>>> + * the next deadline, performing addition could be faster if the difference
>>> + * between cur_deadline and now is small. If the difference is bigger than
>>> + * 1024 * period, use multiplication.
>>> + */
>>> #define UPDATE_LIMIT_SHIFT 10
>>>
>>> /*
>>> @@ -158,25 +164,25 @@
>>> static void repl_timer_handler(void *data);
>>>
>>> /*
>>> - * Systme-wide private data, include global RunQueue/DepletedQ
>>> + * System-wide private data, include global RunQueue/DepletedQ
>>> * Global lock is referenced by schedule_data.schedule_lock from all
>>> * physical cpus. It can be grabbed via vcpu_schedule_lock_irq()
>>> */
>>> struct rt_private {
>>> -spinlock_t lock;/* the global coarse grand lock */
>>> -struct list_head sdom; /* list of availalbe domains, used for
>>> dump */
>>> -struct list_head runq; /* ordered list of runnable vcpus */
>>> -struct list_head depletedq; /* unordered list of depleted vcpus */
>>> -struct list_head replq; /* ordered list of vcpus that need
>>> replenishment */
>>> -cpumask_t tickled; /* cpus been tickled */
>>> -struct timer *repl_timer; /* replenishment timer */
>>> +spinlock_t lock; /* the global coarse grand lock */
>>
>> * course-grained
>>
>> Also, I'm not sure what the point of indenting all these comments out
>> an extra space is. I don't object, of course, if Meng doesn't object,
>> but at very least it could use a one-line explanation in the
>> changelog.
>
> I think he is trying to align those comments to make them start from
> the same column. I was confused at the reason at the very beginning.
> Then I pulled his repo and checked this change.
Right -- well neither you as a reviewer nor anyone in the future looking
back at this changeset should have to try to guess what the purpose was;
if he did want to align them, that's perfectly fine, it just needs a
brief mention in the changelog. :-)
-George
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] x86emul: drop pointless and add useful default cases
On 20/06/16 12:58, Jan Beulich wrote: > @@ -3845,10 +3834,11 @@ x86_emulate( > goto push; > case 7: > generate_exception_if(1, EXC_UD, -1); > -default: > -goto cannot_emulate; > } > break; > + > +default: > +BUG(); These introduce DoS vulnerabilities if there is indeed a path to default. Could I recommend instead a one-time printk() dumping the instruction stream which lead to here, an ASSERT_UNREACHABLE(), and a goto cannot_emulate? That way, a production build won't crash. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/3] console: use warning infrastructure for sync console warning
On Wed, Jun 22, 2016 at 09:37:55AM -0600, Jan Beulich wrote:
> >>> On 20.06.16 at 18:30, wrote:
> > @@ -44,6 +44,14 @@ string_param("conswitch", opt_conswitch);
> > /* sync_console: force synchronous console output (useful for debugging).
> > */
> > static bool_t __initdata opt_sync_console;
> > boolean_param("sync_console", opt_sync_console);
> > +static const char __initconst *warning_sync_console =
>
> static const char __initconst warning_sync_console[] =
>
Fixed.
Wei.
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 3/3] xen: make available hvm_fep to non-debug build as well
On Wed, Jun 22, 2016 at 09:42:38AM -0600, Jan Beulich wrote:
> >>> On 20.06.16 at 18:30, wrote:
> > @@ -97,9 +98,17 @@ boolean_param("hap", opt_hap_enabled);
> >
> > #ifndef opt_hvm_fep
> > /* Permit use of the Forced Emulation Prefix in HVM guests */
> > -bool_t opt_hvm_fep;
> > +bool_t __read_mostly opt_hvm_fep;
> > boolean_param("hvm_fep", opt_hvm_fep);
> > #endif
> > +static const char __initconst *warning_hvm_fep =
> > +"**\n"
> > +"*** WARNING: HVM FORCED EMULATION PREFIX IS AVAILABLE\n"
> > +"*** This option is *ONLY* intended to aid testing of Xen.\n"
> > +"*** It has implications on the security of the system.\n"
> > +"*** Please *DO NOT* use this in production.\n"
> > +"**\n";
> > +
> >
>
> Along with the same comment as on patch 2, here even more than
> there I wonder whether this string wouldn't better be a static local
> in hvm_enable() (or even the scope therein where warning_add()
> gets invoked).
>
I would rather the text stays next to where the option is defined so
it is obvious to anyone who touches this area of code.
> Also adding a stray blank line.
>
Fixed. Also fixed the issue mentioned in patch 2.
Wei.
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events
Hello,
On 22/06/16 18:17, Julien Grall wrote:
On 22/06/16 17:35, Corneliu ZUZU wrote:
Julien,
Hello Corneliu,
I was trying to implement having HCR stored in arch_domain or arch_vcpu
as suggested above and I'm a bit confused about the code in
p2m_restore_state.
I'm hoping you can provide some feedback on this matter. Here's the
current implementation of the function:
void p2m_restore_state(struct vcpu *n)
{
register_t hcr;
hcr = READ_SYSREG(HCR_EL2);
WRITE_SYSREG(hcr & ~HCR_VM, HCR_EL2);
isb();
p2m_load_VTTBR(n->domain);
isb();
if ( is_32bit_domain(n->domain) )
hcr &= ~HCR_RW;
else
hcr |= HCR_RW;
WRITE_SYSREG(n->arch.sctlr, SCTLR_EL1);
isb();
WRITE_SYSREG(hcr, HCR_EL2);
isb();
}
First of all, I see the HCR_VM bit being unset (=0) but I don't quite
understand why and even more peculiar is the fact that I couldn't find
any place where the bit is set (=1) again.
After the first write to HCR_EL2, "hcr" still have the VM bit set as we
only mask it. So the second write will re-set the VM bit.
I am not sure why the VM bit is unset/set in this function. I am not
able to find a paragraph justifying it in the ARM ARM. I have CCed some
ARM folks to check if I missed something.
After talking with different ARM folks, I confirm that it is not
necessary to disable the HCR_VM before setting TTBR0.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 7/7] vm-event/arm: implement support for control-register write vm-events
Hello,
On 23/06/16 06:49, Corneliu ZUZU wrote:
On 6/23/2016 8:31 AM, Corneliu ZUZU wrote:
On 6/22/2016 10:41 PM, Julien Grall wrote:
On 22/06/2016 20:37, Corneliu ZUZU wrote:
I've also realized that it's a bit complicated to avoid writing HCR
from
2 places.
That's because:
- p2m_restore_state is part of the process of switching to another vCPU
and the HCR write _must be committed_ here because other components
depend on that, like address-translation functions
- I want vm_event_vcpu_enter to be called _after_ the switch to the
vCPU
is completed
- I want HCR_TVM to be set in vm_event_vcpu_enter because setting
necessary traps _for cr vm-events_ to work should be done there
(setting
HCR_TVM bit makes sense to be there and the purpose is to centralize
operations such as this for code comprehensibility; also, on the X86
counterpart a similar operation is done for trapping CR3, so it
would be
nice to keep the symmetry)
Would it be such a stretch to have HCR written in 2 places? (the second
time happens rarely anyway: it's unlikely(..) to have to do the
write in
vm_event_vcpu_enter)
Not really. It was mostly to avoid setting/clearing HCR bits in
different place in the code. It makes more difficult to know what is
the final result of the register.
Anyway, let's skip it for now, if it is too difficult.
Regards,
Then perhaps something like the following would be suitable:
1. store hcr in arch_domain (register_t hcr)
2. add a function in asm-arm/processor.h (or where else?) which only
does:
static inline void update_hcr(struct domain *d)
{
WRITE_SYSREG(d->arch.hcr, HCR_EL2);
isb();
}
3. modify p2m_restore_state to do:
n->domain->arch.hcr &= ~HCR_VM;
update_hcr(n->domain);
p2m_load_VTTBR(n->domain);
n->domain->arch.hcr |= HCR_VM;
if ( is_32bit_domain(n->domain) )
n->domain->arch.hcr &= ~HCR_RW;
else
n->domain->arch.hcr |= HCR_RW;
This is not safe at all, p2m_restore_state is vCPU specific at you
modify domain information.
However, if we store the hcr per domain, overriding every context switch
is pointless as the domain will always be 32-bit/64-bit.
update_hcr(n->domain);
WRITE_SYSREG(n->arch.sctlr, SCTLR_EL1);
isb();
4. and vcpu_enter_adjust_traps to
if ( unlikely(0 != v->domain->arch.monitor.write_ctrlreg_enabled) )
{
if ( likely(v->domain->arch.hcr & HCR_TVM) )
return;
v->domain->arch.hcr |= HCR_TVM;
}
else
{
if ( likely(!(v->domain->arch.hcr & HCR_TVM)) )
return;
v->domain->arch.hcr &= ~HCR_TVM;
}
This does not need to be done in vcpu_enter_adjust_traps everytime. You
can set the bit in arch.hcr in DOMCTL_MONITOR_EVENT_WRITE_CTRLREG.
update_hcr(v->domain);
That way at least it's easier to follow where update_hcr is called.
I don't see much reason to store the value in the domain and have
multiple update_hcr. If we store the value, then we should only call
update_hcr once when returning to the guest.
And also set the initial value of HCR at the moment of creation, i.e. in
arch_domain_create as
d->arch.hcr = READ_SYSREG(HCR_EL2)
We control the value of HCR_EL2, so it would be better to assign the
list of flags here.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 96157: tolerable FAIL - PUSHED
flight 96157 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96157/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass
test-armhf-armhf-libvirt 14 guest-saverestorefail never pass
test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass
test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail never pass
test-amd64-i386-libvirt 12 migrate-support-checkfail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass
version targeted for testing:
libvirt 03ce1328086d6937d2647d616efff29941a3e80a
baseline version:
libvirt f06e45d57882869bcde4bf780fb12b4c512fdd92
Last test of basis96095 2016-06-22 04:30:55 Z1 days
Testing same since96157 2016-06-23 04:24:23 Z0 days1 attempts
People who touched revisions under test:
Cole Robinson
Jim Fehlig
Jiri Denemark
Ján Tomko
Peter Krempa
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-armhf-pvopspass
build-i386-pvops pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm fail
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt pass
test-amd64-amd64-libvirt-pairpass
test-amd64-i386-libvirt-pair pass
test-armhf-armhf-libvirt-qcow2 fail
test-armhf-armhf-libvirt-raw fail
test-amd64-amd64-libvirt-vhd pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=libvirt
+ revision=03ce1328086d6937d2647d616efff29941a3e80a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push libvirt
03ce1328086d6937d2647d616efff29941a3e80a
+
Re: [Xen-devel] [PATCH v3 1/3] xen: add warning infrastructure
On Thu, Jun 23, 2016 at 11:37:43AM +0100, Wei Liu wrote: [...] > The warning text (multiple lines) is added as one single string, which > means we can't trivially add leading stars at the beginning of each > line. > > I don't feel like arguing over how the text would look like, so if > something like: > > > WARNING 1 > > WARNING 2 > > ... > > WARNING N > > > is ok to you, I'm fine with using that format, too. Here is an example for how it looks like at the moment. Feels OK to me. (XEN) *** (XEN) WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) This option is intended to aid debugging of Xen by ensuring (XEN) that all output is synchronously delivered on the serial line. (XEN) However it can introduce SIGNIFICANT latencies and affect (XEN) timekeeping. It is NOT recommended for production use! (XEN) *** (XEN) WARNING: HVM FORCED EMULATION PREFIX IS AVAILABLE (XEN) This option is *ONLY* intended to aid testing of Xen. (XEN) It has implications on the security of the system. (XEN) Please *DO NOT* use this in production. (XEN) *** ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 1/3] xen: add warning infrastructure
On 23/06/16 12:17, Wei Liu wrote: > On Thu, Jun 23, 2016 at 11:37:43AM +0100, Wei Liu wrote: > [...] >> The warning text (multiple lines) is added as one single string, which >> means we can't trivially add leading stars at the beginning of each >> line. >> >> I don't feel like arguing over how the text would look like, so if >> something like: >> >> >> WARNING 1 >> >> WARNING 2 >> >> ... >> >> WARNING N >> >> >> is ok to you, I'm fine with using that format, too. > Here is an example for how it looks like at the moment. Feels OK to me. > > (XEN) *** > (XEN) WARNING: CONSOLE OUTPUT IS SYNCHRONOUS > (XEN) This option is intended to aid debugging of Xen by ensuring > (XEN) that all output is synchronously delivered on the serial line. > (XEN) However it can introduce SIGNIFICANT latencies and affect > (XEN) timekeeping. It is NOT recommended for production use! > (XEN) *** > (XEN) WARNING: HVM FORCED EMULATION PREFIX IS AVAILABLE > (XEN) This option is *ONLY* intended to aid testing of Xen. > (XEN) It has implications on the security of the system. > (XEN) Please *DO NOT* use this in production. > (XEN) *** LGTM. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.3-testing test] 96150: regressions - FAIL
flight 96150 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/96150/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt5 libvirt-build fail REGR. vs. 87893 build-amd64-libvirt 5 libvirt-build fail REGR. vs. 87893 build-armhf 5 xen-build fail REGR. vs. 87893 test-amd64-i386-xend-qemut-winxpsp3 9 windows-installfail REGR. vs. 87893 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail pass in 96118 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 87893 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 87893 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 87893 Tests which did not succeed, but are not blocking: build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass build-amd64-rumpuserxen 6 xen-buildfail never pass build-i386-rumpuserxen6 xen-buildfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass version targeted for testing: xen 0a8c94fae993dd8f2b27fd4cc694f61c21de84bf baseline version: xen 8fa31952e2d08ef63897c43b5e8b33475ebf5d93 Last test of basis87893 2016-03-29 13:49:52 Z 85 days Failing since 92180 2016-04-20 17:49:21 Z 63 days 26 attempts Testing same since96017 2016-06-20 17:22:27 Z2 days5 attempts People who touched revisions under test: Andrew Cooper Anthony Liguori Anthony PERARD Gerd Hoffmann Ian Jackson Jan Beulich Jim Paris Stefan Hajnoczi Tim Deegan Wei Liu jobs: build-amd64 pass build-armhf fail build-i386 pass build-amd64-libvirt fail build-armhf-libvirt blocked build-i386-libvirt fail build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-armhf-armhf-xl blocked test-amd64-i386-xl pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64fail test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386
[Xen-devel] Do people want a Developer Meeting on Aug 24th (before Dev Summit)
Folks, do you guys want to hold a Developer Meeting on Aug 24th (before Dev Summit). I do have space to do this, but last year's was very poorly attended. If you could get back to me with an opinion, that would help hugely. Alternatively it would also be possible to use the space for more focused meetings with fewer people. In that case, I would need a number of suggestions for meetings including meeting leaders. Please have a look at the schedule http://events.linuxfoundation.org/events/xen-project-developer-summit/program/schedule ... note that on the 26th, I kept the 2nd room free and was planning to use the Hackathon format in parallel to the talks in the main program. rather than having BoFs interspersed with talks. Some of the slots could be used to host the developer meeting, of desired. Regards Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] ArmVirtPkg/ArmVirtXen: Add ACPI support for Virt Xen ARM
From: Shannon Zhao
Add ACPI support for Virt Xen ARM and only for aarch64. It gets the
ACPI tables through Xen ARM multiboot protocol.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Shannon Zhao
---
Changes since v1:
* move the codes into ArmVirtPkg
* use FdtClient
* don't rely on OvmfPkg/AcpiPlatformDxe/EntryPoint.c while implement own
entry point since it's minor
* use compatible string to find the DT node instead of node path
If you want to test, the corresponding Xen patches can be fetched from:
https://git.linaro.org/people/shannon.zhao/xen.git domu_acpi_v2
---
ArmVirtPkg/ArmVirtXen.dsc | 8 +
ArmVirtPkg/ArmVirtXen.fdf | 8 +
ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c | 241 +
.../XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf | 49 +
4 files changed, 306 insertions(+)
create mode 100644 ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
create mode 100644 ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
index 594ca64..a869986 100644
--- a/ArmVirtPkg/ArmVirtXen.dsc
+++ b/ArmVirtPkg/ArmVirtXen.dsc
@@ -216,3 +216,11 @@
OvmfPkg/XenBusDxe/XenBusDxe.inf
OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+
+ #
+ # ACPI support
+ #
+!if $(ARCH) == AARCH64
+ MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
+ ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
+!endif
diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
index 13412f9..b1e00e5 100644
--- a/ArmVirtPkg/ArmVirtXen.fdf
+++ b/ArmVirtPkg/ArmVirtXen.fdf
@@ -179,6 +179,14 @@ READ_LOCK_STATUS = TRUE
INF OvmfPkg/XenBusDxe/XenBusDxe.inf
INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+ #
+ # ACPI support
+ #
+!if $(ARCH) == AARCH64
+ INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
+ INF ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
+!endif
+
[FV.FVMAIN_COMPACT]
FvAlignment= 16
ERASE_POLARITY = 1
diff --git a/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
new file mode 100644
index 000..9258be8
--- /dev/null
+++ b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
@@ -0,0 +1,241 @@
+/** @file
+ Xen ARM ACPI Platform Driver using Xen ARM multiboot protocol
+
+ Copyright (C) 2016, Linaro Ltd. All rights reserved.
+
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD
License
+ which accompanies this distribution. The full text of the license may be
found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *XenAcpiRsdpStructurePtr = NULL;
+
+/**
+ Get the address of Xen ACPI Root System Description Pointer (RSDP)
+ structure.
+
+ @param RsdpStructurePtr Return pointer to RSDP structure
+
+ @return EFI_SUCCESSFind Xen RSDP structure successfully.
+ @return EFI_NOT_FOUND Don't find Xen RSDP structure.
+ @return EFI_ABORTEDFind Xen RSDP structure, but it's not integrated.
+
+**/
+EFI_STATUS
+EFIAPI
+GetXenArmAcpiRsdp (
+ OUT EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER **RsdpPtr
+ )
+{
+ EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *RsdpStructurePtr;
+ EFI_STATUS Status;
+ FDT_CLIENT_PROTOCOL*FdtClient;
+ CONST UINT64 *Reg;
+ UINT32 RegElemSize, RegSize;
+ UINT64 RegBase;
+ UINT8 Sum;
+
+ RsdpStructurePtr = NULL;
+ //
+ // Get the RSDP structure address from DeviceTree
+ //
+ Status = gBS->LocateProtocol (&gFdtClientProtocolGuid, NULL,
+ (VOID **)&FdtClient);
+ ASSERT_EFI_ERROR (Status);
+
+ Status = FdtClient->FindCompatibleNodeReg (FdtClient, "xen,guest-acpi",
+(CONST VOID **)&Reg, &RegElemSize, &RegSize);
+ if (EFI_ERROR (Status)) {
+DEBUG ((EFI_D_WARN, "%a: No 'xen,guest-acpi' compatible DT node found\n",
+ __FUNCTION__));
+return EFI_NOT_FOUND;
+ }
+
+ ASSERT (RegSize == 2 * sizeof (UINT64));
+
+ RegBase = SwapBytes64(Reg[0]);
+ RsdpStructurePtr = (EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *)RegBase;
+
+ if (RsdpStructurePtr && RsdpStructurePtr->Revision >= 2) {
+Sum = CalculateSum8 ((CONST UINT8 *)RsdpStructurePtr,
+sizeof (EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER));
+if (Sum != 0) {
+ return EFI_ABORTED;
+}
+ }
+
+ *RsdpPtr = RsdpStructurePtr;
+ return EFI_SUCCESS;
+}
+
+/**
+ Get Xen Acpi tables from the RSDP
Re: [Xen-devel] Do people want a Developer Meeting on Aug 24th (before Dev Summit)
On 23/06/16 12:33, Lars Kurth wrote: > Folks, > > do you guys want to hold a Developer Meeting on Aug 24th (before Dev Summit). > I do have space to do this, but last year's was very poorly attended. If you > could get back to me with an opinion, that would help hugely. Alternatively > it would also be possible to use the space for more focused meetings with > fewer people. In that case, I would need a number of suggestions for meetings > including meeting leaders. > > Please have a look at the schedule > http://events.linuxfoundation.org/events/xen-project-developer-summit/program/schedule > ... note that on the 26th, I kept the 2nd room free and was planning to use > the Hackathon format in parallel to the talks in the main program. rather > than having BoFs interspersed with talks. Some of the slots could be used to > host the developer meeting, of desired. So to a large degree, the actual nuts-and-bolts planning which that meeting was meant to cover happens now at the "hackathons" instead. It's important I think, however, for the XenSummit to have a venue for people in the industry who may not know about the Hackathons (or for whatever reason can't come to them) to raise issues with the core developers and have them discussed. If the parallel track could actually fulfill that role, then I think it would be enough; the key would be making sure that the appropriate attention could be attracted. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/4] xen/init: Annotate all command line parameter infrastructure as const
Hi Andrew, On 21/06/16 17:59, Andrew Cooper wrote: There is no reason for any of it to be modified. Additionally, link .init.setup beside the other constant .init data. While editing this area, correct the types used in the extern declarations for __setup_start and __setup_end to match the types the linker actually produces. No functional change. Signed-off-by: Andrew Cooper For the ARM bits: Acked-by: Julien Grall Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/4] arm/init: Move .init.proc.info into .init.data
Hi Andrew, On 21/06/16 17:59, Andrew Cooper wrote: Its contents is constant, and only requires pointer alignment, so move it adacent to .init.setup. Signed-off-by: Andrew Cooper Acked-by: Julien Grall Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 3/4] xen/init: Move initcall infrastructure into .init.data
Hi Andrew, On 23/06/16 11:12, Andrew Cooper wrote: Its contents is constant. The ALIGN(32) is also dropped. On x86, there is nothing between it and a larger alignment. On ARM, __init_end_efi is between the two, but its sole use is to fill SizeOfRawData in the PE Section Table, and doesn't require any specific alignment. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich For ARM bits: Acked-by: Julien Grall Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Do people want a Developer Meeting on Aug 24th (before Dev Summit)
On Thu, Jun 23, 2016 at 12:33:00PM +0100, Lars Kurth wrote: > Folks, > > do you guys want to hold a Developer Meeting on Aug 24th (before Dev > Summit). I do have space to do this, but last year's was very poorly > attended. If you could get back to me with an opinion, that would help > hugely. Alternatively it would also be possible to use the space for > more focused meetings with fewer people. In that case, I would need a > number of suggestions for meetings including meeting leaders. > > Please have a look at the schedule > http://events.linuxfoundation.org/events/xen-project-developer-summit/program/schedule > ... note that on the 26th, I kept the 2nd room free and was planning > to use the Hackathon format in parallel to the talks in the main > program. rather than having BoFs interspersed with talks. Some of the > slots could be used to host the developer meeting, of desired. > Last year's meeting didn't attract many attendees but we did have important f2f discussions regarding release cycle, planning for certain features etc. I think overall it was quite useful. The number of attendees is not the mostly important metric imho. Ultimately my goal is to make sure we allocate some time for face to face conversation. I think having the unconference sessions are probably fine. As George said, the key is to attract appropriate attention. Wei. > Regards Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv3] x86/xen: avoid m2p lookup when setting early page table entries
On 06/23/2016 05:51 AM, David Vrabel wrote: When page tables entries are set using xen_set_pte_init() during early boot there is no page fault handler that could handle a fault when performing an M2P lookup. In 64 bit guests (usually dom0) early_ioremap() would fault in xen_set_pte_init() because an M2P lookup faults because the MFN is in MMIO space and not mapped in the M2P. This lookup is done to see if the PFN in in the range used for the initial page table pages, so that the PTE may be set as read-only. The M2P lookup can be avoided by moving the check (and clear of RW) earlier when the PFN is still available. Signed-off-by: David Vrabel --- Cc: Kevin Moraga Reviewed-by: Boris Ostrovsky ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv3] x86/xen: avoid m2p lookup when setting early page table entries
On 23/06/16 11:51, David Vrabel wrote:
> When page tables entries are set using xen_set_pte_init() during early
> boot there is no page fault handler that could handle a fault when
> performing an M2P lookup.
>
> In 64 bit guests (usually dom0) early_ioremap() would fault in
> xen_set_pte_init() because an M2P lookup faults because the MFN is in
> MMIO space and not mapped in the M2P. This lookup is done to see if
> the PFN in in the range used for the initial page table pages, so that
> the PTE may be set as read-only.
>
> The M2P lookup can be avoided by moving the check (and clear of RW)
> earlier when the PFN is still available.
>
> Signed-off-by: David Vrabel
> ---
> Cc: Kevin Moraga
>
> v3:
> - fold mask_rw_pte()/mask_rw_pteval() into their callers.
>
> v2:
> - Remove __init annotation from xen_make_pte_init() since
> PV_CALLEE_SAVE_REGS_THUNK always puts the thunk in .text.
>
> - mask_rw_pte() -> mask_rw_pteval() for x86-64.
> ---
> arch/x86/xen/mmu.c | 76
> +-
> 1 file changed, 35 insertions(+), 41 deletions(-)
>
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 478a2de..64d8f0b 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1551,41 +1551,6 @@ static void xen_pgd_free(struct mm_struct *mm, pgd_t
> *pgd)
> #endif
> }
>
> -#ifdef CONFIG_X86_32
> -static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
> -{
> - /* If there's an existing pte, then don't allow _PAGE_RW to be set */
> - if (pte_val_ma(*ptep) & _PAGE_PRESENT)
> - pte = __pte_ma(((pte_val_ma(*ptep) & _PAGE_RW) | ~_PAGE_RW) &
> -pte_val_ma(pte));
> -
> - return pte;
> -}
> -#else /* CONFIG_X86_64 */
> -static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
> -{
> - unsigned long pfn;
> -
> - if (xen_feature(XENFEAT_writable_page_tables) ||
> - xen_feature(XENFEAT_auto_translated_physmap) ||
> - xen_start_info->mfn_list >= __START_KERNEL_map)
> - return pte;
> -
> - /*
> - * Pages belonging to the initial p2m list mapped outside the default
> - * address range must be mapped read-only. This region contains the
> - * page tables for mapping the p2m list, too, and page tables MUST be
> - * mapped read-only.
> - */
> - pfn = pte_pfn(pte);
> - if (pfn >= xen_start_info->first_p2m_pfn &&
> - pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_frames)
> - pte = __pte_ma(pte_val_ma(pte) & ~_PAGE_RW);
> -
> - return pte;
> -}
> -#endif /* CONFIG_X86_64 */
> -
> /*
> * Init-time set_pte while constructing initial pagetables, which
> * doesn't allow RO page table pages to be remapped RW.
> @@ -1600,13 +1565,41 @@ static pte_t __init mask_rw_pte(pte_t *ptep, pte_t
> pte)
> * so always write the PTE directly and rely on Xen trapping and
> * emulating any updates as necessary.
> */
> -static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
> +__visible pte_t xen_make_pte_init(pteval_t pte)
> {
> - if (pte_mfn(pte) != INVALID_P2M_ENTRY)
> - pte = mask_rw_pte(ptep, pte);
> - else
> - pte = __pte_ma(0);
> +#ifdef CONFIG_X86_64
> + unsigned long pfn;
> +
> + /*
> + * Pages belonging to the initial p2m list mapped outside the default
> + * address range must be mapped read-only. This region contains the
> + * page tables for mapping the p2m list, too, and page tables MUST be
> + * mapped read-only.
> + */
> + pfn = (pte & PTE_PFN_MASK) >> PAGE_SHIFT;
> + if (xen_start_info->mfn_list < __START_KERNEL_map &&
> + pfn >= xen_start_info->first_p2m_pfn &&
> + pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_frames)
> + pte &= ~_PAGE_RW;
> +#endif
> + pte = pte_pfn_to_mfn(pte);
>
> + if ((pte & PTE_PFN_MASK) >> PAGE_SHIFT == INVALID_P2M_ENTRY)
How can this ever be true? I know this is just the open coded
variant form the original xen_set_pte_init(). Either the if isn't
needed at all or it should be corrected.
> + pte = 0;
> +
> + return native_make_pte(pte);
> +}
> +PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte_init);
> +
> +static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
> +{
> +#ifdef CONFIG_X86_32
> + /* If there's an existing pte, then don't allow _PAGE_RW to be set */
> + if (pte_mfn(pte) != INVALID_P2M_ENTRY
> + && pte_val_ma(*ptep) & _PAGE_PRESENT)
Even more obvious: do we really create ptes with INVALID_P2M_ENTRY and
_PAGE_PRESENT? I think the first part of the if can be dropped again.
Juergen
> + pte = __pte_ma(((pte_val_ma(*ptep) & _PAGE_RW) | ~_PAGE_RW) &
> +pte_val_ma(pte));
> +#endif
> native_set_pte(ptep, pte);
> }
>
> @@ -2407,6 +2400,7 @@ static void __init xen_post_allocator_init(void)
> pv_mmu_ops.alloc_pud = xen_alloc_pud;
> pv_mmu_ops.release_pud =
Re: [Xen-devel] [PATCH v3 1/3] xen: add warning infrastructure
>>> On 23.06.16 at 13:17, wrote: > On Thu, Jun 23, 2016 at 11:37:43AM +0100, Wei Liu wrote: > [...] >> The warning text (multiple lines) is added as one single string, which >> means we can't trivially add leading stars at the beginning of each >> line. >> >> I don't feel like arguing over how the text would look like, so if >> something like: >> >> >> WARNING 1 >> >> WARNING 2 >> >> ... >> >> WARNING N >> >> >> is ok to you, I'm fine with using that format, too. > > Here is an example for how it looks like at the moment. Feels OK to me. > > (XEN) *** > (XEN) WARNING: CONSOLE OUTPUT IS SYNCHRONOUS > (XEN) This option is intended to aid debugging of Xen by ensuring > (XEN) that all output is synchronously delivered on the serial line. > (XEN) However it can introduce SIGNIFICANT latencies and affect > (XEN) timekeeping. It is NOT recommended for production use! > (XEN) *** > (XEN) WARNING: HVM FORCED EMULATION PREFIX IS AVAILABLE > (XEN) This option is *ONLY* intended to aid testing of Xen. > (XEN) It has implications on the security of the system. > (XEN) Please *DO NOT* use this in production. > (XEN) *** Looks good, thanks. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Xen 4.6.3 released
All, I am pleased to announce the release of Xen 4.6.3. This is available immediately from its git repository http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.6 (tag RELEASE-4.6.3) or from the XenProject download page http://www.xenproject.org/downloads/xen-archives/xen-46-series/xen-463.html (where a list of changes can also be found). We recommend all users of the 4.6 stable series to update to this latest point release. Note regarding 4.6.2: An issue was found late in the release process, after one of the affected qemu trees was already tagged. We therefore decided to skip version 4.6.2. Regards, Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 3/3] xen: make available hvm_fep to non-debug build as well
>>> On 23.06.16 at 12:50, wrote:
> On Wed, Jun 22, 2016 at 09:42:38AM -0600, Jan Beulich wrote:
>> >>> On 20.06.16 at 18:30, wrote:
>> > @@ -97,9 +98,17 @@ boolean_param("hap", opt_hap_enabled);
>> >
>> > #ifndef opt_hvm_fep
>> > /* Permit use of the Forced Emulation Prefix in HVM guests */
>> > -bool_t opt_hvm_fep;
>> > +bool_t __read_mostly opt_hvm_fep;
>> > boolean_param("hvm_fep", opt_hvm_fep);
>> > #endif
>> > +static const char __initconst *warning_hvm_fep =
>> > +"**\n"
>> > +"*** WARNING: HVM FORCED EMULATION PREFIX IS AVAILABLE\n"
>> > +"*** This option is *ONLY* intended to aid testing of Xen.\n"
>> > +"*** It has implications on the security of the system.\n"
>> > +"*** Please *DO NOT* use this in production.\n"
>> > +"**\n";
>> > +
>> >
>>
>> Along with the same comment as on patch 2, here even more than
>> there I wonder whether this string wouldn't better be a static local
>> in hvm_enable() (or even the scope therein where warning_add()
>> gets invoked).
>
> I would rather the text stays next to where the option is defined so
> it is obvious to anyone who touches this area of code.
Makes sense. But then - shouldn't it move inside the #ifndef?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/4] x86emul: use (locally) consistent exit mechanisms
>>> On 23.06.16 at 12:36, wrote: > On 20/06/16 12:58, Jan Beulich wrote: >> At least similar code should use similar exit mechanisms (return vs >> goto). >> >> Signed-off-by: Jan Beulich >> --- >> RFC reason: There are many more paths where we could return directly, >> avoiding the _put_fpu() and put_stub(). Otoh arguably the >> two existing return-s around the changes below could also >> be changed to "goto done" to restore consistency. >> >> Subsequently we may then want to consider to reduce the number of >> "goto done" by checking rc right after at least the main switch() >> statements. > > I think this patch goes in the wrong direction. Mixing exit mechanisms > makes code harder to interpret, and x86_emulate() isn't the easiest > function to edit. Well, that's what I had put up in the RFC remark. I'm all for consistency, what I'm not sure is whether this ... > Using "goto done;" consistently would be a better option. is better than (always) using plain return where possible. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] x86emul: drop pointless and add useful default cases
>>> On 23.06.16 at 12:44, wrote: > On 20/06/16 12:58, Jan Beulich wrote: >> @@ -3845,10 +3834,11 @@ x86_emulate( >> goto push; >> case 7: >> generate_exception_if(1, EXC_UD, -1); >> -default: >> -goto cannot_emulate; >> } >> break; >> + >> +default: >> +BUG(); > > These introduce DoS vulnerabilities if there is indeed a path to default. > > Could I recommend instead a one-time printk() dumping the instruction > stream which lead to here, an ASSERT_UNREACHABLE(), and a goto > cannot_emulate? > > That way, a production build won't crash. Good point, will do. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu blocking list
> -Original Message- > From: Dario Faggioli [mailto:dario.faggi...@citrix.com] > Sent: Tuesday, May 24, 2016 10:02 PM > To: Wu, Feng ; Jan Beulich > Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com; Tian, Kevin > ; xen-devel@lists.xen.org; konrad.w...@oracle.com; > k...@xen.org > Subject: Re: [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu > blocking list > > On Tue, 2016-05-24 at 10:07 +, Wu, Feng wrote: > > > See, for instance, cpu_disable_scheduler() in schedule.c. What we > > > do is > > > go over all the vcpus of all domains of either the system or the > > > cpupool, and force the ones that we found with v->processor set to > > > the > > > pCPU that is going down, to perform migration (system_state will be > > > different than SYS_STATE_suspend, and we hence take the 'else' > > > branch). > > > > > > Considering that the pCPU is no longer part of the relevant > > > bitmask-s > > > during the migration, the vCPUs will figure out that they just > > > can't > > > stay there, and move somewhere else. > > > > Thanks a lot for the elaboration, it is really helpful. > > > NP :-) > > > > Note, however, that this happens for running and runnable vCPUs. > > > > I don't quite understand this, do you mean cpu_disable_scheduler() > > only handle running and runnable vCPUs, I tried to find some hints > > from the code, but I didn't get it. Could you please give some more > > information about this? > > > It goes through all the vcpus of all domains, and does not check or > care whether they are running, runnable or blocked. > > Let's look at this in some more details. So, let's assume that > processor 5 is going away, and that you have the following vcpus > around: > > d0v0 : v->processor = 5, running on cpu 5 > d0v1 : v->processor = 4, running on cpu 4 > d1v0 : v->processor = 5, runnable but not running > d2v3 : v->processor = 5, blocked > > for d0v0, we do: > cpu_disable_scheduler(5) > set_bit(_VPF_migrating, d0v0->pause_flags); > vcpu_sleep_nosync(d0v0); > SCHED_OP(sleep, d0v0); > csched_vcpu_sleep(d0v0) > cpu_raise_softirq(5, SCHEDULE_SOFTIRQ); > vcpu_migrate(d0v0); > if ( v->is_running || ...) // assume v->is_running is true > return Hi Dario, after read this mail again, I get another question, could you please help me out? In the above code flow, we return in vcpu_migrate(d0v0) because v->is_running == 1, after vcpu_migrate() return, we check: if ( v->processor == cpu ) ret = -EAGAIN; In my understand in the above case, 'v->processor' is likely equal to 'cpu', hence return -EAGAIN. However, in __cpu_disable(), there is some check as below: if ( cpu_disable_scheduler(cpu) ) BUG(); Might we hit the BUG() in the above case? Or am I miss something? Thanks a lot! Thanks, Feng > ... > ... <--- scheduling occurs on processor 5 > ... > context_saved(d0v0) > vcpu_migrate(d0v0); > //is_running is 0, so _VPF_migrating gets cleared > vcpu_move_locked(d0v0, new_cpu); > vcpu_wake(d0v0); > SCHED_OP(wake, d0v0); > csched_vcpu_wake(d0v0) > __runq_insert(d0v0); > __runq_tickle(d0v0); > > for d0v1, we do: > cpu_disable_scheduler(5) > if ( d0v1->processor != 5 ) > continue > > for d1v0, we do: > cpu_disable_scheduler(5) > set_bit(_VPF_migrating, d1v0->pause_flags); > vcpu_sleep_nosync(d1v0); > SCHED_OP(sleep, d1v0); > csched_vcpu_sleep(d1v0) > __runq_remove(d1v0); > vcpu_migrate(d1v0); > if ( d1v0->is_running || > !test_and_clear_bit(_VPF_migrating, d1v0->pause_flags) > // false, but clears the _VPF_migrating flag > vcpu_move_locked(d1v0, new_cpu); > vcpu_wake(v); > SCHED_OP(wake, d1v0); > csched_vcpu_wake(d1v0) > __runq_insert(d1v0); > __runq_tickle(d1v0); > > for d2v3, we do: > cpu_disable_scheduler(5) > set_bit(_VPF_migrating, d2v3- > >pause_flags); > vcpu_sleep_nosync(d2v3); > SCHED_OP(sleep, d2v3); > > csched_vcpu_sleep(d2v3) > [1] // Nothing! > > vcpu_migrate(d2v3); > if ( d2v3->is_running || > > !test_and_clear_bit(_VPF_migrating, d2v3->pause_flags) > // > false, but clears the _VPF_migrating flag > [*] vcpu_move_locked(d2v3, > new_cpu); > vcpu_wake(d2v3); > [2] // Nothing! > > > > If a > > > vCPU is blocker, there is nothing to do, and in fact, nothing > > > happens > > > (as vcpu_sleep_nosync() and vcpu_wake() are NOP in that case). > > > > What do you mean by saying ' vcpu_sleep_nosync() and vcpu_wake() > > are NOP '? > > > See [1] and [2] above. > > > > For > > > those vCPUs, as soon as they wake up, they'll figure out that their > > > own > > > v->processor is not there any longer, and will move somewhere else. > > > > So basically, when vCPU is blocking, it has no impact to the blocking > > vcpu > >
Re: [Xen-devel] Do people want a Developer Meeting on Aug 24th (before Dev Summit)
> On 23 Jun 2016, at 12:39, George Dunlap wrote: > > On 23/06/16 12:33, Lars Kurth wrote: >> Folks, >> >> do you guys want to hold a Developer Meeting on Aug 24th (before Dev >> Summit). I do have space to do this, but last year's was very poorly >> attended. If you could get back to me with an opinion, that would help >> hugely. Alternatively it would also be possible to use the space for more >> focused meetings with fewer people. In that case, I would need a number of >> suggestions for meetings including meeting leaders. >> >> Please have a look at the schedule >> http://events.linuxfoundation.org/events/xen-project-developer-summit/program/schedule >> ... note that on the 26th, I kept the 2nd room free and was planning to use >> the Hackathon format in parallel to the talks in the main program. rather >> than having BoFs interspersed with talks. Some of the slots could be used to >> host the developer meeting, of desired. > > So to a large degree, the actual nuts-and-bolts planning which that > meeting was meant to cover happens now at the "hackathons" instead. > It's important I think, however, for the XenSummit to have a venue for > people in the industry who may not know about the Hackathons (or for > whatever reason can't come to them) to raise issues with the core > developers and have them discussed. > > If the parallel track could actually fulfill that role, then I think it > would be enough; the key would be making sure that the appropriate > attention could be attracted. That's why I asked. Maybe we can come up with a short list of topics that need to be discussed and are worthwhile for the developer meetings. The idea behind using the Hackathon scheduling methodology for the parallel track is an experiment to make assigning of topics to space mor effective than in the past. I don't have an opinion one way or another. We can have a developer meeting as well. Just shout and I will set it up. Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 3/3] xen: make available hvm_fep to non-debug build as well
On Thu, Jun 23, 2016 at 06:20:38AM -0600, Jan Beulich wrote:
> >>> On 23.06.16 at 12:50, wrote:
> > On Wed, Jun 22, 2016 at 09:42:38AM -0600, Jan Beulich wrote:
> >> >>> On 20.06.16 at 18:30, wrote:
> >> > @@ -97,9 +98,17 @@ boolean_param("hap", opt_hap_enabled);
> >> >
> >> > #ifndef opt_hvm_fep
> >> > /* Permit use of the Forced Emulation Prefix in HVM guests */
> >> > -bool_t opt_hvm_fep;
> >> > +bool_t __read_mostly opt_hvm_fep;
> >> > boolean_param("hvm_fep", opt_hvm_fep);
> >> > #endif
> >> > +static const char __initconst *warning_hvm_fep =
> >> > +"**\n"
> >> > +"*** WARNING: HVM FORCED EMULATION PREFIX IS AVAILABLE\n"
> >> > +"*** This option is *ONLY* intended to aid testing of Xen.\n"
> >> > +"*** It has implications on the security of the system.\n"
> >> > +"*** Please *DO NOT* use this in production.\n"
> >> > +"**\n";
> >> > +
> >> >
> >>
> >> Along with the same comment as on patch 2, here even more than
> >> there I wonder whether this string wouldn't better be a static local
> >> in hvm_enable() (or even the scope therein where warning_add()
> >> gets invoked).
> >
> > I would rather the text stays next to where the option is defined so
> > it is obvious to anyone who touches this area of code.
>
> Makes sense. But then - shouldn't it move inside the #ifndef?
>
That would then require the warning_add() call to be wrapped in ifdef,
too. That looks a bit cumbersome to me.
Wei.
> Jan
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 3/3] xen: make available hvm_fep to non-debug build as well
On 23/06/16 13:44, Wei Liu wrote:
> On Thu, Jun 23, 2016 at 06:20:38AM -0600, Jan Beulich wrote:
> On 23.06.16 at 12:50, wrote:
>>> On Wed, Jun 22, 2016 at 09:42:38AM -0600, Jan Beulich wrote:
>>> On 20.06.16 at 18:30, wrote:
> @@ -97,9 +98,17 @@ boolean_param("hap", opt_hap_enabled);
>
> #ifndef opt_hvm_fep
> /* Permit use of the Forced Emulation Prefix in HVM guests */
> -bool_t opt_hvm_fep;
> +bool_t __read_mostly opt_hvm_fep;
> boolean_param("hvm_fep", opt_hvm_fep);
> #endif
> +static const char __initconst *warning_hvm_fep =
> +"**\n"
> +"*** WARNING: HVM FORCED EMULATION PREFIX IS AVAILABLE\n"
> +"*** This option is *ONLY* intended to aid testing of Xen.\n"
> +"*** It has implications on the security of the system.\n"
> +"*** Please *DO NOT* use this in production.\n"
> +"**\n";
> +
>
Along with the same comment as on patch 2, here even more than
there I wonder whether this string wouldn't better be a static local
in hvm_enable() (or even the scope therein where warning_add()
gets invoked).
>>> I would rather the text stays next to where the option is defined so
>>> it is obvious to anyone who touches this area of code.
>> Makes sense. But then - shouldn't it move inside the #ifndef?
>>
> That would then require the warning_add() call to be wrapped in ifdef,
> too. That looks a bit cumbersome to me.
You can do something like:
#ifndef $FOO
#define warning_text NULL
#else
const static __initdata warning_text[] = "BAR";
#endif
This works in the same way as the current opt_hvm_fep define.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 3/3] xen: make available hvm_fep to non-debug build as well
On Thu, Jun 23, 2016 at 01:48:35PM +0100, Andrew Cooper wrote:
> On 23/06/16 13:44, Wei Liu wrote:
> > On Thu, Jun 23, 2016 at 06:20:38AM -0600, Jan Beulich wrote:
> > On 23.06.16 at 12:50, wrote:
> >>> On Wed, Jun 22, 2016 at 09:42:38AM -0600, Jan Beulich wrote:
> >>> On 20.06.16 at 18:30, wrote:
> > @@ -97,9 +98,17 @@ boolean_param("hap", opt_hap_enabled);
> >
> > #ifndef opt_hvm_fep
> > /* Permit use of the Forced Emulation Prefix in HVM guests */
> > -bool_t opt_hvm_fep;
> > +bool_t __read_mostly opt_hvm_fep;
> > boolean_param("hvm_fep", opt_hvm_fep);
> > #endif
> > +static const char __initconst *warning_hvm_fep =
> > +"**\n"
> > +"*** WARNING: HVM FORCED EMULATION PREFIX IS AVAILABLE\n"
> > +"*** This option is *ONLY* intended to aid testing of Xen.\n"
> > +"*** It has implications on the security of the system.\n"
> > +"*** Please *DO NOT* use this in production.\n"
> > +"**\n";
> > +
> >
> Along with the same comment as on patch 2, here even more than
> there I wonder whether this string wouldn't better be a static local
> in hvm_enable() (or even the scope therein where warning_add()
> gets invoked).
> >>> I would rather the text stays next to where the option is defined so
> >>> it is obvious to anyone who touches this area of code.
> >> Makes sense. But then - shouldn't it move inside the #ifndef?
> >>
> > That would then require the warning_add() call to be wrapped in ifdef,
> > too. That looks a bit cumbersome to me.
>
> You can do something like:
>
> #ifndef $FOO
> #define warning_text NULL
> #else
> const static __initdata warning_text[] = "BAR";
> #endif
>
> This works in the same way as the current opt_hvm_fep define.
>
Sure, that works for me, too.
Wei.
> ~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] Xen Project 4.7 and 4.6.3 Release
Dear Community Members, I’m pleased to announce the release of Xen Project Hypervisor 4.7 and Xen Project Hypervisor 4.6.3. Best Regards Lars, Wei, Jan = Xen Project Hypervisor 4.7 = This new release focuses on improving code quality, security hardening, security features, live migration support, usability improvements and support for new hardware features — this is also the first release of our fixed term June – December release cycle. We continue to strive to make Xen Project Hypervisor the most secure open source hypervisor to match the security challenges in cloud computing, and for embedded and IoT use-cases. We are continuing to improve upon the performance and scalability for our users, and aim to continuously bring many new features to our users in a timely manner. To make it easier to understand the major changes during this release cycle, I’ve grouped them below into several categories: * Security Features * Migration Support * Performance and Workloads * Support for new Hardware Features * Drivers and Devices (Linux, FreeBSD and other) == Security Features == Reboot-free Live Patching: Xen Project Hypervisor 4.7 comes equipped with Live Patching, a technology that enables re-boot free deployment of security patches to minimize disruption and downtime during security upgrades for system administrators and DevOps practitioners. Xen Project 4.7 implements version 1 of the Xen Project’s Live Patching specification, which is designed to encode the vast majority of security patches (approximately 90%) as Live Patching payloads. This version ships with a Live Patching enabled hypervisor and payload deployment tools and is available as a technology preview. KCONFIG support: For security, embedded automotive and IoT use cases, Xen Project introduced the ability to remove core Xen Hypervisor features at compile time via KCONFIG. This ability creates a more lightweight hypervisor and eliminates extra attack surfaces that are beneficial in security-first environments, microservice architectures and environments that have heavy compliance and certification needs, like automotive. Improvements to the Virtual Machine Introspection (VMI) subsystem: A number of performance, scalability, robustness and interface improvements have been added to theVirtual Machine Introspection subsystem, that was introduced in Xen 4.5. In addition,Bitdefender Hypervisor Introspection leveraging Xen Project Virtual Machine Introspection, has recently been released as a new enterprise security solution to discover and remedy deep threats that remain hidden via traditional endpoint security tools. Foundation work to tolerate a restartable Dom0: Several key components in a Xen Project system run in Dom0, which make Dom0 the single point of failure. Xen Project has been able to run xenstored, the daemon for managing the hypervisor’s central settings repository on a Xen Project host, in a sandboxed Virtual Machine called xenstored stub domain since Xen Project version 4.2. In Xen 4.7, we have made it easier to build xenstored stub domains and for them to tolerate a Dom0 restart. This will make Dom0 less critical to a Xen Project system and help us move towards a more robust and secure architecture in the future. More work in this area is expected in subsequent releases. == Migration Support == Improved Migration support: CPU ID Levelling enables migration of VM’s between a larger range of non-identical hosts than previously supported. Fault Tolerance / Coarse-grained Lock-stepping (COLO): Xen 4.5 laid the foundation forCOLO while improving the Xen Project’s Hypervisors Live Migration and Remus High Availability support. The COLO Manager, which introduces a relaxed approach to checkpointing that avoids unnecessary checkpoints enabling near native performance for many workloads, has been fully integrated as an experimental feature into Xen 4.7. Note that the COLO Block Replication and COLO Proxy components, both of which are QEMU components, are currently still reviewed by the QEMU community. Both components are available as out-of-tree add-ons to the Xen Project Hypervisor, until fully integrated into QEMU. == Performance and Workloads == Support for a wider range of workloads and applications: The PV guest limit restriction of 512GB has been removed to allow the creation of huge PV domains in the TB range. TB sized VMs, coupled with Xen Project’s existing support for 512 vCPUs per VM, enable execution of memory and compute intensive workloads such as big data analytics workloads and in-memory databases. Improved Credit 2 scheduler: The Credit2 scheduler is one (big) step closer to being ready for production use. It is now possible to instruct the scheduler to organize its runqueues and perform load balancing at core, socket or NUMA node granularity. More fine grained (core) configurations, deliver more aggressive load balancing, and are best suited for medium size sys
Re: [Xen-devel] [PATCH v3 3/3] xen: make available hvm_fep to non-debug build as well
>>> On 23.06.16 at 14:44, wrote:
> On Thu, Jun 23, 2016 at 06:20:38AM -0600, Jan Beulich wrote:
>> >>> On 23.06.16 at 12:50, wrote:
>> > On Wed, Jun 22, 2016 at 09:42:38AM -0600, Jan Beulich wrote:
>> >> >>> On 20.06.16 at 18:30, wrote:
>> >> > @@ -97,9 +98,17 @@ boolean_param("hap", opt_hap_enabled);
>> >> >
>> >> > #ifndef opt_hvm_fep
>> >> > /* Permit use of the Forced Emulation Prefix in HVM guests */
>> >> > -bool_t opt_hvm_fep;
>> >> > +bool_t __read_mostly opt_hvm_fep;
>> >> > boolean_param("hvm_fep", opt_hvm_fep);
>> >> > #endif
>> >> > +static const char __initconst *warning_hvm_fep =
>> >> > +"**\n"
>> >> > +"*** WARNING: HVM FORCED EMULATION PREFIX IS AVAILABLE\n"
>> >> > +"*** This option is *ONLY* intended to aid testing of Xen.\n"
>> >> > +"*** It has implications on the security of the system.\n"
>> >> > +"*** Please *DO NOT* use this in production.\n"
>> >> > +"**\n";
>> >> > +
>> >> >
>> >>
>> >> Along with the same comment as on patch 2, here even more than
>> >> there I wonder whether this string wouldn't better be a static local
>> >> in hvm_enable() (or even the scope therein where warning_add()
>> >> gets invoked).
>> >
>> > I would rather the text stays next to where the option is defined so
>> > it is obvious to anyone who touches this area of code.
>>
>> Makes sense. But then - shouldn't it move inside the #ifndef?
>>
>
> That would then require the warning_add() call to be wrapped in ifdef,
> too. That looks a bit cumbersome to me.
Ah, right. Well, never mind then - the compiler will (hopefully) take
care of eliminating the unused string then.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv3] x86/xen: avoid m2p lookup when setting early page table entries
On 23/06/16 13:13, Juergen Gross wrote:
> On 23/06/16 11:51, David Vrabel wrote:
>> When page tables entries are set using xen_set_pte_init() during early
>> boot there is no page fault handler that could handle a fault when
>> performing an M2P lookup.
>>
>> In 64 bit guests (usually dom0) early_ioremap() would fault in
>> xen_set_pte_init() because an M2P lookup faults because the MFN is in
>> MMIO space and not mapped in the M2P. This lookup is done to see if
>> the PFN in in the range used for the initial page table pages, so that
>> the PTE may be set as read-only.
>>
>> The M2P lookup can be avoided by moving the check (and clear of RW)
>> earlier when the PFN is still available.
>>
>> Signed-off-by: David Vrabel
>> ---
>> Cc: Kevin Moraga
>>
>> v3:
>> - fold mask_rw_pte()/mask_rw_pteval() into their callers.
>>
>> v2:
>> - Remove __init annotation from xen_make_pte_init() since
>> PV_CALLEE_SAVE_REGS_THUNK always puts the thunk in .text.
>>
>> - mask_rw_pte() -> mask_rw_pteval() for x86-64.
>> ---
>> arch/x86/xen/mmu.c | 76
>> +-
>> 1 file changed, 35 insertions(+), 41 deletions(-)
>>
>> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
>> index 478a2de..64d8f0b 100644
>> --- a/arch/x86/xen/mmu.c
>> +++ b/arch/x86/xen/mmu.c
>> @@ -1551,41 +1551,6 @@ static void xen_pgd_free(struct mm_struct *mm, pgd_t
>> *pgd)
>> #endif
>> }
>>
>> -#ifdef CONFIG_X86_32
>> -static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
>> -{
>> -/* If there's an existing pte, then don't allow _PAGE_RW to be set */
>> -if (pte_val_ma(*ptep) & _PAGE_PRESENT)
>> -pte = __pte_ma(((pte_val_ma(*ptep) & _PAGE_RW) | ~_PAGE_RW) &
>> - pte_val_ma(pte));
>> -
>> -return pte;
>> -}
>> -#else /* CONFIG_X86_64 */
>> -static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
>> -{
>> -unsigned long pfn;
>> -
>> -if (xen_feature(XENFEAT_writable_page_tables) ||
>> -xen_feature(XENFEAT_auto_translated_physmap) ||
>> -xen_start_info->mfn_list >= __START_KERNEL_map)
>> -return pte;
>> -
>> -/*
>> - * Pages belonging to the initial p2m list mapped outside the default
>> - * address range must be mapped read-only. This region contains the
>> - * page tables for mapping the p2m list, too, and page tables MUST be
>> - * mapped read-only.
>> - */
>> -pfn = pte_pfn(pte);
>> -if (pfn >= xen_start_info->first_p2m_pfn &&
>> -pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_frames)
>> -pte = __pte_ma(pte_val_ma(pte) & ~_PAGE_RW);
>> -
>> -return pte;
>> -}
>> -#endif /* CONFIG_X86_64 */
>> -
>> /*
>> * Init-time set_pte while constructing initial pagetables, which
>> * doesn't allow RO page table pages to be remapped RW.
>> @@ -1600,13 +1565,41 @@ static pte_t __init mask_rw_pte(pte_t *ptep, pte_t
>> pte)
>> * so always write the PTE directly and rely on Xen trapping and
>> * emulating any updates as necessary.
>> */
>> -static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
>> +__visible pte_t xen_make_pte_init(pteval_t pte)
>> {
>> -if (pte_mfn(pte) != INVALID_P2M_ENTRY)
>> -pte = mask_rw_pte(ptep, pte);
>> -else
>> -pte = __pte_ma(0);
>> +#ifdef CONFIG_X86_64
>> +unsigned long pfn;
>> +
>> +/*
>> + * Pages belonging to the initial p2m list mapped outside the default
>> + * address range must be mapped read-only. This region contains the
>> + * page tables for mapping the p2m list, too, and page tables MUST be
>> + * mapped read-only.
>> + */
>> +pfn = (pte & PTE_PFN_MASK) >> PAGE_SHIFT;
>> +if (xen_start_info->mfn_list < __START_KERNEL_map &&
>> +pfn >= xen_start_info->first_p2m_pfn &&
>> +pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_frames)
>> +pte &= ~_PAGE_RW;
>> +#endif
>> +pte = pte_pfn_to_mfn(pte);
>>
>> +if ((pte & PTE_PFN_MASK) >> PAGE_SHIFT == INVALID_P2M_ENTRY)
>
> How can this ever be true? I know this is just the open coded
> variant form the original xen_set_pte_init(). Either the if isn't
> needed at all or it should be corrected.
The frame might be ballooned out.
>> +pte = 0;
>> +
>> +return native_make_pte(pte);
>> +}
>> +PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte_init);
>> +
>> +static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
>> +{
>> +#ifdef CONFIG_X86_32
>> +/* If there's an existing pte, then don't allow _PAGE_RW to be set */
>> +if (pte_mfn(pte) != INVALID_P2M_ENTRY
>> +&& pte_val_ma(*ptep) & _PAGE_PRESENT)
>
> Even more obvious: do we really create ptes with INVALID_P2M_ENTRY and
> _PAGE_PRESENT? I think the first part of the if can be dropped again.
Again, the frame might be ballooned out.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 4/8] xen: Use typesafe gfn in xenmem_add_to_physmap_one
On Thu, 23 Jun 2016, Julien Grall wrote: > Hi Stefano, > > On 23/06/16 11:20, Stefano Stabellini wrote: > > On Tue, 21 Jun 2016, Julien Grall wrote: > > > The x86 version of the function xenmem_add_to_physmap_one contains > > > variable name gpfn and gfn which make the code very confusing. > > > I have left unchanged for now. > > > > > > Also, rename gpfn to gfn in the ARM version as the latter is the correct > > > acronym for a guest physical frame. > > > > > > Finally, remove the trailing whitespace around the changes. > > > > > > Signed-off-by: Julien Grall > > > Acked-by: Jan Beulich > > > > > > --- > > > Cc: Stefano Stabellini > > > Cc: Jan Beulich > > > Cc: Andrew Cooper > > > Cc: George Dunlap > > > Cc: Ian Jackson > > > Cc: Konrad Rzeszutek Wilk > > > Cc: Tim Deegan > > > Cc: Wei Liu > > > > > > Changes in v3: > > > - Add Jan's acked-by for non-ARM bits > > > --- > > > xen/arch/arm/mm.c| 10 +- > > > xen/arch/x86/mm.c| 15 +++ > > > xen/common/memory.c | 6 +++--- > > > xen/include/xen/mm.h | 2 +- > > > 4 files changed, 16 insertions(+), 17 deletions(-) > > > > > > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c > > > index 5ab9b75..6882d54 100644 > > > --- a/xen/arch/arm/mm.c > > > +++ b/xen/arch/arm/mm.c > > > @@ -1046,7 +1046,7 @@ int xenmem_add_to_physmap_one( > > > unsigned int space, > > > union xen_add_to_physmap_batch_extra extra, > > > unsigned long idx, > > > -xen_pfn_t gpfn) > > > +gfn_t gfn) > > > > I think there is a possible loss of information here: xen_pfn_t is > > always uint64_t on both ARM and ARM64, while gfn_t is unsigned long with > > its current definition. Or am I missing something? > > > > In fact, given that ARM supports LPAE, shouldn't gfn by defined as > > xen_pfn_t in terms of storage size (TYPE_SAFE(xen_pfn_t, gfn)) ? > > With LPAE, ARM32 supports up to 40-bit PA so the frame will be encoded on > 28-bit. So unsigned long is perfectly fine here. Somehow I have always assumed that the 40-bit limitation was just temporary. That ARM in the future will just increase that number up to 64-bit eventually. If you don't think there is any risk of that happening, then I am fine with this. We just have to keep in mind that many of the guest interfaces use xen_pfn_t, which has a different size on ARM. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 96151: regressions - trouble: blocked/broken/fail/pass
flight 96151 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/96151/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 3 host-install(3) broken REGR. vs. 96125 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken REGR. vs. 96125 test-armhf-armhf-xl 18 leak-check/check fail REGR. vs. 96125 Regressions which are regarded as allowable (not blocking): build-amd64-rumpuserxen 6 xen-buildfail like 96125 build-i386-rumpuserxen6 xen-buildfail like 96125 test-amd64-amd64-xl-rtds 9 debian-install fail like 96125 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail like 96125 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 96125 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 96125 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 96125 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 96125 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass version targeted for testing: xen 91b26a35914176db4d19dc145bc6e2db62ee7a2c baseline version: xen c6f7d21747805b50123fc1b8d73518fea2aa9096 Last test of basis96125 2016-06-22 12:58:07 Z1 days Testing same since96151 2016-06-23 00:44:34 Z0 days1 attempts People who touched revisions under test: Jan Beulich Julien Grall Kevin Tian Quan Xu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass
Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"
On Thu, Jun 23, 2016 at 03:46:46AM -0600, Jan Beulich wrote:
> >>> On 23.06.16 at 11:23, wrote:
> > On Thu, Jun 23, 2016 at 11:18:24AM +0200, Marek Marczykowski-Górecki wrote:
> >> On Thu, Jun 23, 2016 at 03:12:47AM -0600, Jan Beulich wrote:
> >> > >>> On 23.06.16 at 10:57, wrote:
> >> > > On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote:
> >> > >> I wonder what good the duplication of the returned domain ID does: I'm
> >> > >> tempted to remove the one in the command-specific structure. Does
> >> > >> anyone have insight into why it was done that way?
> >> > >
> >> > > Isn't XEN_DOMCTL_getdomaininfo supposed to return info about first
> >> > > existing domain with ID >= passed one? Reading various comments in code
> >> > > it looks to be used to domain enumeration. This patch changes this
> >> > > behaviour.
> >> >
> >> > No, it doesn't. It adjusts the behavior only for the DM case (which
> >> > isn't supposed to get information on other than the target domain,
> >> > i.e. in this one specific case the very domain ID needs to be passed
> >> > in).
> >>
> >> int xc_domain_getinfo(xc_interface *xch,
> >> uint32_t first_domid,
> >> unsigned int max_doms,
> >> xc_dominfo_t *info)
> >> {
> >> unsigned int nr_doms;
> >> uint32_t next_domid = first_domid;
> >> DECLARE_DOMCTL;
> >> int rc = 0;
> >>
> >> memset(info, 0, max_doms*sizeof(xc_dominfo_t));
> >>
> >> for ( nr_doms = 0; nr_doms < max_doms; nr_doms++ )
> >> {
> >> domctl.cmd = XEN_DOMCTL_getdomaininfo;
> >> domctl.domain = (domid_t)next_domid;
> >> if ( (rc = do_domctl(xch, &domctl)) < 0 )
> >> break;
> >> info->domid = (uint16_t)domctl.domain;
> >> (...)
> >> next_domid = (uint16_t)domctl.domain + 1;
> >>
> >>
> >> Looks like heavily dependent on XEN_DOMCTL_getdomaininfo returning next
> > valid
> >> domain.
> >
> > Hmm, looks like I've misread you patch. Reading again...
> >
> > But now I see rcu_read_lock(&domlist_read_lock) is gets called only when
> > looping over domains, but rcu_read_unlock is called in any case. Is it
> > correct?
>
> How that? There is this third hunk:
Ok, after drawing a flowchart of the control in this function after your
change, on a piece of paper, this case looks fine. But depending on how
the domain was found (explicit loop or rcu_lock_domain_by_id), different
locks are held, which makes it harder to follow what is going on.
Crazy idea: how about making the code easy/easier to read instead of
obfuscating it even more? XEN_DOMCTL_getdomaininfo semantic is
convolved enough. How about this version (2 patches):
xen: move domain lookup for getdomaininfo to the same
XEN_DOMCTL_getdomaininfo have different semantics than most of others
domctls - it returns information about first valid domain with ID >=
argument. But that's no excuse for having the lookup done in a different
place, which made handling different corner cases unnecessary complex.
Move the lookup to the first switch clause. And adjust locking to be the
same as for other cases.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/common/domctl.c | 41 -
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index e43904e..6ae1fe0 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -442,11 +442,29 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
u_domctl)
switch ( op->cmd )
{
case XEN_DOMCTL_createdomain:
-case XEN_DOMCTL_getdomaininfo:
case XEN_DOMCTL_test_assign_device:
case XEN_DOMCTL_gdbsx_guestmemio:
d = NULL;
break;
+case XEN_DOMCTL_getdomaininfo:
+d = rcu_lock_domain_by_id(op->domain);
+if ( d == NULL )
+{
+/* search for the next valid domain */
+rcu_read_lock(&domlist_read_lock);
+
+for_each_domain ( d )
+if ( d->domain_id >= op->domain )
+{
+rcu_lock_domain(d);
+break;
+}
+
+rcu_read_unlock(&domlist_read_lock);
+if ( d == NULL )
+return -ESRCH;
+}
+break;
default:
d = rcu_lock_domain_by_id(op->domain);
if ( d == NULL )
@@ -862,33 +880,14 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
u_domctl)
break;
case XEN_DOMCTL_getdomaininfo:
-{
-domid_t dom = op->domain;
-
-rcu_read_lock(&domlist_read_lock);
-
-for_each_domain ( d )
-if ( d->domain_id >= dom )
-break;
-
-ret = -ESRCH;
-if ( d == NULL )
-goto getdomaininfo_out;
-
ret = xsm_getdomaininfo(XSM_HOOK, d);
if ( ret )
-goto getdomaininfo_out;
+break;
getdomaininfo(d, &op->u.getdomaininfo);
-
Re: [Xen-devel] [PATCHv3] x86/xen: avoid m2p lookup when setting early page table entries
On 23/06/16 15:06, David Vrabel wrote:
> On 23/06/16 13:13, Juergen Gross wrote:
>> On 23/06/16 11:51, David Vrabel wrote:
>>> When page tables entries are set using xen_set_pte_init() during early
>>> boot there is no page fault handler that could handle a fault when
>>> performing an M2P lookup.
>>>
>>> In 64 bit guests (usually dom0) early_ioremap() would fault in
>>> xen_set_pte_init() because an M2P lookup faults because the MFN is in
>>> MMIO space and not mapped in the M2P. This lookup is done to see if
>>> the PFN in in the range used for the initial page table pages, so that
>>> the PTE may be set as read-only.
>>>
>>> The M2P lookup can be avoided by moving the check (and clear of RW)
>>> earlier when the PFN is still available.
>>>
>>> Signed-off-by: David Vrabel
>>> ---
>>> Cc: Kevin Moraga
>>>
>>> v3:
>>> - fold mask_rw_pte()/mask_rw_pteval() into their callers.
>>>
>>> v2:
>>> - Remove __init annotation from xen_make_pte_init() since
>>> PV_CALLEE_SAVE_REGS_THUNK always puts the thunk in .text.
>>>
>>> - mask_rw_pte() -> mask_rw_pteval() for x86-64.
>>> ---
>>> arch/x86/xen/mmu.c | 76
>>> +-
>>> 1 file changed, 35 insertions(+), 41 deletions(-)
>>>
>>> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
>>> index 478a2de..64d8f0b 100644
>>> --- a/arch/x86/xen/mmu.c
>>> +++ b/arch/x86/xen/mmu.c
>>> @@ -1551,41 +1551,6 @@ static void xen_pgd_free(struct mm_struct *mm, pgd_t
>>> *pgd)
>>> #endif
>>> }
>>>
>>> -#ifdef CONFIG_X86_32
>>> -static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
>>> -{
>>> - /* If there's an existing pte, then don't allow _PAGE_RW to be set */
>>> - if (pte_val_ma(*ptep) & _PAGE_PRESENT)
>>> - pte = __pte_ma(((pte_val_ma(*ptep) & _PAGE_RW) | ~_PAGE_RW) &
>>> - pte_val_ma(pte));
>>> -
>>> - return pte;
>>> -}
>>> -#else /* CONFIG_X86_64 */
>>> -static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
>>> -{
>>> - unsigned long pfn;
>>> -
>>> - if (xen_feature(XENFEAT_writable_page_tables) ||
>>> - xen_feature(XENFEAT_auto_translated_physmap) ||
>>> - xen_start_info->mfn_list >= __START_KERNEL_map)
>>> - return pte;
>>> -
>>> - /*
>>> -* Pages belonging to the initial p2m list mapped outside the default
>>> -* address range must be mapped read-only. This region contains the
>>> -* page tables for mapping the p2m list, too, and page tables MUST be
>>> -* mapped read-only.
>>> -*/
>>> - pfn = pte_pfn(pte);
>>> - if (pfn >= xen_start_info->first_p2m_pfn &&
>>> - pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_frames)
>>> - pte = __pte_ma(pte_val_ma(pte) & ~_PAGE_RW);
>>> -
>>> - return pte;
>>> -}
>>> -#endif /* CONFIG_X86_64 */
>>> -
>>> /*
>>> * Init-time set_pte while constructing initial pagetables, which
>>> * doesn't allow RO page table pages to be remapped RW.
>>> @@ -1600,13 +1565,41 @@ static pte_t __init mask_rw_pte(pte_t *ptep, pte_t
>>> pte)
>>> * so always write the PTE directly and rely on Xen trapping and
>>> * emulating any updates as necessary.
>>> */
>>> -static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
>>> +__visible pte_t xen_make_pte_init(pteval_t pte)
>>> {
>>> - if (pte_mfn(pte) != INVALID_P2M_ENTRY)
>>> - pte = mask_rw_pte(ptep, pte);
>>> - else
>>> - pte = __pte_ma(0);
>>> +#ifdef CONFIG_X86_64
>>> + unsigned long pfn;
>>> +
>>> + /*
>>> +* Pages belonging to the initial p2m list mapped outside the default
>>> +* address range must be mapped read-only. This region contains the
>>> +* page tables for mapping the p2m list, too, and page tables MUST be
>>> +* mapped read-only.
>>> +*/
>>> + pfn = (pte & PTE_PFN_MASK) >> PAGE_SHIFT;
>>> + if (xen_start_info->mfn_list < __START_KERNEL_map &&
>>> + pfn >= xen_start_info->first_p2m_pfn &&
>>> + pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_frames)
>>> + pte &= ~_PAGE_RW;
>>> +#endif
>>> + pte = pte_pfn_to_mfn(pte);
>>>
>>> + if ((pte & PTE_PFN_MASK) >> PAGE_SHIFT == INVALID_P2M_ENTRY)
>>
>> How can this ever be true? I know this is just the open coded
>> variant form the original xen_set_pte_init(). Either the if isn't
>> needed at all or it should be corrected.
>
> The frame might be ballooned out.
Okay. But how do you get the 64 bit value with all bits set by shifting
an unsigned value to the right (I admit that this is possible on a 32
bit dom0, but I doubt that was the intention of the test)?
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 4/8] xen: Use typesafe gfn in xenmem_add_to_physmap_one
On 23/06/16 14:06, Stefano Stabellini wrote: On Thu, 23 Jun 2016, Julien Grall wrote: On 23/06/16 11:20, Stefano Stabellini wrote: On Tue, 21 Jun 2016, Julien Grall wrote: I think there is a possible loss of information here: xen_pfn_t is always uint64_t on both ARM and ARM64, while gfn_t is unsigned long with its current definition. Or am I missing something? In fact, given that ARM supports LPAE, shouldn't gfn by defined as xen_pfn_t in terms of storage size (TYPE_SAFE(xen_pfn_t, gfn)) ? With LPAE, ARM32 supports up to 40-bit PA so the frame will be encoded on 28-bit. So unsigned long is perfectly fine here. Somehow I have always assumed that the 40-bit limitation was just temporary. That ARM in the future will just increase that number up to 64-bit eventually. If you don't think there is any risk of that happening, then I am fine with this. We just have to keep in mind that many of the guest interfaces use xen_pfn_t, which has a different size on ARM. Currently, Aarch32 supports up to 40-bit whilst Aarch64 supports up to 48-bit (even 52-bit with ARMv8.2). So this should be ok for now. However, pretty much everywhere in Xen we assume that the frame number is unsigned long (see mm.c, p2m.c,...). We would have much more work to do than this small patch. I would rather start to switch to gfn/mfn internally and keep the underlying type as "unsigned long" until we effectively need 64-bit frame. The main reason is 64-bit frame will result into a bigger binary for ARM32 with no apparent reason (40-bit is hardcoded in setup_virt_paging). Switching to gfn/mfn will allow us to uint64_t where it will be required. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv3] x86/xen: avoid m2p lookup when setting early page table entries
On 23/06/16 14:27, Juergen Gross wrote:
> On 23/06/16 15:06, David Vrabel wrote:
>> On 23/06/16 13:13, Juergen Gross wrote:
>>> On 23/06/16 11:51, David Vrabel wrote:
When page tables entries are set using xen_set_pte_init() during early
boot there is no page fault handler that could handle a fault when
performing an M2P lookup.
In 64 bit guests (usually dom0) early_ioremap() would fault in
xen_set_pte_init() because an M2P lookup faults because the MFN is in
MMIO space and not mapped in the M2P. This lookup is done to see if
the PFN in in the range used for the initial page table pages, so that
the PTE may be set as read-only.
The M2P lookup can be avoided by moving the check (and clear of RW)
earlier when the PFN is still available.
Signed-off-by: David Vrabel
---
Cc: Kevin Moraga
v3:
- fold mask_rw_pte()/mask_rw_pteval() into their callers.
v2:
- Remove __init annotation from xen_make_pte_init() since
PV_CALLEE_SAVE_REGS_THUNK always puts the thunk in .text.
- mask_rw_pte() -> mask_rw_pteval() for x86-64.
---
arch/x86/xen/mmu.c | 76
+-
1 file changed, 35 insertions(+), 41 deletions(-)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 478a2de..64d8f0b 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1551,41 +1551,6 @@ static void xen_pgd_free(struct mm_struct *mm,
pgd_t *pgd)
#endif
}
-#ifdef CONFIG_X86_32
-static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
-{
- /* If there's an existing pte, then don't allow _PAGE_RW to be set */
- if (pte_val_ma(*ptep) & _PAGE_PRESENT)
- pte = __pte_ma(((pte_val_ma(*ptep) & _PAGE_RW) | ~_PAGE_RW) &
- pte_val_ma(pte));
-
- return pte;
-}
-#else /* CONFIG_X86_64 */
-static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
-{
- unsigned long pfn;
-
- if (xen_feature(XENFEAT_writable_page_tables) ||
- xen_feature(XENFEAT_auto_translated_physmap) ||
- xen_start_info->mfn_list >= __START_KERNEL_map)
- return pte;
-
- /*
- * Pages belonging to the initial p2m list mapped outside the default
- * address range must be mapped read-only. This region contains the
- * page tables for mapping the p2m list, too, and page tables MUST be
- * mapped read-only.
- */
- pfn = pte_pfn(pte);
- if (pfn >= xen_start_info->first_p2m_pfn &&
- pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_frames)
- pte = __pte_ma(pte_val_ma(pte) & ~_PAGE_RW);
-
- return pte;
-}
-#endif /* CONFIG_X86_64 */
-
/*
* Init-time set_pte while constructing initial pagetables, which
* doesn't allow RO page table pages to be remapped RW.
@@ -1600,13 +1565,41 @@ static pte_t __init mask_rw_pte(pte_t *ptep, pte_t
pte)
* so always write the PTE directly and rely on Xen trapping and
* emulating any updates as necessary.
*/
-static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
+__visible pte_t xen_make_pte_init(pteval_t pte)
{
- if (pte_mfn(pte) != INVALID_P2M_ENTRY)
- pte = mask_rw_pte(ptep, pte);
- else
- pte = __pte_ma(0);
+#ifdef CONFIG_X86_64
+ unsigned long pfn;
+
+ /*
+ * Pages belonging to the initial p2m list mapped outside the default
+ * address range must be mapped read-only. This region contains the
+ * page tables for mapping the p2m list, too, and page tables MUST be
+ * mapped read-only.
+ */
+ pfn = (pte & PTE_PFN_MASK) >> PAGE_SHIFT;
+ if (xen_start_info->mfn_list < __START_KERNEL_map &&
+ pfn >= xen_start_info->first_p2m_pfn &&
+ pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_frames)
+ pte &= ~_PAGE_RW;
+#endif
+ pte = pte_pfn_to_mfn(pte);
+ if ((pte & PTE_PFN_MASK) >> PAGE_SHIFT == INVALID_P2M_ENTRY)
>>>
>>> How can this ever be true? I know this is just the open coded
>>> variant form the original xen_set_pte_init(). Either the if isn't
>>> needed at all or it should be corrected.
>>
>> The frame might be ballooned out.
>
> Okay. But how do you get the 64 bit value with all bits set by shifting
> an unsigned value to the right (I admit that this is possible on a 32
> bit dom0, but I doubt that was the intention of the test)?
pte_pfn_to_mfn() already does the right thing so this test is bogus.
I've removed it.
Can I add your acked-by or reviewed-by with this change?
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 04/17] libxl/arm: prepare for constructing ACPI tables
On Thu, 23 Jun 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> It only constructs the ACPI tables for 64-bit ARM DomU when user enables
> acpi because 32-bit DomU doesn't support ACPI.
>
> Signed-off-by: Shannon Zhao
> ---
> tools/libxl/Makefile | 4 +++
> tools/libxl/libxl_arm.c | 19 +-
> tools/libxl/libxl_arm_acpi.c | 85
>
> tools/libxl/libxl_arm_acpi.h | 32 +
> 4 files changed, 139 insertions(+), 1 deletion(-)
> create mode 100644 tools/libxl/libxl_arm_acpi.c
> create mode 100644 tools/libxl/libxl_arm_acpi.h
>
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 9fee752..264b6ef 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -77,6 +77,10 @@ endif
>
> LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
> LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
> +LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o
> +
> +libxl_arm_acpi.o: libxl_arm_acpi.c
> + $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
>
> ifeq ($(CONFIG_NetBSD),y)
> LIBXL_OBJS-y += libxl_netbsd.o
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index cc5a717..f5db74b 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -1,6 +1,7 @@
> #include "libxl_internal.h"
> #include "libxl_arch.h"
> #include "libxl_libfdt_compat.h"
> +#include "libxl_arm_acpi.h"
>
> #include
> #include
> @@ -888,8 +889,24 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
> libxl__domain_build_state *state,
> struct xc_dom_image *dom)
> {
> +int rc;
> +
> assert(info->type == LIBXL_DOMAIN_TYPE_PV);
> -return libxl__prepare_dtb(gc, info, state, dom);
> +rc = libxl__prepare_dtb(gc, info, state, dom);
> +if (rc)
> +return rc;
> +
> +if (!state->config.acpi) {
> +LOG(DEBUG, "Generating ACPI tables is disabled by user.");
> +return 0;
> +}
> +
> +if (strcmp(dom->guest_type, "xen-3.0-aarch64")) {
> +LOG(DEBUG, "Do not generate ACPI tables for %s", dom->guest_type);
> +state->config.acpi = false;
Shouldn't we return here?
> +}
> +
> +return libxl__prepare_acpi(gc, info, state, dom);
> }
>
> static void finalise_one_memory_node(libxl__gc *gc, void *fdt,
> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> new file mode 100644
> index 000..60c31f9
> --- /dev/null
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -0,0 +1,85 @@
> +/*
> + * ARM DmoU ACPI generation
> + *
> + * Copyright (C) 2008-2010 Kevin O'Connor
> + * Copyright (C) 2006 Fabrice Bellard
> + * Copyright (C) 2013 Red Hat Inc
> + *
> + * Author: Michael S. Tsirkin
> + *
> + * Copyright (c) 2015 HUAWEI TECHNOLOGIES CO.,LTD.
> + *
> + * Author: Shannon Zhao
> + *
> + * Copyright (C) 2016 Linaro Ltd.
> + *
> + * Author: Shannon Zhao
Uhm... If in doubt just remove all the Author lines: git log provides
more than enough information about who wrote this code.
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU Lesser General Public License for more details.
> + */
> +
> +#include "libxl_arm_acpi.h"
> +
> +#include
> +typedef uint8_t u8;
> +typedef uint16_t u16;
> +typedef uint32_t u32;
> +typedef uint64_t u64;
> +#include
> +#include
> +
> +enum {
> +RSDP,
> +XSDT,
> +GTDT,
> +MADT,
> +FADT,
> +DSDT,
> +NUMS,
> +};
> +
> +struct acpitable {
> +void *table;
> +size_t size;
> +};
> +
> +static struct acpitable acpitables[NUMS];
> +
> +int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
> +libxl__domain_build_state *state,
> +struct xc_dom_image *dom)
> +{
> +const libxl_version_info *vers;
> +int rc;
> +
> +/* convenience aliases */
> +xc_domain_configuration_t *xc_config = &state->config;
> +
> +vers = libxl_get_version_info(CTX);
> +if (vers == NULL)
> +return ERROR_FAIL;
> +
> +LOG(DEBUG, "constructing ACPI tables for Xen version %d.%d guest",
> +vers->xen_version_major, vers->xen_version_minor);
> +
> +dom->acpitable_blob = NULL;
> +dom->acpitable_size = 0;
> +
> +return 0;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-basic-offset: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxl/libxl_arm_acpi.h b/tools/libxl/libxl_
Re: [Xen-devel] [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI
On Thu, 23 Jun 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Add a configuration option for ARM DomU so that user can deicde to use
> ACPI or not. This option is defaultly false.
>
> Signed-off-by: Shannon Zhao
> ---
> tools/libxl/libxl_arm.c | 3 +++
> tools/libxl/libxl_types.idl | 1 +
> tools/libxl/xl_cmdimpl.c | 4
> xen/include/public/arch-arm.h | 1 +
> 4 files changed, 9 insertions(+)
>
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index 8f15d9b..cc5a717 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -77,6 +77,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
> return ERROR_FAIL;
> }
>
> +xc_config->acpi = libxl_defbool_val(d_config->b_info.arch_arm.acpi)
> + ? true : false;
> +
> return 0;
> }
>
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index ef614be..426b868 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -560,6 +560,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>
>
> ("arch_arm", Struct(None, [("gic_version", libxl_gic_version),
> + ("acpi", libxl_defbool),
>])),
>
> ], dir=DIR_IN
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 6459eec..0634ffa 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -2506,6 +2506,10 @@ skip_usbdev:
> }
> }
>
> +if (xlu_cfg_get_defbool(config, "acpi", &b_info->arch_arm.acpi, 0)) {
> +libxl_defbool_set(&b_info->arch_arm.acpi, 0);
> +}
We cannot share the existing code to parse the acpi paramter because
that is saved in b_info->u.hvm.acpi, right? It's a pity. I wonder if we
could refactor the existing code so that we can actually share the acpi
parameter between x86 and arm.
> xlu_cfg_destroy(config);
> }
>
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 870bc3b..05e4a58 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -306,6 +306,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
> struct xen_arch_domainconfig {
> /* IN/OUT */
> uint8_t gic_version;
> +uint8_t acpi;
> /* IN */
> uint32_t nr_spis;
> /*
> --
> 2.0.4
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 4/8] xen: Use typesafe gfn in xenmem_add_to_physmap_one
On Thu, 23 Jun 2016, Julien Grall wrote: > On 23/06/16 14:06, Stefano Stabellini wrote: > > On Thu, 23 Jun 2016, Julien Grall wrote: > > > On 23/06/16 11:20, Stefano Stabellini wrote: > > > > On Tue, 21 Jun 2016, Julien Grall wrote: > > > > I think there is a possible loss of information here: xen_pfn_t is > > > > always uint64_t on both ARM and ARM64, while gfn_t is unsigned long with > > > > its current definition. Or am I missing something? > > > > > > > > In fact, given that ARM supports LPAE, shouldn't gfn by defined as > > > > xen_pfn_t in terms of storage size (TYPE_SAFE(xen_pfn_t, gfn)) ? > > > > > > With LPAE, ARM32 supports up to 40-bit PA so the frame will be encoded on > > > 28-bit. So unsigned long is perfectly fine here. > > > > Somehow I have always assumed that the 40-bit limitation was just > > temporary. That ARM in the future will just increase that number up to > > 64-bit eventually. > > > > If you don't think there is any risk of that happening, then I am fine > > with this. We just have to keep in mind that many of the guest > > interfaces use xen_pfn_t, which has a different size on ARM. > > Currently, Aarch32 supports up to 40-bit whilst Aarch64 supports up to 48-bit > (even 52-bit with ARMv8.2). So this should be ok for now. > > However, pretty much everywhere in Xen we assume that the frame number is > unsigned long (see mm.c, p2m.c,...). We would have much more work to do than > this small patch. > > I would rather start to switch to gfn/mfn internally and keep the underlying > type as "unsigned long" until we effectively need 64-bit frame. > > The main reason is 64-bit frame will result into a bigger binary for ARM32 > with no apparent reason (40-bit is hardcoded in setup_virt_paging). Switching > to gfn/mfn will allow us to uint64_t where it will be required. OK. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv3] x86/xen: avoid m2p lookup when setting early page table entries
On 23/06/16 15:37, David Vrabel wrote:
> On 23/06/16 14:27, Juergen Gross wrote:
>> On 23/06/16 15:06, David Vrabel wrote:
>>> On 23/06/16 13:13, Juergen Gross wrote:
On 23/06/16 11:51, David Vrabel wrote:
> When page tables entries are set using xen_set_pte_init() during early
> boot there is no page fault handler that could handle a fault when
> performing an M2P lookup.
>
> In 64 bit guests (usually dom0) early_ioremap() would fault in
> xen_set_pte_init() because an M2P lookup faults because the MFN is in
> MMIO space and not mapped in the M2P. This lookup is done to see if
> the PFN in in the range used for the initial page table pages, so that
> the PTE may be set as read-only.
>
> The M2P lookup can be avoided by moving the check (and clear of RW)
> earlier when the PFN is still available.
>
> Signed-off-by: David Vrabel
> ---
> Cc: Kevin Moraga
>
> v3:
> - fold mask_rw_pte()/mask_rw_pteval() into their callers.
>
> v2:
> - Remove __init annotation from xen_make_pte_init() since
> PV_CALLEE_SAVE_REGS_THUNK always puts the thunk in .text.
>
> - mask_rw_pte() -> mask_rw_pteval() for x86-64.
> ---
> arch/x86/xen/mmu.c | 76
> +-
> 1 file changed, 35 insertions(+), 41 deletions(-)
>
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 478a2de..64d8f0b 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1551,41 +1551,6 @@ static void xen_pgd_free(struct mm_struct *mm,
> pgd_t *pgd)
> #endif
> }
>
> -#ifdef CONFIG_X86_32
> -static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
> -{
> - /* If there's an existing pte, then don't allow _PAGE_RW to be set */
> - if (pte_val_ma(*ptep) & _PAGE_PRESENT)
> - pte = __pte_ma(((pte_val_ma(*ptep) & _PAGE_RW) | ~_PAGE_RW) &
> -pte_val_ma(pte));
> -
> - return pte;
> -}
> -#else /* CONFIG_X86_64 */
> -static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
> -{
> - unsigned long pfn;
> -
> - if (xen_feature(XENFEAT_writable_page_tables) ||
> - xen_feature(XENFEAT_auto_translated_physmap) ||
> - xen_start_info->mfn_list >= __START_KERNEL_map)
> - return pte;
> -
> - /*
> - * Pages belonging to the initial p2m list mapped outside the default
> - * address range must be mapped read-only. This region contains the
> - * page tables for mapping the p2m list, too, and page tables MUST be
> - * mapped read-only.
> - */
> - pfn = pte_pfn(pte);
> - if (pfn >= xen_start_info->first_p2m_pfn &&
> - pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_frames)
> - pte = __pte_ma(pte_val_ma(pte) & ~_PAGE_RW);
> -
> - return pte;
> -}
> -#endif /* CONFIG_X86_64 */
> -
> /*
> * Init-time set_pte while constructing initial pagetables, which
> * doesn't allow RO page table pages to be remapped RW.
> @@ -1600,13 +1565,41 @@ static pte_t __init mask_rw_pte(pte_t *ptep,
> pte_t pte)
> * so always write the PTE directly and rely on Xen trapping and
> * emulating any updates as necessary.
> */
> -static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
> +__visible pte_t xen_make_pte_init(pteval_t pte)
> {
> - if (pte_mfn(pte) != INVALID_P2M_ENTRY)
> - pte = mask_rw_pte(ptep, pte);
> - else
> - pte = __pte_ma(0);
> +#ifdef CONFIG_X86_64
> + unsigned long pfn;
> +
> + /*
> + * Pages belonging to the initial p2m list mapped outside the default
> + * address range must be mapped read-only. This region contains the
> + * page tables for mapping the p2m list, too, and page tables MUST be
> + * mapped read-only.
> + */
> + pfn = (pte & PTE_PFN_MASK) >> PAGE_SHIFT;
> + if (xen_start_info->mfn_list < __START_KERNEL_map &&
> + pfn >= xen_start_info->first_p2m_pfn &&
> + pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_frames)
> + pte &= ~_PAGE_RW;
> +#endif
> + pte = pte_pfn_to_mfn(pte);
>
> + if ((pte & PTE_PFN_MASK) >> PAGE_SHIFT == INVALID_P2M_ENTRY)
How can this ever be true? I know this is just the open coded
variant form the original xen_set_pte_init(). Either the if isn't
needed at all or it should be corrected.
>>>
>>> The frame might be ballooned out.
>>
>> Okay. But how do you get the 64 bit value with all bits set by shifting
>> an unsigned value to the right (I admit that this is possible on a 32
>> bit dom0, but I doubt that was the intention of the test)?
>
> pte_pfn_to_mfn() already does the right thing so this test is bogus.
> I've removed it.
>
> Can I add your acked-by or reviewed-by with this change?
Yes, with
Re: [Xen-devel] [PATCH v2] ArmVirtPkg/ArmVirtXen: Add ACPI support for Virt Xen ARM
On 23 June 2016 at 13:31, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Add ACPI support for Virt Xen ARM and only for aarch64. It gets the
> ACPI tables through Xen ARM multiboot protocol.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Shannon Zhao
> ---
> Changes since v1:
> * move the codes into ArmVirtPkg
> * use FdtClient
> * don't rely on OvmfPkg/AcpiPlatformDxe/EntryPoint.c while implement own
> entry point since it's minor
> * use compatible string to find the DT node instead of node path
>
> If you want to test, the corresponding Xen patches can be fetched from:
> https://git.linaro.org/people/shannon.zhao/xen.git domu_acpi_v2
> ---
> ArmVirtPkg/ArmVirtXen.dsc | 8 +
> ArmVirtPkg/ArmVirtXen.fdf | 8 +
> ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c | 241
> +
> .../XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf | 49 +
> 4 files changed, 306 insertions(+)
> create mode 100644 ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
> create mode 100644 ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
>
> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
> index 594ca64..a869986 100644
> --- a/ArmVirtPkg/ArmVirtXen.dsc
> +++ b/ArmVirtPkg/ArmVirtXen.dsc
> @@ -216,3 +216,11 @@
>
>OvmfPkg/XenBusDxe/XenBusDxe.inf
>OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> +
> + #
> + # ACPI support
> + #
> +!if $(ARCH) == AARCH64
> + MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> + ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
> +!endif
> diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
> index 13412f9..b1e00e5 100644
> --- a/ArmVirtPkg/ArmVirtXen.fdf
> +++ b/ArmVirtPkg/ArmVirtXen.fdf
> @@ -179,6 +179,14 @@ READ_LOCK_STATUS = TRUE
>INF OvmfPkg/XenBusDxe/XenBusDxe.inf
>INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
>
> + #
> + # ACPI support
> + #
> +!if $(ARCH) == AARCH64
> + INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> + INF ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
> +!endif
> +
> [FV.FVMAIN_COMPACT]
> FvAlignment= 16
> ERASE_POLARITY = 1
> diff --git a/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
> b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
> new file mode 100644
> index 000..9258be8
> --- /dev/null
> +++ b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
> @@ -0,0 +1,241 @@
> +/** @file
> + Xen ARM ACPI Platform Driver using Xen ARM multiboot protocol
> +
> + Copyright (C) 2016, Linaro Ltd. All rights reserved.
> +
> + This program and the accompanying materials
> + are licensed and made available under the terms and conditions of the BSD
> License
> + which accompanies this distribution. The full text of the license may be
> found at
> + http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
> IMPLIED.
> +
> +**/
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +
> +EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *XenAcpiRsdpStructurePtr =
> NULL;
> +
Does this need to be a global? If yes, please add STATIC, and prefix
the name with 'm'. Otherwise, move it into InstallXenArmTables ().
> +/**
> + Get the address of Xen ACPI Root System Description Pointer (RSDP)
> + structure.
> +
> + @param RsdpStructurePtr Return pointer to RSDP structure
> +
> + @return EFI_SUCCESSFind Xen RSDP structure successfully.
> + @return EFI_NOT_FOUND Don't find Xen RSDP structure.
> + @return EFI_ABORTEDFind Xen RSDP structure, but it's not
> integrated.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +GetXenArmAcpiRsdp (
... and here
> + OUT EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER **RsdpPtr
> + )
> +{
> + EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *RsdpStructurePtr;
> + EFI_STATUS Status;
> + FDT_CLIENT_PROTOCOL*FdtClient;
> + CONST UINT64 *Reg;
> + UINT32 RegElemSize, RegSize;
> + UINT64 RegBase;
> + UINT8 Sum;
> +
> + RsdpStructurePtr = NULL;
Please initialize FdtClient to NULL here.
> + //
> + // Get the RSDP structure address from DeviceTree
> + //
> + Status = gBS->LocateProtocol (&gFdtClientProtocolGuid, NULL,
Please add gFdtClientProtocolGuid to the [Depex] section of this module
> + (VOID **)&FdtClient);
> + ASSERT_EFI_ERROR (Status);
> +
> + Status = FdtClient->FindCompatibleNodeReg (FdtClient, "xen,guest-acpi",
> +(CONST VOID **)&Reg, &RegElemSize, &RegSize);
> + if (EFI_ERROR (Status)) {
> +DEBUG ((EFI_D_WARN, "%a: No 'xen,guest-acpi' compatible
Re: [Xen-devel] [PATCH v3 4/8] xen: Use typesafe gfn in xenmem_add_to_physmap_one
On Tue, 21 Jun 2016, Julien Grall wrote:
> The x86 version of the function xenmem_add_to_physmap_one contains
> variable name gpfn and gfn which make the code very confusing.
> I have left unchanged for now.
>
> Also, rename gpfn to gfn in the ARM version as the latter is the correct
> acronym for a guest physical frame.
>
> Finally, remove the trailing whitespace around the changes.
>
> Signed-off-by: Julien Grall
> Acked-by: Jan Beulich
Acked-by: Stefano Stabellini
> ---
> Cc: Stefano Stabellini
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Konrad Rzeszutek Wilk
> Cc: Tim Deegan
> Cc: Wei Liu
>
> Changes in v3:
> - Add Jan's acked-by for non-ARM bits
> ---
> xen/arch/arm/mm.c| 10 +-
> xen/arch/x86/mm.c| 15 +++
> xen/common/memory.c | 6 +++---
> xen/include/xen/mm.h | 2 +-
> 4 files changed, 16 insertions(+), 17 deletions(-)
>
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 5ab9b75..6882d54 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1046,7 +1046,7 @@ int xenmem_add_to_physmap_one(
> unsigned int space,
> union xen_add_to_physmap_batch_extra extra,
> unsigned long idx,
> -xen_pfn_t gpfn)
> +gfn_t gfn)
> {
> unsigned long mfn = 0;
> int rc;
> @@ -1081,8 +1081,8 @@ int xenmem_add_to_physmap_one(
> else
> return -EINVAL;
> }
> -
> -d->arch.grant_table_gpfn[idx] = gpfn;
> +
> +d->arch.grant_table_gpfn[idx] = gfn_x(gfn);
>
> t = p2m_ram_rw;
>
> @@ -1145,7 +1145,7 @@ int xenmem_add_to_physmap_one(
> if ( extra.res0 )
> return -EOPNOTSUPP;
>
> -rc = map_dev_mmio_region(d, gpfn, 1, idx);
> +rc = map_dev_mmio_region(d, gfn_x(gfn), 1, idx);
> return rc;
>
> default:
> @@ -1153,7 +1153,7 @@ int xenmem_add_to_physmap_one(
> }
>
> /* Map at new location. */
> -rc = guest_physmap_add_entry(d, _gfn(gpfn), _mfn(mfn), 0, t);
> +rc = guest_physmap_add_entry(d, gfn, _mfn(mfn), 0, t);
>
> /* If we fail to add the mapping, we need to drop the reference we
> * took earlier on foreign pages */
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 7fbc94e..dbcf6cb 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4775,7 +4775,7 @@ int xenmem_add_to_physmap_one(
> unsigned int space,
> union xen_add_to_physmap_batch_extra extra,
> unsigned long idx,
> -xen_pfn_t gpfn)
> +gfn_t gpfn)
> {
> struct page_info *page = NULL;
> unsigned long gfn = 0; /* gcc ... */
> @@ -4834,7 +4834,7 @@ int xenmem_add_to_physmap_one(
> break;
> }
> case XENMAPSPACE_gmfn_foreign:
> -return p2m_add_foreign(d, idx, gpfn, extra.foreign_domid);
> +return p2m_add_foreign(d, idx, gfn_x(gpfn), extra.foreign_domid);
> default:
> break;
> }
> @@ -4849,19 +4849,18 @@ int xenmem_add_to_physmap_one(
> }
>
> /* Remove previously mapped page if it was present. */
> -prev_mfn = mfn_x(get_gfn(d, gpfn, &p2mt));
> +prev_mfn = mfn_x(get_gfn(d, gfn_x(gpfn), &p2mt));
> if ( mfn_valid(prev_mfn) )
> {
> if ( is_xen_heap_mfn(prev_mfn) )
> /* Xen heap frames are simply unhooked from this phys slot. */
> -guest_physmap_remove_page(d, _gfn(gpfn), _mfn(prev_mfn),
> - PAGE_ORDER_4K);
> +guest_physmap_remove_page(d, gpfn, _mfn(prev_mfn),
> PAGE_ORDER_4K);
> else
> /* Normal domain memory is freed, to avoid leaking memory. */
> -guest_remove_page(d, gpfn);
> +guest_remove_page(d, gfn_x(gpfn));
> }
> /* In the XENMAPSPACE_gmfn case we still hold a ref on the old page. */
> -put_gfn(d, gpfn);
> +put_gfn(d, gfn_x(gpfn));
>
> /* Unmap from old location, if any. */
> old_gpfn = get_gpfn_from_mfn(mfn);
> @@ -4872,7 +4871,7 @@ int xenmem_add_to_physmap_one(
> guest_physmap_remove_page(d, _gfn(old_gpfn), _mfn(mfn),
> PAGE_ORDER_4K);
>
> /* Map at new location. */
> -rc = guest_physmap_add_page(d, _gfn(gpfn), _mfn(mfn), PAGE_ORDER_4K);
> +rc = guest_physmap_add_page(d, gpfn, _mfn(mfn), PAGE_ORDER_4K);
>
> /* In the XENMAPSPACE_gmfn, we took a ref of the gfn at the top */
> if ( space == XENMAPSPACE_gmfn || space == XENMAPSPACE_gmfn_range )
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index a8a75e0..812334b 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -649,7 +649,7 @@ static int xenmem_add_to_physmap(struct domain *d,
>
> if ( xatp->space != XENMAPSPACE_gmfn_range )
> return xenmem_add_to_physmap_one(d, xatp->space, extra,
> - xatp->idx, xatp->gpfn);
> + xatp->idx, _gfn(xatp-
Re: [Xen-devel] [PATCH v3 5/8] xen/arm: Rename grant_table_gfpn into grant_table_gfn and use the typesafe gfn
On Tue, 21 Jun 2016, Julien Grall wrote:
> The correct acronym for a guest physical frame is gfn. Also use
> the typesafe gfn to ensure that a guest frame is effectively used.
>
> Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
> ---
> Changes in v2:
> - Remove extra pair of brackets.
> ---
> xen/arch/arm/domain.c | 4 ++--
> xen/arch/arm/mm.c | 2 +-
> xen/include/asm-arm/domain.h | 2 +-
> xen/include/asm-arm/grant_table.h | 2 +-
> 4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index d8a804c..6ce4645 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -464,13 +464,13 @@ struct domain *alloc_domain_struct(void)
> return NULL;
>
> clear_page(d);
> -d->arch.grant_table_gpfn = xzalloc_array(xen_pfn_t, max_grant_frames);
> +d->arch.grant_table_gfn = xzalloc_array(gfn_t, max_grant_frames);
> return d;
> }
>
> void free_domain_struct(struct domain *d)
> {
> -xfree(d->arch.grant_table_gpfn);
> +xfree(d->arch.grant_table_gfn);
> free_xenheap_page(d);
> }
>
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 6882d54..0e408f8 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1082,7 +1082,7 @@ int xenmem_add_to_physmap_one(
> return -EINVAL;
> }
>
> -d->arch.grant_table_gpfn[idx] = gfn_x(gfn);
> +d->arch.grant_table_gfn[idx] = gfn;
>
> t = p2m_ram_rw;
>
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 370cdeb..979f7de 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -51,7 +51,7 @@ struct arch_domain
> uint64_t vttbr;
>
> struct hvm_domain hvm_domain;
> -xen_pfn_t *grant_table_gpfn;
> +gfn_t *grant_table_gfn;
>
> struct vmmio vmmio;
>
> diff --git a/xen/include/asm-arm/grant_table.h
> b/xen/include/asm-arm/grant_table.h
> index 5e076cc..eb02423 100644
> --- a/xen/include/asm-arm/grant_table.h
> +++ b/xen/include/asm-arm/grant_table.h
> @@ -30,7 +30,7 @@ static inline int replace_grant_supported(void)
>
> #define gnttab_shared_gmfn(d, t, i) \
> ( ((i >= nr_grant_frames(d->grant_table)) && \
> - (i < max_grant_frames)) ? 0 : (d->arch.grant_table_gpfn[i]))
> + (i < max_grant_frames)) ? 0 : gfn_x(d->arch.grant_table_gfn[i]))
>
> #define gnttab_need_iommu_mapping(d)\
> (is_domain_direct_mapped(d) && need_iommu(d))
> --
> 1.9.1
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 6/8] xen: Use the typesafe mfn and gfn in map_mmio_regions...
On Tue, 21 Jun 2016, Julien Grall wrote:
> to avoid mixing machine frame with guest frame.
>
> Signed-off-by: Julien Grall
> Acked-by: Jan Beulich
>
> ---
> Cc: Stefano Stabellini
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Konrad Rzeszutek Wilk
> Cc: Tim Deegan
> Cc: Wei Liu
>
> Changes in v3:
> - Use mfn_add when it is possible
> - Add Jan's acked-by
> ---
> xen/arch/arm/domain_build.c | 4 ++--
> xen/arch/arm/gic-v2.c| 4 ++--
> xen/arch/arm/p2m.c | 22 +++---
> xen/arch/arm/platforms/exynos5.c | 8
> xen/arch/arm/platforms/omap5.c | 16
> xen/arch/arm/vgic-v2.c | 4 ++--
> xen/arch/x86/mm/p2m.c| 18 ++
> xen/common/domctl.c | 4 ++--
> xen/include/xen/p2m-common.h | 8
> 9 files changed, 45 insertions(+), 43 deletions(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 9035486..49185f0 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1036,9 +1036,9 @@ static int map_range_to_domain(const struct
> dt_device_node *dev,
> if ( need_mapping )
> {
> res = map_mmio_regions(d,
> - paddr_to_pfn(addr),
> + _gfn(paddr_to_pfn(addr)),
> DIV_ROUND_UP(len, PAGE_SIZE),
> - paddr_to_pfn(addr));
> + _mfn(paddr_to_pfn(addr)));
> if ( res < 0 )
> {
> printk(XENLOG_ERR "Unable to map 0x%"PRIx64
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 4e2f4c7..3893ece 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -601,9 +601,9 @@ static int gicv2_map_hwdown_extra_mappings(struct domain
> *d)
> d->domain_id, v2m_data->addr, v2m_data->size,
> v2m_data->spi_start, v2m_data->nr_spis);
>
> -ret = map_mmio_regions(d, paddr_to_pfn(v2m_data->addr),
> +ret = map_mmio_regions(d, _gfn(paddr_to_pfn(v2m_data->addr)),
> DIV_ROUND_UP(v2m_data->size, PAGE_SIZE),
> -paddr_to_pfn(v2m_data->addr));
> +_mfn(paddr_to_pfn(v2m_data->addr)));
> if ( ret )
> {
> printk(XENLOG_ERR "GICv2: Map v2m frame to d%d failed.\n",
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index aa4e774..47cb383 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1245,27 +1245,27 @@ int unmap_regions_rw_cache(struct domain *d,
> }
>
> int map_mmio_regions(struct domain *d,
> - unsigned long start_gfn,
> + gfn_t start_gfn,
> unsigned long nr,
> - unsigned long mfn)
> + mfn_t mfn)
> {
> return apply_p2m_changes(d, INSERT,
> - pfn_to_paddr(start_gfn),
> - pfn_to_paddr(start_gfn + nr),
> - pfn_to_paddr(mfn),
> + pfn_to_paddr(gfn_x(start_gfn)),
> + pfn_to_paddr(gfn_x(start_gfn) + nr),
> + pfn_to_paddr(mfn_x(mfn)),
> MATTR_DEV, 0, p2m_mmio_direct,
> d->arch.p2m.default_access);
Any reason why you didn't push these changes down to apply_p2m_changes too?
> }
>
> int unmap_mmio_regions(struct domain *d,
> - unsigned long start_gfn,
> + gfn_t start_gfn,
> unsigned long nr,
> - unsigned long mfn)
> + mfn_t mfn)
> {
> return apply_p2m_changes(d, REMOVE,
> - pfn_to_paddr(start_gfn),
> - pfn_to_paddr(start_gfn + nr),
> - pfn_to_paddr(mfn),
> + pfn_to_paddr(gfn_x(start_gfn)),
> + pfn_to_paddr(gfn_x(start_gfn) + nr),
> + pfn_to_paddr(mfn_x(mfn)),
> MATTR_DEV, 0, p2m_invalid,
> d->arch.p2m.default_access);
> }
> @@ -1280,7 +1280,7 @@ int map_dev_mmio_region(struct domain *d,
> if ( !(nr && iomem_access_permitted(d, start_gfn, start_gfn + nr - 1)) )
> return 0;
>
> -res = map_mmio_regions(d, start_gfn, nr, mfn);
> +res = map_mmio_regions(d, _gfn(start_gfn), nr, _mfn(mfn));
> if ( res < 0 )
> {
> printk(XENLOG_G_ERR "Unable to map [%#lx - %#lx] in Dom%d\n",
> diff --git a/xen/arch/arm/platforms/exynos5.c
> b/xen/arch/arm/platforms/exynos5.c
> index bf4964d..c43934f 100644
> --- a/xen/arch/arm/platforms/exynos5.c
> +++ b/xen/arch/arm/platforms/exynos5.c
> @@ -
Re: [Xen-devel] [PATCH v3 6/8] xen: Use the typesafe mfn and gfn in map_mmio_regions...
On 23/06/16 15:05, Stefano Stabellini wrote:
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index aa4e774..47cb383 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1245,27 +1245,27 @@ int unmap_regions_rw_cache(struct domain *d,
}
int map_mmio_regions(struct domain *d,
- unsigned long start_gfn,
+ gfn_t start_gfn,
unsigned long nr,
- unsigned long mfn)
+ mfn_t mfn)
{
return apply_p2m_changes(d, INSERT,
- pfn_to_paddr(start_gfn),
- pfn_to_paddr(start_gfn + nr),
- pfn_to_paddr(mfn),
+ pfn_to_paddr(gfn_x(start_gfn)),
+ pfn_to_paddr(gfn_x(start_gfn) + nr),
+ pfn_to_paddr(mfn_x(mfn)),
MATTR_DEV, 0, p2m_mmio_direct,
d->arch.p2m.default_access);
Any reason why you didn't push these changes down to apply_p2m_changes too?
To keep this series simple. I have another series coming up to push the
change down to apply_p2m_changes and clean up the P2M code.
I can move the patch to push down the change in this series if you prefer.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"
On 23/06/16 14:25, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 23, 2016 at 03:46:46AM -0600, Jan Beulich wrote:
> On 23.06.16 at 11:23, wrote:
>>> On Thu, Jun 23, 2016 at 11:18:24AM +0200, Marek Marczykowski-Górecki wrote:
On Thu, Jun 23, 2016 at 03:12:47AM -0600, Jan Beulich wrote:
On 23.06.16 at 10:57, wrote:
>> On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote:
>>> I wonder what good the duplication of the returned domain ID does: I'm
>>> tempted to remove the one in the command-specific structure. Does
>>> anyone have insight into why it was done that way?
>> Isn't XEN_DOMCTL_getdomaininfo supposed to return info about first
>> existing domain with ID >= passed one? Reading various comments in code
>> it looks to be used to domain enumeration. This patch changes this
>> behaviour.
> No, it doesn't. It adjusts the behavior only for the DM case (which
> isn't supposed to get information on other than the target domain,
> i.e. in this one specific case the very domain ID needs to be passed
> in).
int xc_domain_getinfo(xc_interface *xch,
uint32_t first_domid,
unsigned int max_doms,
xc_dominfo_t *info)
{
unsigned int nr_doms;
uint32_t next_domid = first_domid;
DECLARE_DOMCTL;
int rc = 0;
memset(info, 0, max_doms*sizeof(xc_dominfo_t));
for ( nr_doms = 0; nr_doms < max_doms; nr_doms++ )
{
domctl.cmd = XEN_DOMCTL_getdomaininfo;
domctl.domain = (domid_t)next_domid;
if ( (rc = do_domctl(xch, &domctl)) < 0 )
break;
info->domid = (uint16_t)domctl.domain;
(...)
next_domid = (uint16_t)domctl.domain + 1;
Looks like heavily dependent on XEN_DOMCTL_getdomaininfo returning next
>>> valid
domain.
>>> Hmm, looks like I've misread you patch. Reading again...
>>>
>>> But now I see rcu_read_lock(&domlist_read_lock) is gets called only when
>>> looping over domains, but rcu_read_unlock is called in any case. Is it
>>> correct?
>> How that? There is this third hunk:
> Ok, after drawing a flowchart of the control in this function after your
> change, on a piece of paper, this case looks fine. But depending on how
> the domain was found (explicit loop or rcu_lock_domain_by_id), different
> locks are held, which makes it harder to follow what is going on.
>
> Crazy idea: how about making the code easy/easier to read instead of
> obfuscating it even more? XEN_DOMCTL_getdomaininfo semantic is
> convolved enough. How about this version (2 patches):
>
> xen: move domain lookup for getdomaininfo to the same
>
> XEN_DOMCTL_getdomaininfo have different semantics than most of others
> domctls - it returns information about first valid domain with ID >=
> argument. But that's no excuse for having the lookup done in a different
> place, which made handling different corner cases unnecessary complex.
> Move the lookup to the first switch clause. And adjust locking to be the
> same as for other cases.
>
> Signed-off-by: Marek Marczykowski-Górecki
FWIW, I prefer this solution to the issue.
Reviewed-by: Andrew Cooper , with a few style
nits.
> ---
> xen/common/domctl.c | 41 -
> 1 file changed, 20 insertions(+), 21 deletions(-)
>
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index e43904e..6ae1fe0 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -442,11 +442,29 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
> u_domctl)
> switch ( op->cmd )
> {
> case XEN_DOMCTL_createdomain:
> -case XEN_DOMCTL_getdomaininfo:
> case XEN_DOMCTL_test_assign_device:
> case XEN_DOMCTL_gdbsx_guestmemio:
> d = NULL;
> break;
Newline here please.
> +case XEN_DOMCTL_getdomaininfo:
> +d = rcu_lock_domain_by_id(op->domain);
And here.
> +if ( d == NULL )
> +{
> +/* search for the next valid domain */
/* Search for the next available domain. */
> +rcu_read_lock(&domlist_read_lock);
> +
> +for_each_domain ( d )
> +if ( d->domain_id >= op->domain )
> +{
> +rcu_lock_domain(d);
> +break;
> +}
> +
> +rcu_read_unlock(&domlist_read_lock);
> +if ( d == NULL )
> +return -ESRCH;
> +}
> +break;
Another newline here please.
> default:
> d = rcu_lock_domain_by_id(op->domain);
> if ( d == NULL )
> @@ -862,33 +880,14 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
> u_domctl)
> break;
>
> case XEN_DOMCTL_getdomaininfo:
> -{
> -domid_t dom = op->domain;
> -
> -rcu_read_lock(&domlist_read_lock);
> -
> -for_each_domain
Re: [Xen-devel] [PATCH v3 7/8] xen/arm: Rework the interface of p2m_lookup and use typesafe gfn and mfn
On Tue, 21 Jun 2016, Julien Grall wrote:
> The prototype and the declaration of p2m_lookup disagree on how the
> function should be used. One expect a frame number whilst the other
> an address.
>
> Thankfully, everyone is using with an address today. However, most of
> the callers have to convert a guest frame to an address. Modify
> the interface to take a guest physical frame in parameter and return
> a machine frame.
>
> Whilst modifying the interface, use typesafe gfn and mfn for clarity
> and catching possible misusage.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/p2m.c| 37 -
> xen/arch/arm/traps.c | 21 +++--
> xen/include/asm-arm/p2m.h | 7 +++
> 3 files changed, 34 insertions(+), 31 deletions(-)
>
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 47cb383..f3330dd 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -140,14 +140,15 @@ void flush_tlb_domain(struct domain *d)
> }
>
> /*
> - * Lookup the MFN corresponding to a domain's PFN.
> + * Lookup the MFN corresponding to a domain's GFN.
> *
> * There are no processor functions to do a stage 2 only lookup therefore we
> * do a a software walk.
> */
> -static paddr_t __p2m_lookup(struct domain *d, paddr_t paddr, p2m_type_t *t)
> +static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
> {
> struct p2m_domain *p2m = &d->arch.p2m;
> +const paddr_t paddr = pfn_to_paddr(gfn_x(gfn));
> const unsigned int offsets[4] = {
> zeroeth_table_offset(paddr),
> first_table_offset(paddr),
> @@ -158,7 +159,7 @@ static paddr_t __p2m_lookup(struct domain *d, paddr_t
> paddr, p2m_type_t *t)
> ZEROETH_MASK, FIRST_MASK, SECOND_MASK, THIRD_MASK
> };
> lpae_t pte, *map;
> -paddr_t maddr = INVALID_PADDR;
> +mfn_t mfn = _mfn(INVALID_MFN);
It might be worth defining INVALID_MFN_T and just assign that to mfn.
> paddr_t mask = 0;
> p2m_type_t _t;
> unsigned int level, root_table;
> @@ -216,21 +217,22 @@ static paddr_t __p2m_lookup(struct domain *d, paddr_t
> paddr, p2m_type_t *t)
> {
> ASSERT(mask);
> ASSERT(pte.p2m.type != p2m_invalid);
> -maddr = (pte.bits & PADDR_MASK & mask) | (paddr & ~mask);
> +mfn = _mfn(paddr_to_pfn((pte.bits & PADDR_MASK & mask) |
> +(paddr & ~mask)));
> *t = pte.p2m.type;
> }
>
> err:
> -return maddr;
> +return mfn;
> }
>
> -paddr_t p2m_lookup(struct domain *d, paddr_t paddr, p2m_type_t *t)
> +mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
> {
> -paddr_t ret;
> +mfn_t ret;
> struct p2m_domain *p2m = &d->arch.p2m;
>
> spin_lock(&p2m->lock);
> -ret = __p2m_lookup(d, paddr, t);
> +ret = __p2m_lookup(d, gfn, t);
> spin_unlock(&p2m->lock);
>
> return ret;
> @@ -493,8 +495,9 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t
> gfn,
> * No setting was found in the Radix tree. Check if the
> * entry exists in the page-tables.
> */
> -paddr_t maddr = __p2m_lookup(d, gfn_x(gfn) << PAGE_SHIFT, NULL);
> -if ( INVALID_PADDR == maddr )
> +mfn_t mfn = __p2m_lookup(d, gfn, NULL);
> +
> +if ( mfn_x(mfn) == INVALID_MFN )
> return -ESRCH;
>
> /* If entry exists then its rwx. */
> @@ -1483,8 +1486,7 @@ int p2m_cache_flush(struct domain *d, xen_pfn_t
> start_mfn, xen_pfn_t end_mfn)
>
> mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn)
> {
> -paddr_t p = p2m_lookup(d, pfn_to_paddr(gfn_x(gfn)), NULL);
> -return _mfn(p >> PAGE_SHIFT);
> +return p2m_lookup(d, gfn, NULL);
> }
>
> /*
> @@ -1498,7 +1500,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned
> long flag)
> {
> long rc;
> paddr_t ipa;
> -unsigned long maddr;
> +gfn_t gfn;
> unsigned long mfn;
> xenmem_access_t xma;
> p2m_type_t t;
> @@ -1508,11 +1510,13 @@ p2m_mem_access_check_and_get_page(vaddr_t gva,
> unsigned long flag)
> if ( rc < 0 )
> goto err;
>
> +gfn = _gfn(paddr_to_pfn(ipa));
> +
> /*
> * We do this first as this is faster in the default case when no
> * permission is set on the page.
> */
> -rc = __p2m_get_mem_access(current->domain, _gfn(paddr_to_pfn(ipa)),
> &xma);
> +rc = __p2m_get_mem_access(current->domain, gfn, &xma);
> if ( rc < 0 )
> goto err;
>
> @@ -1561,11 +1565,10 @@ p2m_mem_access_check_and_get_page(vaddr_t gva,
> unsigned long flag)
> * We had a mem_access permission limiting the access, but the page type
> * could also be limiting, so we need to check that as well.
> */
> -maddr = __p2m_lookup(current->domain, ipa, &t);
> -if ( maddr == INVALID_PADDR )
> +mfn = mfn_x(__p2m_lookup(current->domain, gfn, &t));
> +if ( mfn == INVALID_MFN )
The conversion would go away if
Re: [Xen-devel] [PATCH v3 6/8] xen: Use the typesafe mfn and gfn in map_mmio_regions...
On Thu, 23 Jun 2016, Julien Grall wrote:
> On 23/06/16 15:05, Stefano Stabellini wrote:
> > > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > > index aa4e774..47cb383 100644
> > > --- a/xen/arch/arm/p2m.c
> > > +++ b/xen/arch/arm/p2m.c
> > > @@ -1245,27 +1245,27 @@ int unmap_regions_rw_cache(struct domain *d,
> > > }
> > >
> > > int map_mmio_regions(struct domain *d,
> > > - unsigned long start_gfn,
> > > + gfn_t start_gfn,
> > >unsigned long nr,
> > > - unsigned long mfn)
> > > + mfn_t mfn)
> > > {
> > > return apply_p2m_changes(d, INSERT,
> > > - pfn_to_paddr(start_gfn),
> > > - pfn_to_paddr(start_gfn + nr),
> > > - pfn_to_paddr(mfn),
> > > + pfn_to_paddr(gfn_x(start_gfn)),
> > > + pfn_to_paddr(gfn_x(start_gfn) + nr),
> > > + pfn_to_paddr(mfn_x(mfn)),
> > >MATTR_DEV, 0, p2m_mmio_direct,
> > >d->arch.p2m.default_access);
> >
> > Any reason why you didn't push these changes down to apply_p2m_changes too?
>
> To keep this series simple. I have another series coming up to push the change
> down to apply_p2m_changes and clean up the P2M code.
>
> I can move the patch to push down the change in this series if you prefer.
Yeah, it makes sense to keep them together.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"
On 23/06/16 10:50, Jan Beulich wrote: On 23.06.16 at 11:44, wrote: >> On 23/06/16 09:32, Jan Beulich wrote: >>> I wonder what good the duplication of the returned domain ID does: I'm >>> tempted to remove the one in the command-specific structure. Does >>> anyone have insight into why it was done that way? >> This hypercall, and its sibling XEN_SYSCTL_getdomaininfolist have crazy >> semantics, which go out of their way to make it easy to get wrong. >> >> It is important that you always check the returned domid, as it may not >> be the domain you asked for. In particular, if a domain you are looking >> after dies, the adjacent domain's information will be returnned. > Same question as to Marek: How is this related to my remark? Oh right. I misread. Altering the domctl domid value is pointless, as libxc abstracts the call behind do_domctl() anyway. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-upstream-4.3-testing test] 96152: regressions - FAIL
flight 96152 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/96152/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-build fail REGR. vs. 80927 build-i386-libvirt5 libvirt-build fail REGR. vs. 80927 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 80927 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 80927 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass version targeted for testing: qemuu12e8fccf5b5460be7aecddc71d27eceaba6e1f15 baseline version: qemuu10c1b763c26feb645627a1639e722515f3e1e876 Last test of basis80927 2016-02-06 13:30:02 Z 138 days Failing since 93977 2016-05-10 11:09:16 Z 44 days 142 attempts Testing same since95534 2016-06-11 00:59:46 Z 12 days 22 attempts People who touched revisions under test: Anthony PERARD Gerd Hoffmann Ian Jackson Stefano Stabellini Wei Liu jobs: build-amd64 pass build-i386 pass build-amd64-libvirt fail build-i386-libvirt fail build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-i386-xl pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-credit2 pass test-amd64-i386-freebsd10-i386 pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-xl-multivcpupass test-amd64-amd64-pairpass test-amd64-i386-pair pass test-amd64-amd64-pv pass test-amd64-i386-pv pass test-amd64-amd64-amd64-pvgrubpass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2pass test-amd64-i386-xl-raw pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-amd64-libvirt-vhd blocked test-amd64-amd64-xl-qemuu-winxpsp3 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit 12e8fccf5b5460be7aecddc71d27eceaba6e1f15 Author: Ian Jackson Date: Thu May 26 16:21:56 2016 +0100 main loop: Big hammer to fix logfile disk DoS in Xen setups Each time round the main loop, we now fstat stderr. If it is too big, we dup2 /dev/null onto it. This is not a very pretty patch but it is
Re: [Xen-devel] [PATCH v2 04/17] libxl/arm: prepare for constructing ACPI tables
On 2016年06月23日 21:37, Stefano Stabellini wrote:
> On Thu, 23 Jun 2016, Shannon Zhao wrote:
>> +
>> +if (strcmp(dom->guest_type, "xen-3.0-aarch64")) {
>> +LOG(DEBUG, "Do not generate ACPI tables for %s", dom->guest_type);
>> +state->config.acpi = false;
>
> Shouldn't we return here?
>
Ah, right, thanks!
>
>> +}
>> +
>> +return libxl__prepare_acpi(gc, info, state, dom);
>> }
>>
>> static void finalise_one_memory_node(libxl__gc *gc, void *fdt,
>> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
>> new file mode 100644
>> index 000..60c31f9
>> --- /dev/null
>> +++ b/tools/libxl/libxl_arm_acpi.c
>> @@ -0,0 +1,85 @@
>> +/*
>> + * ARM DmoU ACPI generation
>> + *
>> + * Copyright (C) 2008-2010 Kevin O'Connor
>> + * Copyright (C) 2006 Fabrice Bellard
>> + * Copyright (C) 2013 Red Hat Inc
>> + *
>> + * Author: Michael S. Tsirkin
>> + *
>> + * Copyright (c) 2015 HUAWEI TECHNOLOGIES CO.,LTD.
>> + *
>> + * Author: Shannon Zhao
>> + *
>> + * Copyright (C) 2016 Linaro Ltd.
>> + *
>> + * Author: Shannon Zhao
>
> Uhm... If in doubt just remove all the Author lines: git log provides
> more than enough information about who wrote this code.
>
Ahm... Julien suggested I should import the copyright from QEMU since I
refer to that. While what I didn't say before is that even if I didn't
refer to QEMU codes, the implementation will be like this because for
the tables except DSDT we just fill in the contents of the tables. But
for DSDT generation, it's totally different compared with QEMU.
I think I'll remove this. :)
Thanks,
--
Shannon
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 04/17] libxl/arm: prepare for constructing ACPI tables
On Thu, 23 Jun 2016, Shannon Zhao wrote:
> On 2016年06月23日 21:37, Stefano Stabellini wrote:
> > On Thu, 23 Jun 2016, Shannon Zhao wrote:
> >> +
> >> +if (strcmp(dom->guest_type, "xen-3.0-aarch64")) {
> >> +LOG(DEBUG, "Do not generate ACPI tables for %s", dom->guest_type);
> >> +state->config.acpi = false;
> >
> > Shouldn't we return here?
> >
> Ah, right, thanks!
> >
> >> +}
> >> +
> >> +return libxl__prepare_acpi(gc, info, state, dom);
> >> }
> >>
> >> static void finalise_one_memory_node(libxl__gc *gc, void *fdt,
> >> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> >> new file mode 100644
> >> index 000..60c31f9
> >> --- /dev/null
> >> +++ b/tools/libxl/libxl_arm_acpi.c
> >> @@ -0,0 +1,85 @@
> >> +/*
> >> + * ARM DmoU ACPI generation
> >> + *
> >> + * Copyright (C) 2008-2010 Kevin O'Connor
> >> + * Copyright (C) 2006 Fabrice Bellard
> >> + * Copyright (C) 2013 Red Hat Inc
> >> + *
> >> + * Author: Michael S. Tsirkin
> >> + *
> >> + * Copyright (c) 2015 HUAWEI TECHNOLOGIES CO.,LTD.
> >> + *
> >> + * Author: Shannon Zhao
> >> + *
> >> + * Copyright (C) 2016 Linaro Ltd.
> >> + *
> >> + * Author: Shannon Zhao
> >
> > Uhm... If in doubt just remove all the Author lines: git log provides
> > more than enough information about who wrote this code.
> >
> Ahm... Julien suggested I should import the copyright from QEMU since I
> refer to that. While what I didn't say before is that even if I didn't
> refer to QEMU codes, the implementation will be like this because for
> the tables except DSDT we just fill in the contents of the tables. But
> for DSDT generation, it's totally different compared with QEMU.
>
> I think I'll remove this. :)
I see. It's important to keep all the right signed-off-by, acked-by and
reviewed-by in the commit message. But the author list on source files
doesn't make much sense these days.___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] ArmVirtPkg/ArmVirtXen: Add ACPI support for Virt Xen ARM
On 2016年06月23日 21:42, Ard Biesheuvel wrote:
> On 23 June 2016 at 13:31, Shannon Zhao wrote:
>> From: Shannon Zhao
>>
>> Add ACPI support for Virt Xen ARM and only for aarch64. It gets the
>> ACPI tables through Xen ARM multiboot protocol.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Shannon Zhao
>> ---
>> Changes since v1:
>> * move the codes into ArmVirtPkg
>> * use FdtClient
>> * don't rely on OvmfPkg/AcpiPlatformDxe/EntryPoint.c while implement own
>> entry point since it's minor
>> * use compatible string to find the DT node instead of node path
>>
>> If you want to test, the corresponding Xen patches can be fetched from:
>> https://git.linaro.org/people/shannon.zhao/xen.git domu_acpi_v2
>> ---
>> ArmVirtPkg/ArmVirtXen.dsc | 8 +
>> ArmVirtPkg/ArmVirtXen.fdf | 8 +
>> ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c | 241
>> +
>> .../XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf | 49 +
>> 4 files changed, 306 insertions(+)
>> create mode 100644 ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
>> create mode 100644 ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
>>
>> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
>> index 594ca64..a869986 100644
>> --- a/ArmVirtPkg/ArmVirtXen.dsc
>> +++ b/ArmVirtPkg/ArmVirtXen.dsc
>> @@ -216,3 +216,11 @@
>>
>>OvmfPkg/XenBusDxe/XenBusDxe.inf
>>OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
>> +
>> + #
>> + # ACPI support
>> + #
>> +!if $(ARCH) == AARCH64
>> + MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
>> + ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
>> +!endif
>> diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
>> index 13412f9..b1e00e5 100644
>> --- a/ArmVirtPkg/ArmVirtXen.fdf
>> +++ b/ArmVirtPkg/ArmVirtXen.fdf
>> @@ -179,6 +179,14 @@ READ_LOCK_STATUS = TRUE
>>INF OvmfPkg/XenBusDxe/XenBusDxe.inf
>>INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
>>
>> + #
>> + # ACPI support
>> + #
>> +!if $(ARCH) == AARCH64
>> + INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
>> + INF ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
>> +!endif
>> +
>> [FV.FVMAIN_COMPACT]
>> FvAlignment= 16
>> ERASE_POLARITY = 1
>> diff --git a/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
>> b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
>> new file mode 100644
>> index 000..9258be8
>> --- /dev/null
>> +++ b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
>> @@ -0,0 +1,241 @@
>> +/** @file
>> + Xen ARM ACPI Platform Driver using Xen ARM multiboot protocol
>> +
>> + Copyright (C) 2016, Linaro Ltd. All rights reserved.
>> +
>> + This program and the accompanying materials
>> + are licensed and made available under the terms and conditions of the BSD
>> License
>> + which accompanies this distribution. The full text of the license may be
>> found at
>> + http://opensource.org/licenses/bsd-license.php
>> +
>> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
>> IMPLIED.
>> +
>> +**/
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +
>> +#include
>> +
>> +EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *XenAcpiRsdpStructurePtr =
>> NULL;
>> +
>
> Does this need to be a global? If yes, please add STATIC, and prefix
> the name with 'm'. Otherwise, move it into InstallXenArmTables ().
>
Ok, I'll move it to InstallXenArmTables().
>> +/**
>> + Get the address of Xen ACPI Root System Description Pointer (RSDP)
>> + structure.
>> +
>> + @param RsdpStructurePtr Return pointer to RSDP structure
>> +
>> + @return EFI_SUCCESSFind Xen RSDP structure successfully.
>> + @return EFI_NOT_FOUND Don't find Xen RSDP structure.
>> + @return EFI_ABORTEDFind Xen RSDP structure, but it's not
>> integrated.
>> +
>> +**/
>> +EFI_STATUS
>> +EFIAPI
>> +GetXenArmAcpiRsdp (
>
> ... and here
>
Ok.
>> + OUT EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER **RsdpPtr
>> + )
>> +{
>> + EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *RsdpStructurePtr;
>> + EFI_STATUS Status;
>> + FDT_CLIENT_PROTOCOL*FdtClient;
>> + CONST UINT64 *Reg;
>> + UINT32 RegElemSize, RegSize;
>> + UINT64 RegBase;
>> + UINT8 Sum;
>> +
>> + RsdpStructurePtr = NULL;
>
> Please initialize FdtClient to NULL here.
>
Sure.
>> + //
>> + // Get the RSDP structure address from DeviceTree
>> + //
>> + Status = gBS->LocateProtocol (&gFdtClientProtocolGuid, NULL,
>
> Please add gFdtClientProtocolGuid to the [Depex] section of this module
>
Ok.
>> + (VOID **)&FdtClient);
>> + ASSERT_EF
Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"
On 06/23/2016 04:39 AM, Jan Beulich wrote:
On 23.06.16 at 10:32, wrote:
On 22.06.16 at 20:24, wrote:
Either method works, and I agree allowing DM to invoke this domctl is both
useful and not going to introduce problems. The getdomaininfo permission
will also need to be added to the device_model macro in xen.if.
What exactly this last sentence means I need to add I'm not sure
about.
Perhaps this?
--- unstable.orig/tools/flask/policy/policy/modules/xen/xen.if
+++ unstable/tools/flask/policy/policy/modules/xen/xen.if
@@ -148,7 +148,7 @@ define(`device_model', `
create_channel($2, $1, $2_channel)
allow $1 $2_channel:event create;
- allow $1 $2_target:domain shutdown;
+ allow $1 $2_target:domain { getdomaininfo shutdown };
allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack
};
allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl
irqlevel pciroute pcilevel cacheattr send_irq };
')
Jan
Yes, that is what I meant.
--
Daniel De Graaf
National Security Agency
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI
On 2016年06月23日 21:39, Stefano Stabellini wrote:
> On Thu, 23 Jun 2016, Shannon Zhao wrote:
>> > From: Shannon Zhao
>> >
>> > Add a configuration option for ARM DomU so that user can deicde to use
>> > ACPI or not. This option is defaultly false.
>> >
>> > Signed-off-by: Shannon Zhao
>> > ---
>> > tools/libxl/libxl_arm.c | 3 +++
>> > tools/libxl/libxl_types.idl | 1 +
>> > tools/libxl/xl_cmdimpl.c | 4
>> > xen/include/public/arch-arm.h | 1 +
>> > 4 files changed, 9 insertions(+)
>> >
>> > diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
>> > index 8f15d9b..cc5a717 100644
>> > --- a/tools/libxl/libxl_arm.c
>> > +++ b/tools/libxl/libxl_arm.c
>> > @@ -77,6 +77,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>> > return ERROR_FAIL;
>> > }
>> >
>> > +xc_config->acpi = libxl_defbool_val(d_config->b_info.arch_arm.acpi)
>> > + ? true : false;
>> > +
>> > return 0;
>> > }
>> >
>> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>> > index ef614be..426b868 100644
>> > --- a/tools/libxl/libxl_types.idl
>> > +++ b/tools/libxl/libxl_types.idl
>> > @@ -560,6 +560,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>> >
>> >
>> > ("arch_arm", Struct(None, [("gic_version", libxl_gic_version),
>> > + ("acpi", libxl_defbool),
>> >])),
>> >
>> > ], dir=DIR_IN
>> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>> > index 6459eec..0634ffa 100644
>> > --- a/tools/libxl/xl_cmdimpl.c
>> > +++ b/tools/libxl/xl_cmdimpl.c
>> > @@ -2506,6 +2506,10 @@ skip_usbdev:
>> > }
>> > }
>> >
>> > +if (xlu_cfg_get_defbool(config, "acpi", &b_info->arch_arm.acpi, 0)) {
>> > +libxl_defbool_set(&b_info->arch_arm.acpi, 0);
>> > +}
> We cannot share the existing code to parse the acpi paramter because
> that is saved in b_info->u.hvm.acpi, right?
Yes.
> It's a pity. I wonder if we
> could refactor the existing code so that we can actually share the acpi
> parameter between x86 and arm.
>
I have no idea about this since I'm not familiar with this. But is there
any downsides of current way? Because for x86, it will use
b_info->u.hvm.acpi and for ARM it will use b_info->arch_arm.acpi. I
think they don't conflict even though we store it at two places.
Or could we add some codes to check the arch and decide where to store it?
Thanks,
--
Shannon
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 02/14] libxc: Prepare a start info structure for hvmloader
On 06/22/2016 01:15 PM, Anthony PERARD wrote:
> ... and load BIOS/UEFI firmware into guest memory.
>
> This adds a new firmware module, system_firmware_module. It is loaded in
> the guest memory and final location is provided to hvmloader via the
> hvm_start_info struct.
>
> This patch create the hvm_start_info struct for HVM guest that have a
> device model, so this is now common code with HVM guest without device
> model.
>
> Signed-off-by: Anthony PERARD
> ---
> CC: boris.ostrov...@oracle.com
> CC: roger@citrix.com
>
> Changes in V5:
> - in alloc_magic_pages_hvm, check dom->device_model only once instead of
> twice (fold second if into previous else)
> - rework add_module_to_list to make it easier to read
> - also comment about the intended memory layout of start_info and the
> modules
> - in bootlate_hvm(), drop start_page and use start_info as they point to
> the same address
> - rename xc_dom_image.bios_module to xc_dom_image.system_firmware_module
> - rename module name to "firmware" (was "bios")
>
> Changes in V4:
> - change title to suggest the change of beavior
> - remove code to load acpi tables (dsdt)
> - Update public/xen.h about hvm_start_info available on other HVM guest
> in %ebx.
>
> Changes in V3:
> - rename acpi_table_module to full_acpi_module.
> - factorise module loading, using new function to load existing optinal
> module, this should not change anything
> - should now use the same code to loads modules as for HVMlite VMs.
> this avoid duplication of code.
> - no more generic cmdline with a list of modules, each module have its name
> in the module specific cmdline.
> - scope change for common code between hvmlite and hvmloader
> ---
> tools/libxc/include/xc_dom.h | 3 +
> tools/libxc/xc_dom_hvmloader.c | 3 +
> tools/libxc/xc_dom_x86.c | 152
> +
> xen/include/public/xen.h | 2 +-
> 4 files changed, 116 insertions(+), 44 deletions(-)
>
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index 6cb10c4..0629971 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -209,6 +209,9 @@ struct xc_dom_image {
> /* If unset disables the setup of the IOREQ pages. */
> bool device_model;
>
> +/* BIOS/Firmware passed to HVMLOADER */
> +struct xc_hvm_firmware_module system_firmware_module;
> +
> /* Extra ACPI tables passed to HVMLOADER */
> struct xc_hvm_firmware_module acpi_module;
>
> diff --git a/tools/libxc/xc_dom_hvmloader.c b/tools/libxc/xc_dom_hvmloader.c
> index da8b995..cf2d57c 100644
> --- a/tools/libxc/xc_dom_hvmloader.c
> +++ b/tools/libxc/xc_dom_hvmloader.c
> @@ -167,6 +167,9 @@ static int modules_init(struct xc_dom_image *dom)
> {
> int rc;
>
> +rc = module_init_one(dom, &dom->system_firmware_module,
> + "System Firmware module");
> +if ( rc ) goto err;
> rc = module_init_one(dom, &dom->acpi_module, "ACPI module");
> if ( rc ) goto err;
> rc = module_init_one(dom, &dom->smbios_module, "SMBIOS module");
> diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
> index 021f8a8..f017fbd 100644
> --- a/tools/libxc/xc_dom_x86.c
> +++ b/tools/libxc/xc_dom_x86.c
> @@ -69,6 +69,9 @@
> #define round_up(addr, mask) ((addr) | (mask))
> #define round_pg_up(addr) (((addr) + PAGE_SIZE_X86 - 1) & ~(PAGE_SIZE_X86 -
> 1))
>
> +#define HVMLOADER_MODULE_MAX_COUNT 1
> +#define HVMLOADER_MODULE_NAME_SIZE 10
> +
> struct xc_dom_params {
> unsigned levels;
> xen_vaddr_t vaddr_mask;
> @@ -590,6 +593,7 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
> xen_pfn_t special_array[X86_HVM_NR_SPECIAL_PAGES];
> xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
> xc_interface *xch = dom->xch;
> +size_t start_info_size = sizeof(struct hvm_start_info);
>
> /* Allocate and clear special pages. */
> for ( i = 0; i < X86_HVM_NR_SPECIAL_PAGES; i++ )
> @@ -624,8 +628,6 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
>
> if ( !dom->device_model )
> {
> -size_t start_info_size = sizeof(struct hvm_start_info);
> -
> if ( dom->cmdline )
> {
> dom->cmdline_size = ROUNDUP(strlen(dom->cmdline) + 1, 8);
> @@ -635,17 +637,18 @@ static int alloc_magic_pages_hvm(struct xc_dom_image
> *dom)
> /* Limited to one module. */
> if ( dom->ramdisk_blob )
> start_info_size += sizeof(struct hvm_modlist_entry);
> -
> -rc = xc_dom_alloc_segment(dom, &dom->start_info_seg,
> - "HVMlite start info", 0, start_info_size);
> -if ( rc != 0 )
> -{
> -DOMPRINTF("Unable to reserve memory for the start info");
> -goto out;
> -}
> }
> else
> {
> +start_info_size +=
> +sizeof(struct hvm_modlist_entry) * HVMLOADER_MODULE_MAX_COUNT;
> +/
Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"
>>> On 23.06.16 at 15:25, wrote:
> On Thu, Jun 23, 2016 at 03:46:46AM -0600, Jan Beulich wrote:
>> >>> On 23.06.16 at 11:23, wrote:
>> > On Thu, Jun 23, 2016 at 11:18:24AM +0200, Marek Marczykowski-Górecki wrote:
>> >> On Thu, Jun 23, 2016 at 03:12:47AM -0600, Jan Beulich wrote:
>> >> > >>> On 23.06.16 at 10:57, wrote:
>> >> > > On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote:
>> >> > >> I wonder what good the duplication of the returned domain ID does:
>> >> > >> I'm
>> >> > >> tempted to remove the one in the command-specific structure. Does
>> >> > >> anyone have insight into why it was done that way?
>> >> > >
>> >> > > Isn't XEN_DOMCTL_getdomaininfo supposed to return info about first
>> >> > > existing domain with ID >= passed one? Reading various comments in
>> >> > > code
>> >> > > it looks to be used to domain enumeration. This patch changes this
>> >> > > behaviour.
>> >> >
>> >> > No, it doesn't. It adjusts the behavior only for the DM case (which
>> >> > isn't supposed to get information on other than the target domain,
>> >> > i.e. in this one specific case the very domain ID needs to be passed
>> >> > in).
>> >>
>> >> int xc_domain_getinfo(xc_interface *xch,
>> >> uint32_t first_domid,
>> >> unsigned int max_doms,
>> >> xc_dominfo_t *info)
>> >> {
>> >> unsigned int nr_doms;
>> >> uint32_t next_domid = first_domid;
>> >> DECLARE_DOMCTL;
>> >> int rc = 0;
>> >>
>> >> memset(info, 0, max_doms*sizeof(xc_dominfo_t));
>> >>
>> >> for ( nr_doms = 0; nr_doms < max_doms; nr_doms++ )
>> >> {
>> >> domctl.cmd = XEN_DOMCTL_getdomaininfo;
>> >> domctl.domain = (domid_t)next_domid;
>> >> if ( (rc = do_domctl(xch, &domctl)) < 0 )
>> >> break;
>> >> info->domid = (uint16_t)domctl.domain;
>> >> (...)
>> >> next_domid = (uint16_t)domctl.domain + 1;
>> >>
>> >>
>> >> Looks like heavily dependent on XEN_DOMCTL_getdomaininfo returning next
>> > valid
>> >> domain.
>> >
>> > Hmm, looks like I've misread you patch. Reading again...
>> >
>> > But now I see rcu_read_lock(&domlist_read_lock) is gets called only when
>> > looping over domains, but rcu_read_unlock is called in any case. Is it
>> > correct?
>>
>> How that? There is this third hunk:
>
> Ok, after drawing a flowchart of the control in this function after your
> change, on a piece of paper, this case looks fine. But depending on how
> the domain was found (explicit loop or rcu_lock_domain_by_id), different
> locks are held, which makes it harder to follow what is going on.
>
> Crazy idea: how about making the code easy/easier to read instead of
> obfuscating it even more? XEN_DOMCTL_getdomaininfo semantic is
> convolved enough. How about this version (2 patches):
>
> xen: move domain lookup for getdomaininfo to the same
I don't mind this one.
> xen: allow XEN_DOMCTL_getdomaininfo for device model
But I don't really like this, and would prefer my solution here; it's
Daniel's call though.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table
On Thu, 23 Jun 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> It uses static DSDT table like the way x86 uses. Currently the DSDT
> table only contains processor device objects and it generates the
> maximal objects which so far is 128.
>
> Signed-off-by: Shannon Zhao
> ---
> tools/libxl/Makefile | 24 -
> tools/libxl/libxl_arm_acpi.c | 15 ++
> tools/libxl/libxl_arm_acpi.h | 2 +
> tools/libxl/libxl_empty_dsdt_arm.asl | 22 +
> tools/libxl/libxl_mk_dsdt_arm.c | 94
>
> 5 files changed, 156 insertions(+), 1 deletion(-)
> create mode 100644 tools/libxl/libxl_empty_dsdt_arm.asl
> create mode 100644 tools/libxl/libxl_mk_dsdt_arm.c
>
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 264b6ef..5347480 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -77,7 +77,29 @@ endif
>
> LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
> LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
> -LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o
> +LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o libxl_dsdt_anycpu_arm.o
> +
> +vpath iasl $(PATH)
> +libxl_mk_dsdt_arm: libxl_mk_dsdt_arm.c
> + $(CC) $(CFLAGS) -o $@ libxl_mk_dsdt_arm.c
> +
> +libxl_dsdt_anycpu_arm.asl: libxl_empty_dsdt_arm.asl libxl_mk_dsdt_arm
> + awk 'NR > 1 {print s} {s=$$0}' $< > $@
> + ./libxl_mk_dsdt_arm >> $@
> +
> +libxl_dsdt_anycpu_arm.c: %.c: iasl %.asl
> + iasl -vs -p $* -tc $*.asl
> + sed -e 's/AmlCode/$*/g' $*.hex >$@
> + echo "int $*_len=sizeof($*);" >>$@
> + rm -f $*.aml $*.hex
> +
> +iasl:
> + @echo
> + @echo "ACPI ASL compiler (iasl) is needed"
> + @echo "Download and install Intel ACPI CA from"
> + @echo "http://acpica.org/downloads/";
> + @echo
> + @exit 1
>
> libxl_arm_acpi.o: libxl_arm_acpi.c
> $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> index 353d774..45fc354 100644
> --- a/tools/libxl/libxl_arm_acpi.c
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -54,6 +54,9 @@ enum {
> NUMS,
> };
>
> +extern unsigned char libxl_dsdt_anycpu_arm[];
> +extern int libxl_dsdt_anycpu_arm_len;
> +
> struct acpitable {
> void *table;
> size_t size;
> @@ -256,6 +259,17 @@ static void make_acpi_fadt(libxl__gc *gc, struct
> xc_dom_image *dom)
> dom->acpitable_size += ROUNDUP(acpitables[FADT].size, 3);
> }
>
> +static void make_acpi_dsdt(libxl__gc *gc, struct xc_dom_image *dom)
> +{
> +acpitables[DSDT].table = libxl__zalloc(gc, libxl_dsdt_anycpu_arm_len);
> +memcpy(acpitables[DSDT].table, libxl_dsdt_anycpu_arm,
> + libxl_dsdt_anycpu_arm_len);
> +
> +acpitables[DSDT].size = libxl_dsdt_anycpu_arm_len;
> +/* Align to 64bit. */
> +dom->acpitable_size += ROUNDUP(acpitables[DSDT].size, 3);
> +}
> +
> int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
> libxl__domain_build_state *state,
> struct xc_dom_image *dom)
> @@ -284,6 +298,7 @@ int libxl__prepare_acpi(libxl__gc *gc,
> libxl_domain_build_info *info,
> return rc;
>
> make_acpi_fadt(gc, dom);
> +make_acpi_dsdt(gc, dom);
>
> return 0;
> }
> diff --git a/tools/libxl/libxl_arm_acpi.h b/tools/libxl/libxl_arm_acpi.h
> index 9b58de6..b0fd9ce 100644
> --- a/tools/libxl/libxl_arm_acpi.h
> +++ b/tools/libxl/libxl_arm_acpi.h
> @@ -19,6 +19,8 @@
>
> #include
>
> +#define DOMU_MAX_VCPUS 128
> +
> int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
> libxl__domain_build_state *state,
> struct xc_dom_image *dom);
> diff --git a/tools/libxl/libxl_empty_dsdt_arm.asl
> b/tools/libxl/libxl_empty_dsdt_arm.asl
> new file mode 100644
> index 000..005fa6a
> --- /dev/null
> +++ b/tools/libxl/libxl_empty_dsdt_arm.asl
> @@ -0,0 +1,22 @@
> +/**
> + * DSDT for Xen ARM DomU
> + *
> + * Copyright (c) 2004, Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> with
> + * this program; If not, see
Re: [Xen-devel] [PATCH 01/11] public / x86: introduce hvmctl hypercall
On 20/06/16 13:52, Jan Beulich wrote: > +/* > + * Note that this value is effectively part of the ABI, even if we don't need > + * to make it a formal part of it. Hence this value may only be changed if > + * accompanied by a suitable interface version increase. > + */ > +#define HVMCTL_iter_shift 8 > +#define HVMCTL_iter_mask ((1U << HVMCTL_iter_shift) - 1) > +#define HVMCTL_iter_max (1U << (16 + HVMCTL_iter_shift)) This (mis)use of the cmd parameter is surely no longer necessary, given that there is space in xen_hvmctl_t to encode continuation information? ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Change of max-ram-below-4g initial value breaks Xen
Hi,
> How could xen_ram_init() find out if the value of max-ram-below-4g is
> the default or if a user have set it? Is there another way we could fix
> this?
Attached patch should fix it. Patch survived a quick smoke test on kvm
so far, need to do some more testing tomorrow. Can you give it a spin
on xen?
thanks,
Gerd
From d45a95861def18a02e1c26d3717693432517107a Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann
Date: Thu, 23 Jun 2016 16:49:03 +0200
Subject: [PATCH] xen: fix ram init regression
Commit "8156d48 pc: allow raising low memory via max-ram-below-4g
option" causes a regression on xen, because it uses a different
memory split.
This patch initializes max-ram-below-4g to zero and leaves the
initialization to the memory initialization functions. That way
they can pick different default values (max-ram-below-4g is zero
still) or use the user supplied value (max-ram-below-4g is non-zero).
Signed-off-by: Gerd Hoffmann
---
hw/i386/pc.c | 2 +-
hw/i386/pc_piix.c | 3 +++
hw/i386/pc_q35.c | 3 +++
xen-hvm.c | 3 +++
4 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 7198ed5..66e1dae 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1886,7 +1886,7 @@ static void pc_machine_initfn(Object *obj)
pc_machine_get_hotplug_memory_region_size,
NULL, NULL, NULL, &error_abort);
-pcms->max_ram_below_4g = 0xe000; /* 3.5G */
+pcms->max_ram_below_4g = 0; /* use default */
object_property_add(obj, PC_MACHINE_MAX_RAM_BELOW_4G, "size",
pc_machine_get_max_ram_below_4g,
pc_machine_set_max_ram_below_4g,
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 53bc968..78e3d44 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -114,6 +114,9 @@ static void pc_init1(MachineState *machine,
*qemu -M pc,max-ram-below-4g=2G -m 4G -> 2048M low, 2048M high
*qemu -M pc,max-ram-below-4g=4G -m 3968M -> 3968M low (=4G-128M)
*/
+if (!pcms->max_ram_below_4g) {
+pcms->max_ram_below_4g = 0xe000; /* default: 3.5G */
+}
lowmem = pcms->max_ram_below_4g;
if (machine->ram_size >= pcms->max_ram_below_4g) {
if (pcmc->gigabyte_align) {
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index e4b541f..1b653e2 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -93,6 +93,9 @@ static void pc_q35_init(MachineState *machine)
/* Handle the machine opt max-ram-below-4g. It is basically doing
* min(qemu limit, user limit).
*/
+if (!pcms->max_ram_below_4g) {
+pcms->max_ram_below_4g = 1ULL << 32; /* default: 4G */;
+}
if (lowmem > pcms->max_ram_below_4g) {
lowmem = pcms->max_ram_below_4g;
if (machine->ram_size - lowmem > lowmem &&
diff --git a/xen-hvm.c b/xen-hvm.c
index 98ea44f..eb57792 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -190,6 +190,9 @@ static void xen_ram_init(PCMachineState *pcms,
/* Handle the machine opt max-ram-below-4g. It is basically doing
* min(xen limit, user limit).
*/
+if (!user_lowmem) {
+user_lowmem = HVM_BELOW_4G_RAM_END; /* default */
+}
if (HVM_BELOW_4G_RAM_END <= user_lowmem) {
user_lowmem = HVM_BELOW_4G_RAM_END;
}
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 6/8] xen: Use the typesafe mfn and gfn in map_mmio_regions...
On 23/06/16 15:15, Stefano Stabellini wrote:
On Thu, 23 Jun 2016, Julien Grall wrote:
On 23/06/16 15:05, Stefano Stabellini wrote:
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index aa4e774..47cb383 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1245,27 +1245,27 @@ int unmap_regions_rw_cache(struct domain *d,
}
int map_mmio_regions(struct domain *d,
- unsigned long start_gfn,
+ gfn_t start_gfn,
unsigned long nr,
- unsigned long mfn)
+ mfn_t mfn)
{
return apply_p2m_changes(d, INSERT,
- pfn_to_paddr(start_gfn),
- pfn_to_paddr(start_gfn + nr),
- pfn_to_paddr(mfn),
+ pfn_to_paddr(gfn_x(start_gfn)),
+ pfn_to_paddr(gfn_x(start_gfn) + nr),
+ pfn_to_paddr(mfn_x(mfn)),
MATTR_DEV, 0, p2m_mmio_direct,
d->arch.p2m.default_access);
Any reason why you didn't push these changes down to apply_p2m_changes too?
To keep this series simple. I have another series coming up to push the change
down to apply_p2m_changes and clean up the P2M code.
I can move the patch to push down the change in this series if you prefer.
Yeah, it makes sense to keep them together.
Well, I still plan to have a different patch to push down the change.
Switching from unsigned long to gfn/mfn is a long work which need to be
split to ease the review.
I will see what I can do.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"
On Thu, Jun 23, 2016 at 03:12:04PM +0100, Andrew Cooper wrote:
> On 23/06/16 14:25, Marek Marczykowski-Górecki wrote:
> > On Thu, Jun 23, 2016 at 03:46:46AM -0600, Jan Beulich wrote:
> > On 23.06.16 at 11:23, wrote:
> >>> On Thu, Jun 23, 2016 at 11:18:24AM +0200, Marek Marczykowski-Górecki
> >>> wrote:
> On Thu, Jun 23, 2016 at 03:12:47AM -0600, Jan Beulich wrote:
> On 23.06.16 at 10:57, wrote:
> >> On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote:
> >>> I wonder what good the duplication of the returned domain ID does: I'm
> >>> tempted to remove the one in the command-specific structure. Does
> >>> anyone have insight into why it was done that way?
> >> Isn't XEN_DOMCTL_getdomaininfo supposed to return info about first
> >> existing domain with ID >= passed one? Reading various comments in code
> >> it looks to be used to domain enumeration. This patch changes this
> >> behaviour.
> > No, it doesn't. It adjusts the behavior only for the DM case (which
> > isn't supposed to get information on other than the target domain,
> > i.e. in this one specific case the very domain ID needs to be passed
> > in).
> int xc_domain_getinfo(xc_interface *xch,
> uint32_t first_domid,
> unsigned int max_doms,
> xc_dominfo_t *info)
> {
> unsigned int nr_doms;
> uint32_t next_domid = first_domid;
> DECLARE_DOMCTL;
> int rc = 0;
>
> memset(info, 0, max_doms*sizeof(xc_dominfo_t));
>
> for ( nr_doms = 0; nr_doms < max_doms; nr_doms++ )
> {
> domctl.cmd = XEN_DOMCTL_getdomaininfo;
> domctl.domain = (domid_t)next_domid;
> if ( (rc = do_domctl(xch, &domctl)) < 0 )
> break;
> info->domid = (uint16_t)domctl.domain;
> (...)
> next_domid = (uint16_t)domctl.domain + 1;
>
>
> Looks like heavily dependent on XEN_DOMCTL_getdomaininfo returning next
> >>> valid
> domain.
> >>> Hmm, looks like I've misread you patch. Reading again...
> >>>
> >>> But now I see rcu_read_lock(&domlist_read_lock) is gets called only when
> >>> looping over domains, but rcu_read_unlock is called in any case. Is it
> >>> correct?
> >> How that? There is this third hunk:
> > Ok, after drawing a flowchart of the control in this function after your
> > change, on a piece of paper, this case looks fine. But depending on how
> > the domain was found (explicit loop or rcu_lock_domain_by_id), different
> > locks are held, which makes it harder to follow what is going on.
> >
> > Crazy idea: how about making the code easy/easier to read instead of
> > obfuscating it even more? XEN_DOMCTL_getdomaininfo semantic is
> > convolved enough. How about this version (2 patches):
> >
> > xen: move domain lookup for getdomaininfo to the same
> >
> > XEN_DOMCTL_getdomaininfo have different semantics than most of others
> > domctls - it returns information about first valid domain with ID >=
> > argument. But that's no excuse for having the lookup done in a different
> > place, which made handling different corner cases unnecessary complex.
> > Move the lookup to the first switch clause. And adjust locking to be the
> > same as for other cases.
> >
> > Signed-off-by: Marek Marczykowski-Górecki
>
> FWIW, I prefer this solution to the issue.
>
> Reviewed-by: Andrew Cooper , with a few style
> nits.
Fixed patch according to your comments:
xen: move domain lookup for getdomaininfo to the same
XEN_DOMCTL_getdomaininfo have different semantics than most of others
domctls - it returns information about first valid domain with ID >=
argument. But that's no excuse for having the lookup code in a different
place, which made handling different corner cases unnecessary complex.
Move the lookup to the first switch clause. And adjust locking to be the
same as for other cases.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/common/domctl.c | 44 +++-
1 file changed, 23 insertions(+), 21 deletions(-)
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index e43904e..41de3e8 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -442,11 +442,32 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
u_domctl)
switch ( op->cmd )
{
case XEN_DOMCTL_createdomain:
-case XEN_DOMCTL_getdomaininfo:
case XEN_DOMCTL_test_assign_device:
case XEN_DOMCTL_gdbsx_guestmemio:
d = NULL;
break;
+
+case XEN_DOMCTL_getdomaininfo:
+d = rcu_lock_domain_by_id(op->domain);
+
+if ( d == NULL )
+{
+/* Search for the next available domain. */
+rcu_read_lock(&domlist_read_lock);
+
+for_each_domain ( d )
+if ( d->domain_id >= op->domain )
+{
+rcu_lock_dom
Re: [Xen-devel] [PATCH v2 07/17] libxl/arm: Construct ACPI GTDT table
On Thu, 23 Jun 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Construct GTDT table with the interrupt information of timers.
>
> Signed-off-by: Shannon Zhao
> ---
> tools/libxl/libxl_arm_acpi.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> index d5ffedf..de863f4 100644
> --- a/tools/libxl/libxl_arm_acpi.c
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -39,6 +39,9 @@ typedef uint64_t u64;
> #define ACPI_BUILD_APPNAME6 "XenARM"
> #define ACPI_BUILD_APPNAME4 "Xen "
>
> +#define ACPI_LEVEL_SENSITIVE(u8) 0x00
> +#define ACPI_ACTIVE_LOW (u8) 0x01
> +
> enum {
> RSDP,
> XSDT,
> @@ -110,6 +113,30 @@ static void make_acpi_xsdt(libxl__gc *gc, struct
> xc_dom_image *dom)
> dom->acpitable_size += ROUNDUP(acpitables[XSDT].size, 3);
> }
>
> +static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
> +{
> +struct acpi_table_gtdt *gtdt;
> +size_t size = sizeof(*gtdt);
> +
> +gtdt = libxl__zalloc(gc, size);
> +
> +gtdt->non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
> +gtdt->non_secure_el1_flags =
> + (ACPI_LEVEL_SENSITIVE <<
> ACPI_GTDT_INTERRUPT_MODE)
> + |(ACPI_ACTIVE_LOW <<
> ACPI_GTDT_INTERRUPT_POLARITY);
> +gtdt->virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
> +gtdt->virtual_timer_flags =
> + (ACPI_LEVEL_SENSITIVE <<
> ACPI_GTDT_INTERRUPT_MODE)
> + |(ACPI_ACTIVE_LOW <<
> ACPI_GTDT_INTERRUPT_POLARITY);
> +
> +make_acpi_header(>dt->header, "GTDT", size, 2);
> +
> +acpitables[GTDT].table = gtdt;
> +acpitables[GTDT].size = size;
> +/* Align to 64bit. */
> +dom->acpitable_size += ROUNDUP(acpitables[GTDT].size, 3);
> +}
Many of this tables look pretty much static. Any reason why we can't
define them and initialize them on an header somewhere like:
struct acpi_gtdt xen_acpi_gtdt {
.non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
.non_secure_el1_flags = (ACPI_LEVEL_SENSITIVE <<
ACPI_GTDT_INTERRUPT_MODE) | (ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
.virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
.virtual_timer_flags = (ACPI_LEVEL_SENSITIVE <<
ACPI_GTDT_INTERRUPT_MODE)|(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
};
it would make the code shorter and easier to read.
> int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
> libxl__domain_build_state *state,
> struct xc_dom_image *dom)
> @@ -132,6 +159,7 @@ int libxl__prepare_acpi(libxl__gc *gc,
> libxl_domain_build_info *info,
>
> make_acpi_rsdp(gc, dom);
> make_acpi_xsdt(gc, dom);
> +make_acpi_gtdt(gc, dom);
>
> return 0;
> }
> --
> 2.0.4
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"
On 06/23/2016 09:25 AM, Marek Marczykowski-Górecki wrote: [...] Ok, after drawing a flowchart of the control in this function after your change, on a piece of paper, this case looks fine. But depending on how the domain was found (explicit loop or rcu_lock_domain_by_id), different locks are held, which makes it harder to follow what is going on. Crazy idea: how about making the code easy/easier to read instead of obfuscating it even more? XEN_DOMCTL_getdomaininfo semantic is convolved enough. How about this version (2 patches): [...] xen: allow XEN_DOMCTL_getdomaininfo for device model Allow device model domain to get info about its target domain. It is used during PCI passthrough setup (xc_domain_memory_mapping checks for guest being auto-translated). While it happens in stubdomain, it failed, breaking PCI passthrough in such setup. While it is possible to workaround this at toolstack side, it seems logical to allow device model to get information about its target domain. The problem was exposed by c428c9f "tools/libxl: handle the iomem parameter with the memory_mapping hcall". Signed-off-by: Marek Marczykowski-Górecki --- xen/include/xsm/dummy.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h index 406cd18..70a1633 100644 --- a/xen/include/xsm/dummy.h +++ b/xen/include/xsm/dummy.h @@ -128,7 +128,10 @@ static XSM_INLINE int xsm_domctl(XSM_DEFAULT_ARG struct domain *d, int cmd) case XEN_DOMCTL_unbind_pt_irq: return xsm_default_action(XSM_DM_PRIV, current->domain, d); case XEN_DOMCTL_getdomaininfo: -return xsm_default_action(XSM_XS_PRIV, current->domain, d); +if (current->domain->target) +return xsm_default_action(XSM_DM_PRIV, current->domain, d); +else +return xsm_default_action(XSM_XS_PRIV, current->domain, d); default: return xsm_default_action(XSM_PRIV, current->domain, d); } I would prefer testing for the xenstore flag instead of testing for the target field. It ends up being the same thing in reality, since nobody sane would make the xenstore also a device model (and not also dom0). case XEN_DOMCTL_getdomaininfo: if ( src->is_xenstore ) return 0; return xsm_default_action(XSM_DM_PRIV, current->domain, d); This makes it clear that xenstore is the special case, and removes the need for the one-off XSM_XS_PRIV constant. -- Daniel De Graaf National Security Agency ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: domain_build: DT: add clocks node to the hypervisor node
On 22/06/16 16:58, Julien Grall wrote:
On 21/06/16 11:15, Dirk Behme wrote:
+printk("Failed to remember the clock node of %s\n", path);
+printk("Use the Linux kernel command
'clk_ignore_unused'\n");
+return 0;
I don't think this is tolerable. We need to fix it once and for all.
I understand that xen does not provide a realloc function. Is there
another way we can get a rid of this limit?
Note that I would wait that we agree on the device tree bindings before
reworking this patch. It will avoid you to waste time if we decide to
move towards a different solution.
I am wondering if we can use the member domain_list of dt_device_node to
link the device having a clock property. And then latter one, allocate
the memory + copying the data.
+}
+memcpy(&kinfo->clk.dtclocks[kinfo->clk.cnt], clocks, len);
+kinfo->clk.cnt += len;
return 0;
}
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"
On 23/06/16 15:59, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 23, 2016 at 03:12:04PM +0100, Andrew Cooper wrote:
>> On 23/06/16 14:25, Marek Marczykowski-Górecki wrote:
>>> On Thu, Jun 23, 2016 at 03:46:46AM -0600, Jan Beulich wrote:
>>> On 23.06.16 at 11:23, wrote:
> On Thu, Jun 23, 2016 at 11:18:24AM +0200, Marek Marczykowski-Górecki
> wrote:
>> On Thu, Jun 23, 2016 at 03:12:47AM -0600, Jan Beulich wrote:
>> On 23.06.16 at 10:57, wrote:
On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote:
> I wonder what good the duplication of the returned domain ID does: I'm
> tempted to remove the one in the command-specific structure. Does
> anyone have insight into why it was done that way?
Isn't XEN_DOMCTL_getdomaininfo supposed to return info about first
existing domain with ID >= passed one? Reading various comments in code
it looks to be used to domain enumeration. This patch changes this
behaviour.
>>> No, it doesn't. It adjusts the behavior only for the DM case (which
>>> isn't supposed to get information on other than the target domain,
>>> i.e. in this one specific case the very domain ID needs to be passed
>>> in).
>> int xc_domain_getinfo(xc_interface *xch,
>> uint32_t first_domid,
>> unsigned int max_doms,
>> xc_dominfo_t *info)
>> {
>> unsigned int nr_doms;
>> uint32_t next_domid = first_domid;
>> DECLARE_DOMCTL;
>> int rc = 0;
>>
>> memset(info, 0, max_doms*sizeof(xc_dominfo_t));
>>
>> for ( nr_doms = 0; nr_doms < max_doms; nr_doms++ )
>> {
>> domctl.cmd = XEN_DOMCTL_getdomaininfo;
>> domctl.domain = (domid_t)next_domid;
>> if ( (rc = do_domctl(xch, &domctl)) < 0 )
>> break;
>> info->domid = (uint16_t)domctl.domain;
>> (...)
>> next_domid = (uint16_t)domctl.domain + 1;
>>
>>
>> Looks like heavily dependent on XEN_DOMCTL_getdomaininfo returning next
> valid
>> domain.
> Hmm, looks like I've misread you patch. Reading again...
>
> But now I see rcu_read_lock(&domlist_read_lock) is gets called only when
> looping over domains, but rcu_read_unlock is called in any case. Is it
> correct?
How that? There is this third hunk:
>>> Ok, after drawing a flowchart of the control in this function after your
>>> change, on a piece of paper, this case looks fine. But depending on how
>>> the domain was found (explicit loop or rcu_lock_domain_by_id), different
>>> locks are held, which makes it harder to follow what is going on.
>>>
>>> Crazy idea: how about making the code easy/easier to read instead of
>>> obfuscating it even more? XEN_DOMCTL_getdomaininfo semantic is
>>> convolved enough. How about this version (2 patches):
>>>
>>> xen: move domain lookup for getdomaininfo to the same
>>>
>>> XEN_DOMCTL_getdomaininfo have different semantics than most of others
>>> domctls - it returns information about first valid domain with ID >=
>>> argument. But that's no excuse for having the lookup done in a different
>>> place, which made handling different corner cases unnecessary complex.
>>> Move the lookup to the first switch clause. And adjust locking to be the
>>> same as for other cases.
>>>
>>> Signed-off-by: Marek Marczykowski-Górecki
>> FWIW, I prefer this solution to the issue.
>>
>> Reviewed-by: Andrew Cooper , with a few style
>> nits.
> Fixed patch according to your comments:
>
> xen: move domain lookup for getdomaininfo to the same
>
> XEN_DOMCTL_getdomaininfo have different semantics than most of others
> domctls - it returns information about first valid domain with ID >=
> argument. But that's no excuse for having the lookup code in a different
> place, which made handling different corner cases unnecessary complex.
> Move the lookup to the first switch clause. And adjust locking to be the
> same as for other cases.
>
> Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Andrew Cooper
> ---
> xen/common/domctl.c | 44 +++-
> 1 file changed, 23 insertions(+), 21 deletions(-)
>
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index e43904e..41de3e8 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -442,11 +442,32 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
> u_domctl)
> switch ( op->cmd )
> {
> case XEN_DOMCTL_createdomain:
> -case XEN_DOMCTL_getdomaininfo:
> case XEN_DOMCTL_test_assign_device:
> case XEN_DOMCTL_gdbsx_guestmemio:
> d = NULL;
> break;
> +
> +case XEN_DOMCTL_getdomaininfo:
> +d = rcu_lock_domain_by_id(op->domain);
> +
> +if ( d == NULL )
> +{
> +/* Search for the next available domain. */
> +rcu_read_lock(&dom
