On Tue, Aug 29, 2017 at 02:37:50PM +0100, Igor Druzhinin wrote: > On 29/08/17 14:33, Wei Liu wrote: > > On Tue, Aug 29, 2017 at 02:24:49PM +0100, Andrew Cooper wrote: > >> On 29/08/17 09:50, Roger Pau Monne wrote: > >>> Commit 149c6b unmasked an issue long present in Xen: the control/event > >>> block addresses provided in the ACPI FADT table where hardcoded to the > >>> V1 version. This was papered over because hvmloader would also always > >>> set HVM_PARAM_ACPI_IOPORTS_LOCATION to 1 regardless of the BIOS > >>> version. > >>> > >>> Fix this by passing the address of the control/event blocks to > >>> acpi_build_tables, so the values can be properly set in the FADT > >>> table provided to the guest. > >>> > >>> Signed-off-by: Roger Pau Monné <roger....@citrix.com> > >>> --- > >>> Cc: Igor Druzhinin <igor.druzhi...@citrix.com> > >>> Cc: Jan Beulich <jbeul...@suse.com> > >>> Cc: Andrew Cooper <andrew.coop...@citrix.com> > >>> Cc: Ian Jackson <ian.jack...@eu.citrix.com> > >>> Cc: Wei Liu <wei.l...@citrix.com> > >>> --- > >>> This commit should fix the qumu-trad Windows errors seen by osstest. > >> > >> This changes windows behaviour, but does not fix windows. Windows now > >> boots, but waits forever while trying to reboot after installing PV > >> drivers. There is no hint in the qemu log that the ACPI shutdown event > >> was received. > >> > >> Unless someone has some very quick clever ideas, the original fix will > >> need reverting. > > > > If I don't get a new fix by the end of today I'm going to revert Igor's > > patch (but keep Roger's patch in tree). > > > > I guess the easiest way to overcome it would be to set "qemu-xen" as a > device-model in libxl unconditionally.
I don't think that's right because libxl does support both qemu-xen and qemu-trad. The value written in xenstore should reflect the reality. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
