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

From: "Jan Beulich" <JBeulich@suse.com>
To: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Cc: dgdegra@tycho.nsa.gov, xen-devel <xen-devel@lists.xen.org>
Subject: Re: PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"
Date: Wed, 22 Jun 2016 09:23:13 -0600	[thread overview]
Message-ID: <576AC98102000078000F7BDE@prv-mh.provo.novell.com> (raw)
In-Reply-To: <20160622141314.GD1593@mail-itl>

>>> On 22.06.16 at 16:13, <marmarek@invisiblethingslab.com> wrote:
> On Wed, Jun 22, 2016 at 07:50:09AM -0600, Jan Beulich wrote:
>> >>> On 22.06.16 at 15:03, <marmarek@invisiblethingslab.com> 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

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