On Tue, Sep 20, 2022 at 05:33:42PM +0100, Marc Zyngier wrote: > On Tue, 20 Sep 2022 16:39:47 +0100, > Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > > On Mon, Sep 19, 2022 at 07:12:53PM +0100, Marc Zyngier wrote: > > > On Mon, 05 Sep 2022 18:01:55 +0100, > > > Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > > > > Peter, please let me know if you want to pick this series up together > > > > with your other KVM patches. Otherwise I can post it separately, it's > > > > worth merging it on its own as it clarifies the page flag vs tag setting > > > > ordering. > > > > > > I'm looking at queuing this, but I'm confused by this comment. Do I > > > need to pick this as part of the series? Or is this an independent > > > thing (my hunch is that it is actually required not to break other > > > architectures...). > > > > This series series (at least the first patches) won't apply cleanly on > > top of 6.0-rc1 and, of course, we shouldn't break other architectures. I > > can repost the whole series but I don't have the setup to test the > > MAP_SHARED KVM option (unless Peter plans to post it soon). > > I don't feel brave enough to take a series affecting all architectures It shouldn't affect the others, the only change is that PG_arch_2 is now only defined for arm64 but no other architecture is using it. The problem with loongarch is that it doesn't have enough spare bits in page->flags and even without any patches I think it's broken with the right value for NR_CPUS. > so late in the game, and the whole thing had very little arm64 > exposure. The latest QEMU doesn't seem to work anymore, so I don't > have any MTE-capable emulation (and using the FVP remotely is a pain > in the proverbial neck). > > I'll come back to this after the merge window, should Peter decide to > respin the series. It makes sense. -- Catalin _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
