Re: [Xen-devel] Status of HVM improvements, support of recent technologies and request for some tips

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 3 Aug 2015, Fabio Fantoni wrote:
> Some years ago the support/improvement of hvm domUsseemed neglected, recently
> seems to be good.
> 
> Qemu upstream when I started using early versions from the 1.2 was neglected
> but now it seems early to be quite used, tested and considered, thanks to all
> those who are working to improve support for xen.

Thanks!


> New windows pv driversseems to be well alignedwith several improvements.
> I found many bugs at the beginning but thanks to Paul Durrant have been
> resolved quickly.
> Will be an official xen project build withsigned drivers out there?
> 
> OVMF (eufi firmware for hvm domUs) support some years ago was bad but now with
> contribution of Anthony Perard and Wei Lui seems usable with windows and linux
> domUs.
> On my latest fast tests I found that boot option is not working or not
> supported for now as I reported in another mail.
> Should I report it to ovmf upstream?

Yeah, this needs to be fixed. Unfortunately this is one of the things
that don't get tested by OSSTest, so if it breaks we don't notice.


> In boot tests I saw also floppy test that should be not present based on qemu
> settings: is it only a boot test or is there a bug about it?
> I'll test it further and I'll compare with seabios about some small strange
> things I found.

The floppy needs to work if it is specified in the xl config file. Please
report it as a bug, if that is the case.


> Actuallywhere a system binaries are specified they will not update
> automatically hvmloader built-in seabios and ovmf firmware but require xen
> rebuild (probably major for production system from distro build).
> I saw in wiki project "Improvements to firmware handling HVM guests" that
> include also it, is there any news about?

I agree that this is annoying. I am looking forward to relying less on
the xen-unstable build system to fetch and build external components
(like ovmf) and more on raisin. But this doesn't necessarily fix the
problem, just moves it from xen-unstable to raisin.


> Another probably good thing should be unified eufi and bios support in
> hvmloader.
> I saw in wiki project "OVMF Compatibility Support Module support in Xen", is
> there any news about?

Yes, you are right, it would be nice to have but AFAIK nobody is working
on it at the moment.

 
> Another interesting thing is Q35 support.
> Now we are still using very old emulated hardware based on I440FX emulation.
> Q35 adds emulation for the ICH9 host chipset, PCI-E bus by default, ahci disk
> controller by default and other things probably useful on recent systems.
> I did a fast tests with it on xen 2 years ago but I was blocked by disk not
> visible that was require new qemu parameters and that had a bug about.
> With a basic ahci support in libxl (included in 4.6) and another patch to
> convert other disk cases (I'll keep it tested and I'll repost for 4.7) seems
> that now is possible use new qemu parameters for disks, and I'll now retry Q35
> on xen.
> I'll probably start to write some libxl patches about and I have some
> questions:
> 
> Have someone already start to do it but without posting the patches for now?
> About xl parameter for chipset selection what is the correct parameter to add?
> device_model_machine="q35|i440fx" (default="i440fx") can be good?
> I did a fast look to in libxl_dm.c and I don't know what to do for q35 case of
> xen_platform_pci=0. Actually "-machine xenfv" is used but it seems only for
> old chipset case. Any idea/advice?
> AHCI disks controller is the default built-in in q35 instead of ide one for
> old chipset. Is it correct to force hdtype="ahci" with q35 and add a warning
> if user selects hdtype="ide"?
> If I remember well, is old pci bridge still needed
> ("-device","i82801b11-bridge") for emulated vgas support along other things or
> did something changed in the meanwhile?
> About hvmloader also this time I'll remove an assert (if I remember good) to
> do q35 tests but a better change is needed and I don't know about.
> Any help is appreciated.

The issue with Q35 is that it introduces incompatibility for little
benefit. Now that you added ahci support to HVM guests with i440fx, what
are the reasons to switch to q35? I am pretty sure that even Windows 10
runs on the i440fx.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel