Re: [Xen-devel] [PATCH v2][RFC] libxl: Add AHCI support for upstream qemu

[Zir Blazer <zir_blazer@xxxxxxxxxxx>]

Since I'm not a developer I may be peeking my nose a bit too far, but based on 
what I know, I think that enabling AHCI by default would be a compatibility 
suicide. I'm not sure about Linux and Windows Vista/7/8+, but at least for 
Windows XP based VMs, it would be a terrible idea.


Back during WXP years, the vanilla install ISO didn't had any AHCI Drivers 
integrated at all. If you set the SATA Controller to AHCI, the WXP installation 
wouldn't detect any Hard Disk at all. If you really wanted to use AHCI during 
its early days, you would need a Floppy Disk with the AHCI Drivers of your SATA 
Controller (Chipset/South Bridge or third party controller), that you could use 
by pressing the F6 key right after booting the install CD:
http://www.pc-tips-and-tricks.com/images/Install-windows-xp-02.jpg

If you didn't had a Floppy Disk Driver or were lazy, the typical choice was to 
set the SATA Controller to IDE and install WXP, skipping anything AHCI related.

At some point an application called nLite appeared, which allowed you to make 
your custom Windows XP ISO. You could easily modify a lot of default options, 
integrate hotfixes, and even Drivers, and after you were happy with your 
changes, you could then make your custom ISO and burn it to a CD (Or from a USB 
Flash Drive with other tools to make it booteable). So, with nLite, it was 
rather easy to integrated the AHCI Drivers of your SATA Controller to the 
install ISO. This way, if you were doing a fresh install, reinstall or repair, 
there was no excuse to not use AHCI.
However, since for VM usage AHCI was not available at all until QEMU 
implemented it recently, by default you will be always using IDE, so there was 
no actual need to make a customized WXP install ISO with AHCI Drivers that you 
were never going to use. Besides, Windows XP doesn't even install nor have 
ready any AHCI Drivers if you're in IDE mode, so if you're going to switch to 
use AHCI by default, every existing WXP VM would greet you with a BSOD after 
upgrading Xen.


So, with this proposal you would have two issues: First, doing a new install of 
Windows XP on a VM , since by default it shouldn't detect any HD at all in 
AHCI. Second, that existing WXP VMs will BSOD on boot. For as long as you can 
switch to IDE mode everything should still be working as always, but it would 
mean that at the very least you would have to modify the DomU config file to 
replace default AHCI with old IDE.

Regarding using Windows XP with AHCI:
First, as stated before, if you want to install it on a new VM, you need the 
AHCI Drivers. Since it seems that at some point support for Floppy Disk got 
removed from Xen (I tried recently to use a Floppy Disk image with fda= as 
stated somewhere on the wiki, but it did nothing. Nor I found any recent 
documentation claiming that you can mount a Floppy Disk image at all), the only 
choice is to make a custom ISO with nLite with the AHCI Drivers integrated in 
it. Since the emulated Southbridge is an Intel ICH9, I believe that the Drivers 
that should be needed are these:
http://www.win-raid.com/t22f23-Guide-Integration-of-Intels-AHCI-RAID-drivers-into-a-Windows-XP-W-k-W-k-CD.html
Check for the a) and c) options for WXP/2003 in 32 and 64 Bits variants.

Also, it is important to note that the plain ICH9 Southbridge according to 
Intel DOES NOT OFFICIALLY HAVE AHCI SUPPORT, ICH9R does.
http://en.wikipedia.org/wiki/I/O_Controller_Hub#ICH9

The previous Drivers are claimed to have been modified to force support for 
ICH9 since AHCI is there, just that the original Drivers doesn't want to use 
it. Typical artificial market segmentation strategies. Still, if QEMU is 
emulating the plain ICH9 and you can't get Windows to see drives in AHCI mode 
after integrating the AHCI Drivers, that may be why.


Second, it is possible to switch from IDE to AHCI on WXP without reinstalling, 
but doing it is rather hacky and instructions are very Chipset and vendor 
dependant, which may (Or not) include editing Windows registry. Here are 
instructions that claim to work for Intel Southbridges, which since we're using 
ICH9, may possibily work for Xen based WXP VMs:
http://www.prime-expert.com/articles/a11/change-from-ide-to-ahci-without-reinstalling-windows-xp.php

But should these not work, chances are that you will need to add a rescue ISO 
to your DomU config file to repair the broken install, since I'm not 100% sure 
if you can even get it to boot in Safe Mode if it BSODs at boot.


I think that's all what I could figure out. If you're using the GPLPV Drivers I 
don't know if there are any changes regarding running in AHCI mode.



----------------------------------------
> Date: Mon, 8 Jun 2015 16:17:39 +0200
> From: fabio.fantoni@xxxxxxx
> To: stefano.stabellini@xxxxxxxxxxxxx
> CC: xen-devel@xxxxxxxxxxxxxxxxxxx; wei.liu2@xxxxxxxxxx; 
> Ian.Campbell@xxxxxxxxxx; Ian.Jackson@xxxxxxxxxxxxx; Paul.Durrant@xxxxxxxxxx; 
> anthony.perard@xxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH v2][RFC] libxl: Add AHCI support for upstream 
> qemu
>
> Il 08/06/2015 16:00, Stefano Stabellini ha scritto:
>> On Tue, 19 May 2015, Fabio Fantoni wrote:
>>> Il 19/05/2015 12:40, Wei Liu ha scritto:
>>>> On Mon, May 18, 2015 at 07:22:01PM +0200, Fabio Fantoni wrote:
>>>>> Il 18/05/2015 17:53, Wei Liu ha scritto:
>>>>>> On Thu, May 14, 2015 at 01:11:13PM +0200, Fabio Fantoni wrote:
>>>>>>> Usage:
>>>>>>> ahci=0|1 (default=0)
>>>>>>>
>>>>>>> If enabled adds ich9 disk controller in ahci mode and uses it with
>>>>>>> upstream qemu to emulate disks instead of ide.
>>>>>> Is ICH9 available in our default setup?
>>>>>>
>>>>>> Why do we not always enable AHCI?
>>>>> ahci seems require ich9 controller (default in q35 but not in older used
>>>>> by
>>>>> xen), I think that change it ide->ahci automatically for all cases may
>>>>> causes problems, probably in save/restore and more probably in windows <=7
>>>>> without pv where change ide<->ahci require a registry change for not have
>>>>> blue screen.
>>>>>
>>>> I guess we now have a QEMU with Q35. But migrating from previous
>>>> previous versions will indeed need to be taken care of.
>>> This patch don't add q35 cipset support but only ich9 ahci disk controller 
>>> in
>>> older and only cipset supported in xen.
>> This is pretty nice actually, thanks for the patch!
>>
>>
>>> Time ago I tried to add q35 support in xen but I had some problems I was
>>> unable to solves and nobody helped me.
>>> Q35 have newer ich9 ahci disk controller as default, on older cipset must be
>>> added (done in this patch).
>>> qemu, kvm ovmf already support q35, xen need changes at least in hvmloader
>>> (that I'm probably unable to do) and libxl (that I started time ago without
>>> good result), Add ahci support and switch all qemu parameters in libxl to 
>>> new
>>> -device is a good start also for future q35 support (are both part needed
>>> based on my old q35 tests on xen)
>> Yeah, going q35 opens a whole new can of worms. I think that adding the
>> ich9 chipset to the existing machine is a good compromise.
>>
>>
>>>>>>> It doesn't support cdroms which still use ide (cdroms will use
>>>>>>> "-device
>>>>>>> ide-cd" as new qemu parameters)
>>>>>>> Ahci requires new qemu parameters but for now other emulated disks
>>>>>>> cases
>>>>>>> remains with old ones because automatic bus selection seems bugged in
>>>>>>> qemu using new parameters. (I'll retry)
>>>>>>>
>>>>>> Buggy as in? Have you reported to QEMU upstream?
>>>>> Already reported long time ago in xen-devel and qemu-devel, the only reply
>>>>> from qemu-devel was to use fixed bus and is what I did in v2 of this
>>>>> patch.
>>>>> Can someone tell me if can be a problem fixed bus?
>>>>>
>>>> I don't have enough knowledge on this. Maybe Anthony and Stefano have
>>>> more insight.
>> Let me get this straight: cdrom still works but goes via ide. In
>> addition AHCI disks can be attached. Seems good to me.
>>
>> Have you tested Windows?
>>
>> If this works with Windows too, I would expose an ahci option
>> (default=off) in the config file. If ahci=on, then all disks could be
>> exposed via ahci. Does this seem sensible? In a couple of releases, if
>> it works well, we could make ahci=on the default.
>
> I tested both linux and windows, mainly windows domUs (7 and 8.1).
> Windows < 8 FWIK needs a registry key change for switch ide<->ahci
> without bluescreen (this is the reason because I did ahci=0|1 instead
> change it by default) but trying with windows 7 with pv is possible
> change without bluescreen, probably the problem is only without pv but
> ahci option default disabled resolve it (for the users don't set ahci=0
> on xen upgrade process).
> Based on what I know and all tests I did this patch seems the best way
> for add ahci support but I think that a experts (like you) review is better.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
                                          
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel