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

[Xen-devel] Re: [Qemu-devel] [PATCH v3] xen: implement unplug protocol i

To: Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [Qemu-devel] [PATCH v3] xen: implement unplug protocol in xen_platform
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Fri, 15 Jul 2011 11:34:03 +0100
Cc: Kevin Wolf <kwolf@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "mst@xxxxxxxxxx" <mst@xxxxxxxxxx>, "armbru@xxxxxxxxxx" <armbru@xxxxxxxxxx>, "agraf@xxxxxxx" <agraf@xxxxxxx>, "qemu-devel@xxxxxxxxxx" <qemu-devel@xxxxxxxxxx>, Anthony Perard <anthony.perard@xxxxxxxxxx>
Delivery-date: Fri, 15 Jul 2011 03:31:04 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1107011829070.12963@kaball-desktop>
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: <1309260558-3332-1-git-send-email-stefano.stabellini@xxxxxxxxxxxxx> <4E0C681D.60001@xxxxxxxxxx> <alpine.DEB.2.00.1106301512280.12963@kaball-desktop> <4E0D7FB2.9010609@xxxxxxxxxx> <alpine.DEB.2.00.1107011829070.12963@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Fri, 1 Jul 2011, Stefano Stabellini wrote:
> On Fri, 1 Jul 2011, Kevin Wolf wrote:
> > Am 30.06.2011 16:16, schrieb Stefano Stabellini:
> > > On Thu, 30 Jun 2011, Kevin Wolf wrote:
> > >>> +static int pci_piix3_xen_ide_unplug(DeviceState *dev)
> > >>> +{
> > >>> +    PCIDevice *pci_dev;
> > >>> +    PCIIDEState *pci_ide;
> > >>> +    DriveInfo *di;
> > >>> +    int i = 0;
> > >>> +
> > >>> +    pci_dev = DO_UPCAST(PCIDevice, qdev, dev);
> > >>> +    pci_ide = DO_UPCAST(PCIIDEState, dev, pci_dev);
> > >>> +
> > >>> +    for (; i < 3; i++) {
> > >>> +        di = drive_get_by_index(IF_IDE, i);
> > >>> +        if (di != NULL && di->bdrv != NULL && !di->bdrv->removable) {
> > >>> +            DeviceState *ds = bdrv_get_attached(di->bdrv);
> > >>> +            if (ds) {
> > >>> +                bdrv_detach(di->bdrv, ds);
> > >>> +            }
> > >>> +            bdrv_close(di->bdrv);
> > >>> +            pci_ide->bus[di->bus].ifs[di->unit].bs = NULL;
> > >>
> > >> Have you tested if this is enough if the guest tries to continue using
> > >> the device? I don't know of any case where it's not sufficient, just
> > >> trying to make sure that it's really true in practice.
> > > 
> > > The purpose of this is to "hide" the disk from the guest. The unplug is
> > > supposed to happen *before* the guest enumerates the IDE disks; it is
> > > responsibility of the guest to make sure of it.
> > > I tested it with Linux PV on HVM drivers, and Linux doesn't see the
> > > emulated disk after the unplug, as it should be.
> > 
> > Yeah. What I meant is that we should make sure that a misbehaving guest,
> > which just keeps on playing with the IDE ports anyway, can't crash qemu.
> > A quick review suggests that it is the case, but testing it anyway would
> > be better.
> 
> I see what you mean: I tested it, a guest cannot crash Qemu.
> 

ping?

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