[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"


  • To: Jan Beulich <JBeulich@xxxxxxxx>, Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
  • From: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
  • Date: Wed, 22 Jun 2016 14:24:37 -0400
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Wed, 22 Jun 2016 18:25:02 +0000
  • Ironport-phdr: 9a23:VkfitRR4e9M4TW0xlWylZJCS/Npsv+yvbD5Q0YIujvd0So/mwa65YRaN2/xhgRfzUJnB7Loc0qyN4vimATBLus7JmUtBWaIPfidNsd8RkQ0kDZzNImzAB9muURYHGt9fXkRu5XCxPBsdMs//Y1rPvi/6tmZKSV3BPAZ4bt74BpTVx5zukbvjo9uLP04T3HKUWvBbElaflU3prM4YgI9veO4a6yDihT92QdlQ3n5iPlmJnhzxtY+a9Z9n9DlM6bp6r5YTGY2zRakzTKRZATI6KCh1oZSz7ViQcBGLrkc4fi1W10MQQluN0BavfJ73+gH3q+580ynSae/cQK0wWD+ix7x2UxKugyACYXpx1WjNh89HqatBqwCwpBtg2I3VJa4OLvd1faKVKdYTX29IRMtSfy1HHIKnboELAvYBPOBXtI30rR0Fqh7oVie2A+a65jZOh3LylYE3m8s7GAjIlFgsEN4Dv27dhMnkP6cVF+auxe/HyiuVPKAe4iv09IWdKkNpmvqLR78lNJOIkUQ=
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

On 06/22/2016 11:23 AM, Jan Beulich wrote:
On 22.06.16 at 16:13, <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
On Wed, Jun 22, 2016 at 07:50:09AM -0600, Jan Beulich wrote:
On 22.06.16 at 15:03, <marmarek@xxxxxxxxxxxxxxxxxxxxxx> 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)?

Daniel?

Jan

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.

--
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.