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

From: Julien Grall <julien.grall@arm.com>
To: Andrii Anisov <andrii.anisov@gmail.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 11:31:56 +0100	[thread overview]
Message-ID: <a59d8d2e-0858-dc9c-466e-860657727698@arm.com> (raw)
Message-ID: <20190515103156.g7QkgKs8d43DyxlYVr5A7ogANolabV1JCawxy106VHc@z> (raw)
In-Reply-To: <c58b5000-623d-766e-eba8-a4df1fbe1a44@gmail.com>

Hi Andrii,

On 15/05/2019 10:04, Andrii Anisov wrote:
> 
> 
> 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.
There are actually no good reason for a guest to register via the two interfaces 
at the same time. The more we want to encourage the OS developer to switch to 
the new interface.

I also provided in my previous e-mails way to make the two working together 
without much trouble.

> 
>> 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.

0x0 is not an option. It could be a valid physical address. We need a value that 
cannot be used by anyone.

> 
>>  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.

Well, if a bootloader keep some part in memory (such as for handling runtime 
services), it will usually mark those pages are reserved. So it can't be used by 
the kernel.

But here, the point is it would not be difficult to handle 2). So why would you 
try to forbid it?

Cheers,

-- 
Julien Grall

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