On (21/07/21 09:22), Marc Zyngier wrote: > On Wed, 21 Jul 2021 03:05:25 +0100, > Sergey Senozhatsky <senozhatsky@xxxxxxxxxxxx> wrote: > > > > On (21/07/12 16:42), Marc Zyngier wrote: > > > > > > > > PV-vcpu-state is a per-CPU struct, which, for the time being, > > > > holds boolean `preempted' vCPU state. During the startup, > > > > given that host supports PV-state, each guest vCPU sends > > > > a pointer to its per-CPU variable to the host as a payload > > > > > > What is the expected memory type for this memory region? What is its > > > life cycle? Where is it allocated from? > > > > Guest per-CPU area, which physical addresses is shared with the > > host. > > Again: what are the memory types you expect this to be used with? I heard your questions, I'm trying to figure out the answers now. As of memory type - I presume you are talking about coherent vs non-coherent memory. Can guest per-CPU memory be non-coherent? Guest never writes anything to the region of memory it shares with the host, it only reads what the host writes to it. All reads and writes are done from CPU (no devices DMA access, etc). Do we need any cache flushes/syncs in this case? > When will the hypervisor ever stop accessing this? KVM always access it for the vcpus that are getting scheduled out or scheduled in on the host side. > How does it work across reset? I need to figure out what happens during reset/migration in the first place. > I'm sorry to be that pressing, but these are the gory details that > actually matter if you want this thing to be maintainable. Sure, no problem. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
