From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Jones 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) Message-ID: <1818654223.418514.1306945550994.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <4DE67FE80200007800044F43@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4DE67FE80200007800044F43@vpn.id2.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: Paolo Bonzini , xen-devel@lists.xensource.com, Laszlo Ersek List-Id: xen-devel@lists.xenproject.org ----- Original Message ----- > >>> On 01.06.11 at 17:27, Laszlo Ersek 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