From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36062) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zn8QJ-0001ik-2c for qemu-devel@nongnu.org; Fri, 16 Oct 2015 13:04:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zn8QH-0008Dz-Fx for qemu-devel@nongnu.org; Fri, 16 Oct 2015 13:04:07 -0400 Date: Fri, 16 Oct 2015 19:03:56 +0200 From: Kevin Wolf Message-ID: <20151016170356.GI4185@noname.redhat.com> References: <561E3865.1010500@m2r.biz> <9AAE0902D5BC7E449B7C8E4E778ABCD02F6114DD@AMSPEX01CL01.citrite.net> <20151016140416.GD4185@noname.redhat.com> <9AAE0902D5BC7E449B7C8E4E778ABCD02F616715@AMSPEX01CL01.citrite.net> <20151016150226.GF4185@noname.redhat.com> <9AAE0902D5BC7E449B7C8E4E778ABCD02F616927@AMSPEX01CL01.citrite.net> <20151016161152.GG4185@noname.redhat.com> <9AAE0902D5BC7E449B7C8E4E778ABCD02F616CC1@AMSPEX01CL01.citrite.net> <20151016164257.GH4185@noname.redhat.com> <9AAE0902D5BC7E449B7C8E4E778ABCD02F616F4B@AMSPEX01CL01.citrite.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9AAE0902D5BC7E449B7C8E4E778ABCD02F616F4B@AMSPEX01CL01.citrite.net> Subject: Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Durrant Cc: "qemu-block@nongnu.org" , "qemu-devel@nongnu.org" , "xen-devel@lists.xen.org" , Fabio Fantoni , Stefano Stabellini , Anthony Perard , John Snow Am 16.10.2015 um 18:53 hat Paul Durrant geschrieben: > > > > > > Just tell your admin what virtual hardware you really need. (Or tell > > > > > > them to give you a proper interface to configure your VMs yourself.) > > > > > > > > > > > > > > > > My point is that the virtual hardware that the OS user wants will > > > > > change. Before they install PV drivers, they will need emulated > > > > > device. After installing PV drivers they will want PV devices. Should > > > > > they really have to contact their cloud provider to make the switch, > > > > > when at the moment it happens automatically and transparently (the > > > > > AHCI problem aside)? > > > > > > > > My point is that such a magic change shouldn't happen. It doesn't happen > > > > on real hardware either and people still get things installed to non-IDE > > > > disks. > > > > > > > > There is no reason to install the OS onto a different device than will > > > > be used later. With Linux, it's no problem at all because the PV drivers > > > > are already included on the installation media anyway, and on Windows > > or > > > > presumably any other OS you can load and install the drivers right from > > > > the beginning. > > > > > > > > In fact, I would be surprised if using xendisk instead of IDE for > > > > installing Windows didn't result in a noticably faster installation. > > > > > > > > > > It most certainly would, but requiring users do it this way is likely to meet > > some resistance I suspect. > > > > Why do you think so? Installing the PV drivers afterwards doesn't seem > > easier than just providing them during the installation. > > > > My experience of XenServer customers tells me that any form of manual > intervention during guest install is likely to meet with resistance, > unfortunately. Do they consider the guest install complete before they manually intervene for installing the PV drivers? I'm no Windows expert, but I'm sure there is a way to automate installation even when a driver disk is needed. > > > > Now, if you really insist on providing a legacy interface even to guests > > > > that eventually use PV drivers, there actually are sane ways to > > > > implement this. It will be tricky to make that transition now without > > > > breaking compatibility, but it could have been done from the start. > > > > > > > > Sane means for example that you don't open the same image twice (and > > > > even read-write!) at the same time. This is a recipe for disaster and > > > > it's surprising that you don't see corrupted images more often. > > > > > > > > > > We don't because unplug is supposed to ensure the emulated device is > > > gone before the PV frontend is started > > > > The important part is the backend, but it seems that you open the second > > instance of the image only when starting the PV frontend? > > I believe this is the case, yes. > > > > > As long as you don't enable the user to use most of qemu's functionality > > like starting block jobs (which would keep the IDE instance around even > > after unplugging the disk), it might actually be safe assuming that the > > guest cooperates. Not sure what a malicious guest could do, though, as > > nobody seems to check whether IDE is really unplugged before the second > > instance is opened. > > The Windows drivers do check. After the unplug Windows is asked to > re-enumerate the IDE buses and we make sure the disks we expect to be > gone are really gone. You can't use guest code to protect against malicious guests. > > raw and qcow2 should be safe these days, but in > > earlier times it would probably have been possible for the guest to > > overwrite the image header and access arbitrary files on the host as > > backing file. It might still be true for other image formats. > > > > > > So if you wanted to have a clean solution, try to think how real > > > > hardware would solve the problem. If you want me to suggest something > > > > off the top of my head, I would come up with an extended IDE device > > (one > > > > single device!) that provides the IDE I/O ports and additionally some > > > > MMIO BAR that enables access to PV functionality. > > > > > > > > Once you enable PV functionality, the IDE ports stop working; device > > > > reset disables the PV ring and goes back to IDE mode. No hard disk > > > > suddenly disappearing from the machine, no image corruption if the IDE > > > > device is written to before enabling PV, etc. > > > > > > > > > > That's not sufficient though. The IDE device must not be enumerated by > > > the OS and, in Windows at least, that enumeration occurs before the PV > > > frontend has started up. > > > > The trick is that it's only a single device, so there is no second > > device that must be prevented from being enumerated. You provide a > > driver for this specific IDE controller, so Windows wouldn't even try > > the generic IDE driver when your driver is available. > > > > But the whole point is that we want Windows to use the generic IDE > driver. If we had a driver in Windows from the outset then it would be > pure PV and there'd be no problem :-) And it would do that when your driver isn't available. This fallback is the difference from a pure PV device. But as soon as your driver is available, it will be preferred and the generic IDE driver won't be used any more. Kevin > > It's kind of the same sort of IDE controller extension as Bus Master > > DMA, which just added a new BAR. If you had an old driver, it would just > > ignore the new registers. If you had a new one, it would use them. But > > in no way would the old appearance of the device simply disappear, you > > just use an extended register set on the same device. > > > > > > But it's your choice. You can keep your broken hack in IDE. Just don't > > > > expect anyone to support adding new broken hacks to other devices. > > > > > > > > > > I'd prefer to have a cleaner solution and I believe can achieve that in > > Windows by obscuring the emulated disks using filter drivers, so that's the > > way I'll probably go. > > > > I wouldn't consider anything that works with two distinct disk devices > > and two separate BlockDriverStates for the same image file a clean > > solution. > > > > Kevin