From: Andrew Jones <drjones@redhat.com>
To: Jan Beulich <JBeulich@novell.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
xen-devel@lists.xensource.com, Laszlo Ersek <lersek@redhat.com>
Subject: Re: [RFC PATCH linux-2.6.18-xen] pciback: clean up (MSI-X vec, entrynr) list when resetting PCI device
Date: Wed, 1 Jun 2011 12:25:50 -0400 (EDT) [thread overview]
Message-ID: <1818654223.418514.1306945550994.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> (raw)
In-Reply-To: <4DE67FE80200007800044F43@vpn.id2.novell.com>
----- Original Message -----
> >>> On 01.06.11 at 17:27, Laszlo Ersek <lersek@redhat.com> wrote:
> > Or, as you say above, the guest's generic MSI-X massaging PCI code
> > could
> > be modified.
>
> The host's.
>
> > We didn't want to leave this to the guest, however. It's not that I
> > intentionally try to postpone the cleanup until after the domain has
> > vanished; it's rather the domU can't be expected / trusted to do the
> > cleanup itself in all cases.
>
> When the guest is dead, the host has to take care. As long as the
> guest is alive, it ought to be responsible (and the host simply must
> not get in the way).
>
As Laszlo stated, we can leave the security concerns out since we're
talking about pci passthrough for pv guests. So malicious guests aside,
there's still the scenario where a proprietary, broken (but works on
bare-metal) driver comes along and messes things up. You then try to
either reboot and re-passthrough to that same guest or even to a
different guest that doesn't have a broken driver, but it now fails. Or,
IOW, the host should guarantee that no domu (even ones running
proprietary, broken code) can't ruin the day of another domu (or even
its own day on a subsequent boot).
Drew
next prev parent reply other threads:[~2011-06-01 16:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-01 10:05 [RFC PATCH linux-2.6.18-xen] pciback: clean up (MSI-X vec, entrynr) list when resetting PCI device Laszlo Ersek
2011-06-01 11:02 ` Laszlo Ersek
2011-06-01 14:31 ` Konrad Rzeszutek Wilk
2011-06-01 16:18 ` Paolo Bonzini
2011-06-01 17:32 ` Laszlo Ersek
2011-06-01 18:13 ` 2.6.38 (FC15) with PCI passthrough fails mysteriously with iommu=soft Konrad Rzeszutek Wilk
2011-06-02 7:42 ` Laszlo Ersek
2011-06-02 20:49 ` Pasi Kärkkäinen
2011-06-01 12:56 ` [RFC PATCH linux-2.6.18-xen] pciback: clean up (MSI-X vec, entrynr) list when resetting PCI device Jan Beulich
2011-06-01 14:12 ` Laszlo Ersek
2011-06-01 14:59 ` Jan Beulich
2011-06-01 15:27 ` Laszlo Ersek
2011-06-01 16:07 ` Jan Beulich
2011-06-01 16:25 ` Andrew Jones [this message]
2011-06-01 16:27 ` Paolo Bonzini
2011-06-01 16:16 ` Paolo Bonzini
2011-06-01 14:51 ` Konrad Rzeszutek Wilk
2011-06-01 15:01 ` Konrad Rzeszutek Wilk
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=1818654223.418514.1306945550994.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com \
--to=drjones@redhat.com \
--cc=JBeulich@novell.com \
--cc=lersek@redhat.com \
--cc=pbonzini@redhat.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 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).