[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"



>>> 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.
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.

Jan


_______________________________________________
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®.