All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH] x86/PVH: expose OEMx ACPI tables to Dom0
Date: Wed, 26 Mar 2025 11:21:57 +0100	[thread overview]
Message-ID: <5fa59cc5-2072-4cee-b6f9-7d9cc6be9074@suse.com> (raw)
In-Reply-To: <Z-PUhO3C1qp3L8-l@macbook.local>

On 26.03.2025 11:18, Roger Pau Monné wrote:
> On Wed, Mar 26, 2025 at 10:45:18AM +0100, Jan Beulich wrote:
>> On 26.03.2025 10:21, Roger Pau Monné wrote:
>>> On Wed, Mar 26, 2025 at 09:45:09AM +0100, Jan Beulich wrote:
>>>> Further tables on said system
>>>> which weren't blacklisted prior to that commit, yet which also aren't
>>>> whitelisted are DBGP, DBG2, FIDT, LPIT, MIGT, MSCT, NITR, PCCT, RASF,
>>>> SVOS, UEFI, WDDT, and WSMT. Even without diving into the details of any
>>>> of them it seems pretty clear to me that at least some would want
>>>> whitelisting, too.
>>>
>>> I cannot find any reference about: FIDT, MIGT, NITR, SVOS and WDDT in
>>> the ACPI spec.
>>
>> WDDT - Watchdog Descriptor Table (Table 5.6 in spec version 6.5)
>>
>>> The MSCT I think we don't want to expose, as it's related to topology
>>> data.
>>>
>>> Regarding RASF I would be slightly worried about the patrol scrub
>>> feature.  The memory map exposed to dom0 will be different from the
>>> native one, and there's also the interposed p2m.
>>
>> Thing is - either kind of Dom0 needs to have a sufficient level of insight
>> into the host memory map to support memory-related RAS features. Which may
>> mean that RASF may only be exposed if the Dom0 kernel declares itself as
>> aware of the need to consider data there to refer to a separate address
>> space.
> 
> Yes, but then, how is a PVH dom0 going to be aware of such addresses?
> Given the automatic translation of gfn -> mfn that's completely hidden
> from dom0.

Right, but the knowledge is going to be necessary there, I expect.

> I'm not saying it can't be done, but I think RASF shouldn't be exposed
> to a PVH dom0 until we understand how such feature is supposed to work
> with the interposed p2m and the fabricated memory map available to a
> PVH dom0.  Note a PVH dom0 can still get the host memory map from the
> XENMEM_machine_memory_map hypercall.

Oh, of course I agree we can't expose such without first having dealt with
the implications.

Jan


      reply	other threads:[~2025-03-26 10:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-26  8:45 [PATCH] x86/PVH: expose OEMx ACPI tables to Dom0 Jan Beulich
2025-03-26  9:21 ` Roger Pau Monné
2025-03-26  9:45   ` Jan Beulich
2025-03-26 10:18     ` Roger Pau Monné
2025-03-26 10:21       ` Jan Beulich [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=5fa59cc5-2072-4cee-b6f9-7d9cc6be9074@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /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.