All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Antoine Damhet <antoine.damhet@blade-group.com>,
	Igor Mammedov <imammedo@redhat.com>,
	"Richard W.M. Jones" <rjones@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set.
Date: Thu, 26 Nov 2020 08:25:14 -0500	[thread overview]
Message-ID: <20201126082033-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <0d63ed0e-4dae-9f7e-9512-45c94e1968f0@redhat.com>

On Thu, Nov 26, 2020 at 01:51:43PM +0100, Laszlo Ersek wrote:
> On 11/26/20 12:09, Michael S. Tsirkin wrote:
> > On Wed, Nov 25, 2020 at 09:13:22PM +0100, Antoine Damhet wrote:
> >> On Wed, Nov 25, 2020 at 11:04:55AM -0500, Michael S. Tsirkin wrote:
> >>> On Wed, Nov 25, 2020 at 01:32:51PM +0000, Richard W.M. Jones wrote:
> >>>> On Wed, Nov 25, 2020 at 02:27:11PM +0100, Antoine Damhet wrote:
> >>>>> Hello,
> >>>>>
> >>>>> We recently found out that some softwares are effectively crashing
> >>>>> when they detect qemu's `OEM ID` or `OEM table ID` in the ACPI tables.
> >>>>>
> >>>>> I see no reason not to expose the setting to the user/command-line. A
> >>>>> previous patch has been submitted in 2015[1] but did not get through
> >>>>> because (if I understand correctly) using the IDs on the `SLIC`, `BXPC`
> >>>>> and `RSDT` tables were enough at the time.
> >>>>>
> >>>>> If you agree, I am willing to forward port the patches of M. Jones but I
> >>>>> need to ask how it would work `Signed-Off`-wise ?
> >>>>
> >>>> On this point, the patch I sent was actually written by
> >>>> Michael Tokarev, I was only trying to get them upstream.
> >>>>
> >>>> Rich.
> >>>
> >>> I think at least one of the issues is that e.g. UEFI at least
> >>> seems to assume unique OEM table IDs e.g. for SSDTs.
> >>>
> >>> So let's try to be more specific please, which software
> >>> crashes, what does it want to see and in which table.
> >>
> >> I'm sorry I cannot give you the name of the crashing software due to a
> >> company policy. But I can tell you that if either `BOCHS ` or `BXPC` is
> >> present in any of the tables it will crash. Any (or at least the few
> >> that I threw at it) other string will work so it seems it's some kind
> >> of DRM-related hypervisor detection.
> > 
> > Hmm I'm not sure how far we want to go with this. If software vendors
> > want to detect a hypervisor there will always be a way.
> > How are we sure we are not starting an arms race here?
> > 
> > Also which of the IDs matter?  OEMID? OEM Table ID? Creator ID?
> > 
> > 
> >> As for the uniqueness of the table IDs, I guess it would be sane to keep
> >> the same pattern (id+table sig) but allowing the first 4 bytes to be
> >> overridden.
> >>
> >> [...]
> > 
> > It's certainly possible, it's just very specific to just this DRM scheme.
> > Not sure what's a better way to do it:
> >   qemu -acpidefault oem_id=ABCD,oem_table_id=EFGHIJKL
> > is probably going too far since then table IDs are not unique.
> > 
> > Also I'd probably use machine properties for this, the need here
> > is baroque enough that we don't want a dedicated option.
> 
> Minimally, I dislike the partial overlap with the existent "-acpitable"
> switch.
> 
> Thanks
> Laszlo

Well the existing -acpitable is very powerful and easy to break guests
with, it can not really be fully supported.

> > 
> >>
> >> -- 
> >> Antoine 'xdbob' Damhet
> > 



      reply	other threads:[~2020-11-26 13:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-25 13:27 [DISCUSSION] Allow ACPI default OEM ID and OEM table ID fields to be set Antoine Damhet
2020-11-25 13:32 ` Richard W.M. Jones
2020-11-25 16:04   ` Michael S. Tsirkin
2020-11-25 20:13     ` Antoine Damhet
2020-11-26 11:09       ` Michael S. Tsirkin
2020-11-26 12:50         ` Antoine Damhet
2020-11-26 13:29           ` Michael S. Tsirkin
2020-11-26 16:34             ` Antoine Damhet
2020-11-26 17:05               ` Michael S. Tsirkin
2020-11-26 19:41                 ` Igor Mammedov
2020-11-26 17:09               ` Michael S. Tsirkin
2020-11-26 17:37                 ` Antoine Damhet
2020-11-26 12:51         ` Laszlo Ersek
2020-11-26 13:25           ` Michael S. Tsirkin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201126082033-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=antoine.damhet@blade-group.com \
    --cc=imammedo@redhat.com \
    --cc=lersek@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.