From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Dan Gora <dan.gora@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: PCI BAR register space written with garbage in HVM guest.
Date: Tue, 16 Mar 2010 11:20:40 -0400 [thread overview]
Message-ID: <20100316152040.GA28821@phenom.dumpdata.com> (raw)
In-Reply-To: <4779de451003151955v15863656i5f39a631a8c558ee@mail.gmail.com>
> <aside>
> What is pcifront/pciback's role for HVM guests exactly? I understand
None functionaly. The purpose is to "bind" the PCI devices to pciback
(or pcistub) so that no other kernel module usurps it and starts
utilizing it.
> that you "hide" the devices from the dom0 with pciback and it
> definately loads and does *something* when the HVM guest comes up, but
> accesses from the domU don't appear to go through it at all (I
> understand that it works with qemu somehow, but that channel too is
> not at all clear how it works...)
With HVM pciback is not used. You need an virtualization aware IOMMU to
pass through PCI devices to the guest. PCIback/PCI front is for PV
guests and on machine where you don't neccessarily have this fancy
IOMMU.
> I've looked through qemu enough to kind of understand that it's
> responsible for abstracting the PCI configuration space for the domU,
> but I don't really understand how accesses get channeled through to it
> from the domU. Does it use hypercalls somehow? Can someone explain
The Hypervisor gets "trapped" when an outb is made (look for
emulate_privileged_op function and specifically out).
Then it somehow injects the fault in QEMU which does the rest. I don't
remember the details of how it does thought :-(
> how this whole flow is supposed to work for PCI configuration space
> accesses?
> </aside>
next prev parent reply other threads:[~2010-03-16 15:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-16 1:09 PCI BAR register space written with garbage in HVM guest Dan Gora
2010-03-16 1:48 ` Konrad Rzeszutek Wilk
2010-03-16 2:55 ` Dan Gora
2010-03-16 10:27 ` Jan Beulich
2010-03-16 15:20 ` Konrad Rzeszutek Wilk [this message]
2010-03-16 15:54 ` Jan Beulich
2010-03-16 10:24 ` Jan Beulich
2010-03-17 0:14 ` Dan Gora
2010-03-17 2:46 ` Konrad Rzeszutek Wilk
2010-03-17 3:31 ` Dan Gora
2010-03-18 2:14 ` Dan Gora
[not found] ` <20100318143207.GF14445@phenom.dumpdata.com>
2010-03-18 18:27 ` Dan Gora
2010-03-18 18:10 ` Konrad Rzeszutek Wilk
2010-03-18 19:56 ` Dan Gora
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=20100316152040.GA28821@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=dan.gora@gmail.com \
--cc=xen-devel@lists.xensource.com \
/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.