WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [RFC PATCH linux-2.6.18-xen] pciback: clean up (MSI-X ve

To: Andrew Jones <drjones@xxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC PATCH linux-2.6.18-xen] pciback: clean up (MSI-X vec, entrynr) list when resetting PCI device
From: Paolo Bonzini <pbonzini@xxxxxxxxxx>
Date: Wed, 01 Jun 2011 18:27:17 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Laszlo Ersek <lersek@xxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Wed, 01 Jun 2011 10:31:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1818654223.418514.1306945550994.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1818654223.418514.1306945550994.JavaMail.root@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.10
On 06/01/2011 06:25 PM, Andrew Jones wrote:
>  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).

I think you're in violent agreement here.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>