From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: xen-devel <xen-devel@lists.xen.org>
Subject: PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"
Date: Wed, 22 Jun 2016 15:03:35 +0200 [thread overview]
Message-ID: <20160622130335.GA410@mail-itl> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 1111 bytes --]
Hi,
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=c428c9f162895cb3473fab26d23ffbf41a6f293d;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?
--
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
next reply other threads:[~2016-06-22 13:03 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-22 13:03 Marek Marczykowski-Górecki [this message]
2016-06-22 13:50 ` PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall" Jan Beulich
2016-06-22 14:13 ` Marek Marczykowski-Górecki
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=20160622130335.GA410@mail-itl \
--to=marmarek@invisiblethingslab.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.