qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/2] acpi: Allow ACPI default OEM ID and OEM tab


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH 1/2] acpi: Allow ACPI default OEM ID and OEM table ID fields to be set.
Date: Thu, 3 Sep 2015 22:55:49 +0300

On Thu, Sep 03, 2015 at 05:37:15PM +0200, Laszlo Ersek wrote:
> On 09/03/15 17:17, Michael Tokarev wrote:
> > 03.09.2015 18:09, Laszlo Ersek wrote:
> >> On 09/02/15 23:32, Michael S. Tsirkin wrote:
> >>> On Wed, Sep 02, 2015 at 08:03:37PM +0100, Richard W.M. Jones wrote:
> >>>> When using qemu's internal ACPI table generation, qemu sets the fields
> >>>> OEM ID and OEM table ID to arbitrary default values.  OEM ID is set to
> >>>> "BOCHS " and OEM table ID is set to "BXPCxxxx" where "xxxx" is
> >>>> replaced by the ACPI table name (eg. "BXPCRSDT" for the RSDT table).
> >>>>
> >>>> This patch allows you to override these default values.
> >>>>
> >>>> Use one of these alternatives:
> >>>>
> >>>>   qemu -acpidefault oem_id=ABCD,oem_table_id=EFGH
> >>>>   qemu -acpidefault oem_id=ABCD,oem_table_id=EFGHIJKL
> >>>>
> >>>> In the first case, the last four types of the OEM table name field are
> >>>> set to the ACPI table name.
> >>>>
> >>>> This does not affect the -acpitable option (for user-defined ACPI
> >>>> tables), which has its own method for setting these fields.
> >>>>
> >>>> Signed-off-by: Richard W.M. Jones <address@hidden>
> >>>
> >>> I don't think the 1st option makes sense - why force
> >>> 4 bytes of the ID?
> >>>
> >>> And the issue with the 2nd one is that it won't work if
> >>> there are two tables with same ID - which might be the
> >>> case for SSID and UEFI tables at least.
> >>>
> >>> Maybe specify this per signature?
> >>
> >> I agree with these remarks, but I'd propose a different idea for solving
> >> the OEM Table ID problem.
> >>
> >> As can be seen from the previous discussion that Rich linked in the
> >> blurb, and from Michael Tokarev's patch, and from Chris Evich's earlier
> >> testing of Win8.1 (linked in the previous discussion), the *only* guest
> >> OS where this matters is Windows 7. And Windows 7 doesn't care about the
> >> OEM Table Id, only the OEM Id.
> > 
> > Actually win7 do care about oem table id.  And my patch shows it.  This
> > is the minimal portion of RSDT (and also FACP in UEFI mode) which should
> > match SLIC -- oem_id (6 bytes) and oem_table_id (8 bytes). My patch copies
> > 10 bytes starting with oem_id.
> 
> Actually, 6 + 4 + 4 = 14, so OemID and OemTableID. But, you are right, I
> was working off the commit message & comments only, not the actual
> amount of bytes copied.
> 
> This ties down both OemID and OemTableId, between all of RSDT, SLIC, and
> FADT. Since
> - I argue against exposing a generic oem_table_id on the command
>   line (unlike oem_id),
> - and I also find that an oem_table_id "map" would be overkill,
> 
> I think it follows that I can only ask for the special SLIC-handling
> logic already visible in your patch. "User passed in SLIC --> adapt RSDT
> and FADT." That is, it is already user-controlled.
> 
> (The FADT change will ensure that OVMF will update the RSDT that *it*
> installs.)
> 
> This is just my preference, of course... But at least it doesn't seem to
> conflict with Michael's! :)
> 
> Thanks
> Laszlo

If done this way, I think a machine option to turn this off
might not be a bad idea, just in case.

> > Without that, win7 offline activation
> > doesn't work.
> > 
> > FWIW :)
> > 
> > Thanks,
> > 
> > /mjt
> > 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]