Re: [Xen-devel] [PATCH v2 2/2] xen: implement VCPUOP_register_runstate_phys_memory_area

From: Andrii Anisov <andrii.anisov@gmail.com>
To: Julien Grall <julien.grall@arm.com>, Jan Beulich <JBeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	xen-devel <xen-devel@lists.xenproject.org>,
	"andrii_anisov@epam.com" <andrii_anisov@epam.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 2/2] xen: implement VCPUOP_register_runstate_phys_memory_area
Date: Wed, 15 May 2019 12:04:09 +0300	[thread overview]
Message-ID: <c58b5000-623d-766e-eba8-a4df1fbe1a44@gmail.com> (raw)
Message-ID: <20190515090409.-HdOdUIhKSPFGQf6FLTReCUzn_dLjuEVvWi0QJ-eqc4@z> (raw)
In-Reply-To: <8f1d8d76-b2a6-7443-a38b-201058b6e84d@arm.com>

On 14.05.19 16:49, Julien Grall wrote:
> You have to keep in mind that existing OS have to run on newer Xen without any modification.

As I just written to Jan, it is one more reason to keep those interfaces living in parallel and do not mix their implementation.

> The existing hypercall allows you to:
>     1) De-register an interface using the value 0.

My current implementation can easily be updated with the same behavior.

>     2) Replacing a current existing interface

> You probably can't use 2) for a bootloader -> kernel handover because we are dealing with guest virtual address. There is an high chance the virtual address space layout is going to be different or even turning off MMU for a bit (done on Arm). So you have to use 1) otherwise you might write in a random place in memory.

This definitely not the way to handle transitions between systems in a guest domain.

> I am not entirely sure whether there are actual value for 2). The only reason I can think of is if you want to move around the runstate in your virtual address space. But that's sounds a bit weird at least on Arm.
> For the new hypercall, I think we at least want 1) (with a magic value TBD). 

The magic value 0x0 can easily be introduced.

>  2) might be helpful in the case the bootloader didn't do the right thing or we are using Kexec to boot a new kernel. This would also be safer as physical address could be excluded more easily.

But the new system have to get some knowledge about the previous phys addr is reserved (used by hypervisor), and do not use it prior to registering new runstate area.
Providing such a knowledge is something (e.g.) the bootloader should take care of. But, IMO, it is better to require from (e.g.) the bootloader to unregister its runstate area prior to switching to the new system.

-- 
Sincerely,
Andrii Anisov.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel