Re: [PATCH 0/2 for-4.12] Introduce runstate area registration with phys address

From: Andrii Anisov <andrii.anisov@gmail.com>
To: Julien Grall <julien.grall@arm.com>, xen-devel@lists.xen.org
Cc: "Juergen Gross" <jgross@suse.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Andrii Anisov" <andrii_anisov@epam.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH 0/2 for-4.12] Introduce runstate area registration with phys address
Date: Mon, 18 Mar 2019 15:38:24 +0200	[thread overview]
Message-ID: <e7a79173-a404-04fd-0271-d2b03bc5bc5b@gmail.com> (raw)
In-Reply-To: <01c84c0d-630b-1d8e-3a4b-e5497b83fd92@arm.com>


On 18.03.19 14:25, Julien Grall wrote:
> As I already said multiple times before, please try to explain everything in your first e-mail...
I know. I'm trying to provide enough info in the cover letter. But it seems I do not succeed.
Putting all the thoughts might lead into overburdened text. But it looks it should be done. Going to do that next time.

> The limitations you mention is only for GICv2. If you use GICv3, the number of CPUs can go much higher. Whether this is going to be use in the future is another question. However, I would rather try to not discard 32-bit from any discussion as you don't know how this is going to be used in the future.
> 
> The Arm32 port is interesting because all the memory is not mapped in Xen. There are chance that the Arm64 will go towards the same in the future.
> 
> I have been thinking a bit more about arm32.I don't think we ever map 2GB of on-demand-paging in one go, so this could probably be reduced to 1GB. The other 1GB could be used to increase the vmap. This would give us up to 1792MB of vmap.
> 
> Pending to the performance result, the global mapping could be a solution for arm32 as well.
Well.. OK.

>> Effects I can imagine, might be different:
>>   - New runstate area might be updated on Arm64, maybe partially and concurrently (IIRC, we have all the RAM permanently mapped to XEN)
> 
> Today the RAM is always permanently mapped, I can't promise this is going to be the case in the future.
> 
>>   - Paging fault might happen on Arm32
> 
> What do you mean?
Ouch... I did mean translation fault.

> 
>>   - Smth. similar or different might happen on x86 PV or HVM

>> Yet, all of them are out of design and are quite unexpected.
> We *must* protect hypervisor against any guest behavior.
Totally agree.

> Particularly the unexpected one. If the Android VM hit itself, then I pretty much don't care assuming the VM was misbehaving. However, I don't think anyone would be happy if the Android VM is able to take down the whole platform. At least, I would not want to be the passenger of that car...
Neither do I.

>>> You also saw a performance drop when using glmark2 benchmark.
>> Yes, I did see it with Roger's patch. But with mine - numbers are slightly better (~1%) for runstate being mapped. > Also introducing more races preventing code will introduce its impact.
> 
> Please provide the numbers once you fixed the race.
I'm laying my hands on the tracer now. Want to get numbers from it as well.

-- 
Sincerely,
Andrii Anisov.

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