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

[Andrii Anisov <andrii.anisov@xxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel