On 10/06/2024 7:47 pm, Marek Marczykowski-Górecki wrote: > On Mon, Jun 10, 2024 at 04:25:01PM +0100, Andrew Cooper wrote: >> On 10/06/2024 2:32 pm, Marek Marczykowski-Górecki wrote: >>> This tests if QEMU works in PVH dom0. QEMU in dom0 requires enabling TUN >>> in the kernel, so do that too. >>> >>> Add it to both x86 runners, similar to the PVH domU test. >>> >>> Signed-off-by: Marek Marczykowski-Górecki <marma...@invisiblethingslab.com> >> Acked-by: Andrew Cooper <andrew.coop...@citrix.com> >> >> CC Oleksii. >> >>> --- >>> Requires rebuilding test-artifacts/kernel/6.1.19 >> Ok. >> >> But on a tangent, shouldn't that move forwards somewhat? > There is already "[PATCH 08/12] automation: update kernel for x86 tests" > in the stubdom test series. And as noted in the cover letter there, most > patches can be applied independently, and also they got R-by/A-by from > Stefano already.
I've got yet more fixes to come too. I'll chase down some CI R-ack's in due course. > >>> I'm actually not sure if there is a sense in testing HVM domU on both >>> runners, when PVH domU variant is already tested on both. Are there any >>> differences between Intel and AMD relevant for QEMU in dom0? >> It's not just Qemu, it's also HVMLoader, and the particulars of VT-x/SVM >> VMExit decode information in order to generate ioreqs. > For just HVM, we have PCI passthrough tests on both - they run HVM (but > on PV dom0). My question was more about PVH-dom0 specific parts. Still a firm recommendation for both. Dom0 is a very different set of codepaths to other domains, and unlike PV (where almost all logic is common), for PVH there's large variety of VT-x/SVM specifics both in terms of configuring dom0 to start with, and at runtime. Within XenRT, it's been very rare that we've found a PVH dom0 bug affecting Intel and AMD equally. ~Andrew
