On 10/9/2026 5:16 AM, Edgecombe, Rick P wrote: > On Mon, 2026-08-17 at 10:58 -0700, Edgecombe, Rick P wrote: >>>> Actually why is this on top of in-place conversion? I thought the idea was >>>> to break the series apart to get something basic upstream: >>>> https://lore.kernel.org/all/[email protected]/ >>>> >>>> Adding in-place conversion tests seems to be going in the opposite >>>> direction. >>>> >>> >>> We wanted to have this series based on in-place conversion since >>> non-in-place conversion is on a deprecation path. >> >> Hmm, what kind of timeline do you see for the old interface actually getting >> yanked out of the kernel? I was imagining it would be there for many years at >> minimum, in which case it would need tests too. >> >> The level of dependencies we have on coco stuff is pretty unfortunate I >> think. >> Considering these tests should have ideally quickly followed the TDX base >> upstreaming, it would be nice if we could avoid it here. > > I saw the new version is also based on in-place conversion (which is now > headed > upstream, congrats!). But can we talk about the legacy deprecation? Is there a > plan to actually deprecate and remove it, or even move qemu off of the old > interface? > > Otherwise, I disagree with the plan to drop the tests for the old interface. > That said I'd would be thrilled to have anything upstream, so if the set can > be > smaller or faster that way, then I agree with the change.
The v15 actually supports both: out-of-place conversion (per-VM memory attributes) and in-place conversion. > But in general, I'd like to know the plan for the old interface. Sean talked something about it: https://lore.kernel.org/all/[email protected]/
