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
