Re: [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

[Kevin Wolf <kwolf@redhat.com>]

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