[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xen-devel
Subject:    Re: [Xen-devel] RT Xen on ARM - R-Car series
From:       Julien Grall <julien.grall () arm ! com>
Date:       2019-01-31 23:14:37
Message-ID: 2a651c5d-3f94-378d-baf9-f52cab0cdc62 () arm ! com
[Download RAW message or body]

Hi Stefano,

On 1/31/19 9:56 PM, Stefano Stabellini wrote:
> On Thu, 31 Jan 2019, Julien Grall wrote:
>> On 31/01/2019 12:00, Andrii Anisov wrote:
>>> Hello Julien,
>>>
>>> On 31.01.19 13:37, Julien Grall wrote:
>>>>> On my side I just commented out that printk, because it renders a debug
>>>>> build unusable.
>>>>
>>>> ... if it is unusable, why don't you try to tackle the problem?
>>> Because of...
>>>
>>>> This is in my long ever growing list of things to
>>>
>>> ... be done.
>>>
>>> Some of things get solutions, some WAs.
>>
>> I can't see a good workaround for this. At some point someone would have to
>> pick it up rather than building a house of cards.
> 
> I ran into this problem as well not too long ago too. It is very
> annoying and it is basically impossible to work-around, the only thing
> possible would be to suppress the warning, but that doesn't even count
> as a work-around :-)

I am sure I will regret to have said that, but I will for fairness :).

If security is not a concern within the guest, then you can disable kpti 
(either via Kconfig or command line). All the errors should go away for 
Linux guest.

> 
> The way forward is to modify the existing
> VCPUOP_register_runstate_memory_area interface. I liked Julien's idea in
> https://lists.xenproject.org/archives/html/xen-devel/2018-03/msg00227.html:
> we don't necessarily need to change the parameters of the hypercalls
> from a guest virtual address to a guest physical address. It should be
> enough to convert the guest virtual address into a guest physical
> address in Xen when VCPUOP_register_runstate_memory_area is called
> (xen/common/domain.c:VCPUOP_register_runstate_memory_area), then store
> the guest physical address or its mapping in v->runstate_guest (the type
> of runstate_guest needs to change) and always use the guest physical
> address for future updates on the runstate memory area.

I would love to say it is that easy :). However, there are some research 
to do regarding how this is used by guests today. The hypercall is 
taking a virtual address, so technically it would be possible for a 
guest to pass a non page-aligned virtual address. So this would span 
onto two buffers (it seems to happen on older Linux).

Furthermore, because this is a virtual address, a guess would be free to 
modify the mapping at any time.

So if we want to use guest physical address in Xen, we need to know if 
it will not break any current guest. This would also probably needs to 
be documented in the interface.

With the current interface workaround, we are still playing with devil 
(see [2]). So it would be nice to get a new interface that does not use 
virtual address.

> 
> It doesn't seem too difficult.

Even with my comments above, I agree :).

Cheers,

[2] <9fa77816-a25c-c19b-cc26-e0d28cc2e160@citrix.com>



-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[prev in list] [next in list] [prev in thread] [next in thread]