On Fri, Feb 07, 2020 at 11:04:03AM +0100, Igor Mammedov wrote: > On Fri, 7 Feb 2020 10:00:50 +0100 > Igor Kotrasiński <i.kotrasi...@partner.samsung.com> wrote: > > > On 2/5/20 3:49 PM, Jan Kiszka wrote: > > > On 05.02.20 15:39, Stefan Hajnoczi wrote: > > >> On Tue, Feb 04, 2020 at 12:30:42PM +0100, > > >> i.kotrasi...@partner.samsung.com wrote: > > >>> From: Igor Kotrasinski <i.kotrasi...@partner.samsung.com> > > >>> > > >>> This patchset adds a "memory exposing" device that allows two QEMU > > >>> instances to share arbitrary memory regions. Unlike ivshmem, it does not > > >>> create a new region of memory that's shared between VMs, but instead > > >>> allows one VM to access any memory region of the other VM we choose to > > >>> share. > > >>> > > >>> The motivation for this device is a sort of ARM Trustzone "emulation", > > >>> where a rich system running on one machine (e.g. x86_64 linux) is able > > >>> to perform SMCs to a trusted system running on another (e.g. OpTEE on > > >>> ARM). With a device that allows sharing arbitrary memory between VMs, > > >>> this can be achieved with minimal changes to the trusted system and its > > >>> linux driver while allowing the rich system to run on a speedier x86 > > >>> emulator. I prepared additional patches for linux, OpTEE OS and OpTEE > > >>> build system as a PoC that such emulation works and passes OpTEE tests; > > >>> I'm not sure what would be the best way to share them. > > >>> > > >>> This patchset is my first foray into QEMU source code and I'm certain > > >>> it's not yet ready to be merged in. I'm not sure whether memory sharing > > >>> code has any race conditions or breaks rules of working with memory > > >>> regions, or if having VMs communicate synchronously via chardevs is the > > >>> right way to do it. I do believe the basic idea for sharing memory > > >>> regions is sound and that it could be useful for inter-VM > > >>> communication. > > >> > > >> Hi, > > >> Without having looked into the patches yet, I'm already wondering if you > > >> can use the existing -object > > >> memory-backend-file,size=512M,mem-path=/my/shared/mem feature for your > > >> use case? > > >> > > >> That's the existing mechanism for fully sharing guest RAM and if you > > >> want to share all of memory then maybe a device is not necessary - just > > >> share the memory. > > > > That option adds memory in addition to the memory allocated with the > > '-m' flag, doesn't it? I looked into that option, and it seemed to me > > you can't back all memory this way. > with current QEMU you play with memory sharing using numa workaround > > -m 512 \ > -object memory-backend-file,id=mem,size=512M,mem-path=/my/shared/mem > feature,share=on \ > -numa node,memdev=mem > > also on the list there is series that allows to share main ram > without numa workaround, see > "[PATCH v4 00/80] refactor main RAM allocation to use hostmem backend" > > with it applied you can share main RAM with following CLI: > > -object memory-backend-file,id=mem,size=512M,mem-path=/my/shared/mem > feature,share=on \ > -m 512 \ > -M virt,memory-backend=mem
Nice! That takes care of memory. If signalling (e.g. a notification interrupt) is necessary then a mechanism is still needed for that. I don't know enough about TrustZone to suggest an appropriate way of doing it with existing QEMU features. Maybe Peter understands? Stefan
signature.asc
Description: PGP signature
