On 06.09.2021 22:47, Elliott Mitchell wrote: > On Mon, Sep 06, 2021 at 09:52:17AM +0200, Jan Beulich wrote: >> On 06.09.2021 00:10, Elliott Mitchell wrote: >>> I brought this up a while back, but it still appears to be present and >>> the latest observations appear rather serious. >>> >>> I'm unsure of the entire set of conditions for reproduction. >>> >>> Domain 0 on this machine is PV (I think the BIOS enables the IOMMU, but >>> this is an older AMD IOMMU). >>> >>> This has been confirmed with Xen 4.11 and Xen 4.14. This includes >>> Debian's patches, but those are mostly backports or environment >>> adjustments. >>> >>> Domain 0 is presently using a 4.19 kernel. >>> >>> The trigger is creating a HVM or PVH domain where memory does not equal >>> maxmem. >> >> I take it you refer to "[PATCH] x86/pod: Do not fragment PoD memory >> allocations" submitted very early this year? There you said the issue >> was with a guest's maxmem exceeding host memory size. Here you seem to >> be talking of PoD in its normal form of use. Personally I uses this >> all the time (unless enabling PCI pass-through for a guest, for being >> incompatible). I've not observed any badness as severe as you've >> described. > > I've got very little idea what is occurring as I'm expecting to be doing > ARM debugging, not x86 debugging. > > I was starting to wonder whether this was widespread or not. As such I > was reporting the factors which might be different in my environment. > > The one which sticks out is the computer has an older AMD processor (you > a 100% Intel shop?).
No, AMD is as relevant to us as is Intel. > The processor has the AMD NPT feature, but a very > early/limited IOMMU (according to Linux "AMD IOMMUv2 functionality not > available"). > > Xen 4.14 refused to load the Domain 0 kernel as PVH (not enough of an > IOMMU). That sounds odd at the first glance - PVH simply requires that there be an (enabled) IOMMU. Hence the only thing I could imagine is that Xen doesn't enable the IOMMU in the first place for some reason. Jan
