xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Jan Beulich <JBeulich@suse.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 16:13:14 +0200	[thread overview]
Message-ID: <20160622141314.GD1593@mail-itl> (raw)
In-Reply-To: <576AB3B102000078000F7B53@prv-mh.provo.novell.com>


[-- Attachment #1.1: Type: text/plain, Size: 2545 bytes --]

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?

> 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?  How to combine those
types? Change XSM_XS_PRIV to XSM_XS_DM_PRIV (it looks like the only
usage of XSM_XS_PRIV)?

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

  reply	other threads:[~2016-06-22 14:13 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-22 13:03 PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall" Marek Marczykowski-Górecki
2016-06-22 13:50 ` Jan Beulich
2016-06-22 14:13   ` Marek Marczykowski-Górecki [this message]
2016-06-22 15:23     ` Jan Beulich
2016-06-22 18:24       ` Daniel De Graaf
2016-06-23  8:32         ` Jan Beulich
2016-06-23  8:39           ` Jan Beulich
2016-06-23 14:33             ` Daniel De Graaf
2016-06-23  8:57           ` Marek Marczykowski-Górecki
2016-06-23  9:12             ` Jan Beulich
2016-06-23  9:18               ` Marek Marczykowski-Górecki
2016-06-23  9:23                 ` Marek Marczykowski-Górecki
2016-06-23  9:46                   ` Jan Beulich
2016-06-23 13:25                     ` Marek Marczykowski-Górecki
2016-06-23 14:12                       ` Andrew Cooper
2016-06-23 14:59                         ` Marek Marczykowski-Górecki
2016-06-23 15:01                           ` Andrew Cooper
2016-06-23 14:45                       ` Jan Beulich
2016-06-23 15:00                       ` Daniel De Graaf
2016-06-23 15:22                         ` Marek Marczykowski-Górecki
2016-06-23 15:30                           ` Daniel De Graaf
2016-06-23 15:37                           ` Jan Beulich
2016-06-23 15:45                             ` Marek Marczykowski-Górecki
2016-06-23 15:49                               ` Marek Marczykowski-Górecki
2016-06-23 16:02                               ` Jan Beulich
2016-06-23  9:45                 ` Jan Beulich
2016-06-23  9:44           ` Andrew Cooper
2016-06-23  9:50             ` Jan Beulich
2016-06-23 14:15               ` Andrew Cooper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160622141314.GD1593@mail-itl \
    --to=marmarek@invisiblethingslab.com \
    --cc=JBeulich@suse.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).