Re: [Xen-devel] RT Xen on ARM - R-Car series

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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 :-)

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.

It doesn't seem too difficult.

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