* Peter Maydell (peter.maydell@xxxxxxxxxx) wrote: > On Mon, 7 Dec 2020 at 16:44, Dr. David Alan Gilbert <dgilbert@xxxxxxxxxx> wrote: > > * Steven Price (steven.price@xxxxxxx) wrote: > > > Sorry, I know I simplified it rather by saying it's similar to protected VM. > > > Basically as I see it there are three types of memory access: > > > > > > 1) Debug case - has to go via a special case for decryption or ignoring the > > > MTE tag value. Hopefully this can be abstracted in the same way. > > > > > > 2) Migration - for a protected VM there's likely to be a special method to > > > allow the VMM access to the encrypted memory (AFAIK memory is usually kept > > > inaccessible to the VMM). For MTE this again has to be special cased as we > > > actually want both the data and the tag values. > > > > > > 3) Device DMA - for a protected VM it's usual to unencrypt a small area of > > > memory (with the permission of the guest) and use that as a bounce buffer. > > > This is possible with MTE: have an area the VMM purposefully maps with > > > PROT_MTE. The issue is that this has a performance overhead and we can do > > > better with MTE because it's trivial for the VMM to disable the protection > > > for any memory. > > > > Those all sound very similar to the AMD SEV world; there's the special > > case for Debug that Peter mentioned; migration is ...complicated and > > needs special case that's still being figured out, and as I understand > > Device DMA also uses a bounce buffer (and swiotlb in the guest to make > > that happen). > > Mmm, but for encrypted VMs the VM has to jump through all these > hoops because "don't let the VM directly access arbitrary guest RAM" > is the whole point of the feature. For MTE, we don't want in general > to be doing tag-checked accesses to guest RAM and there is nothing > in the feature "allow guests to use MTE" that requires that the VMM's > guest RAM accesses must do tag-checking. So we should avoid having > a design that require us to jump through all the hoops. Yes agreed, that's a fair distinction. Dave Even if > it happens that handling encrypted VMs means that QEMU has to grow > some infrastructure for carefully positioning hoops in appropriate > places, we shouldn't use it unnecessarily... All we actually need is > a mechanism for migrating the tags: I don't think there's ever a > situation where you want tag-checking enabled for the VMM's accesses > to the guest RAM. > > thanks > -- PMM > -- Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
