On Tue, Aug 29, 2017 at 02:53:56PM +0100, Igor Druzhinin wrote:
> On 29/08/17 14:51, Wei Liu wrote:
> > 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.
> > 
> 
> In that case, probably worth reverting until we figure out why setting
> the right port location causes such an effect.

No problem. I will do that now.

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

Reply via email to