Re: [PATCH] x86/shadow: Delete the none.c dummy file

[Jan Beulich <jbeulich@xxxxxxxx>]

On 09.02.2026 17:20, Alejandro Vallejo wrote:
> On Mon Feb 9, 2026 at 4:55 PM CET, Roger Pau Monné wrote:
>> On Mon, Feb 09, 2026 at 04:35:04PM +0100, Alejandro Vallejo wrote:
>>> On Mon Feb 9, 2026 at 3:42 PM CET, Roger Pau Monné wrote:
>>>> Also, seeing the code in arch_sanitise_domain_config() we possibly
>>>> want to return an error at that point if toolstack attempts to create
>>>> an HVM guest without HAP enabled, and shadow is build time disabled.
>>>> I've sent a patch to that end.
>>>
>>> ... this patch you meantion. Thanks.
>>>
>>> I'm guessing it's still a hot potato in for non-shadow PV, which strongly 
>>> hints
>>> at our being better off leaving it in that case. On HVM-only configurations 
>>> it
>>> seems rather silly.
>>
>> I'm not sure I follow exactly what you mean.
> 
> I'm not sure _I_ follow exactly what I mean. Part of the confusion is the
> overloaded use of "shadow" to mean "shadow paging" and "fault-and-track"
> of logdirty behaviour.

There's no such overload, I don't think. Shadow paging is _needed_ for certain
operations. E.g. to put a PV guest in log-dirty mode.

>> Some rants below which
>> might or might not be along the lines of what you suggest.
> 
> Thanks.
> 
>>
>> PV needs shadow for migration.
> 
> shadow in the sense of shadow paging? So PV-only + !SHADOW means migrations 
> are
> impossible? Why can't Xen operate on the PV pagetables rather than using 
> shadow?
> 
>> HVM can use shadow or HAP, and our default is HAP.
> 
> For regular use or migrations?

HVM guests always have paging enabled - either HAP or shadow. Hence this
distinction makes sense only for PV. However, the answer is still: Both.
Because besides for log-dirty tracking, shadow mode is also used there to
mitigate L1TF for guests not doing so on their own.

Jan