From: Julien Grall <julien.grall@arm.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xen.org, "LOPEZ,
FUENTES NACARINO Jairo Eduardo" <jairo@ruri.waseda.jp>,
Andrii Anisov <andrii.anisov@gmail.com>
Subject: Re: RT Xen on ARM - R-Car series
Date: Thu, 31 Jan 2019 23:14:37 +0000 [thread overview]
Message-ID: <2a651c5d-3f94-378d-baf9-f52cab0cdc62@arm.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1901311345570.22962@sstabellini-ThinkPad-X260>
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
next prev parent reply other threads:[~2019-01-31 23:14 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CACrvCsaeHuwzZzUQTzNYF7fqmgQWNJUVOQZv9D0MnYrXjqzZtQ@mail.gmail.com>
2018-12-22 12:21 ` RT Xen on ARM - R-Car series Andrii Anisov
2018-12-25 16:07 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
2018-12-27 11:07 ` Andrii Anisov
2018-12-28 15:22 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
2018-12-28 8:28 ` Andrii Anisov
2018-12-28 8:32 ` Andrii Anisov
2018-12-28 8:39 ` Andrii Anisov
2019-01-04 9:09 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
2019-01-08 17:04 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
2019-01-11 20:12 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
2019-01-14 8:42 ` Andrii Anisov
2019-01-16 7:53 ` Andrii Anisov
2019-01-21 18:04 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
[not found] ` <CACrvCsZB-tps6=Vr=1Phf5oo5eUReabMLJzkbO3d2hmNLDOxww@mail.gmail.com>
[not found] ` <7e217489-2c1a-c35f-d51f-0969654aa8cc@gmail.com>
[not found] ` <CACrvCsaYJ-zGkZwfdV7BXDABW8u_EDQetU3pq+2otRGXWTXagw@mail.gmail.com>
[not found] ` <4d078801-b804-06e7-ad5c-8032b1dbaa84@gmail.com>
2019-01-28 17:20 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
2019-01-28 8:25 ` Andrii Anisov
2019-01-29 15:30 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
2019-01-29 13:29 ` Andrii Anisov
2019-01-30 20:23 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
2019-01-30 12:12 ` Julien Grall
2019-01-31 11:22 ` Andrii Anisov
2019-01-31 11:37 ` Julien Grall
2019-01-31 12:00 ` Andrii Anisov
2019-01-31 12:20 ` Julien Grall
2019-01-31 21:56 ` Stefano Stabellini
2019-01-31 23:14 ` Julien Grall [this message]
2019-02-01 10:02 ` Andrii Anisov
2019-02-01 10:12 ` Julien Grall
2019-02-01 10:35 ` Andrii Anisov
2019-02-01 11:06 ` Julien Grall
2019-02-01 16:53 ` Roger Pau Monné
2019-02-01 17:40 ` Julien Grall
2019-02-04 10:28 ` Andrii Anisov
2019-02-04 11:21 ` Julien Grall
2019-02-04 14:46 ` Andrii Anisov
2019-02-04 15:05 ` Julien Grall
2019-02-04 12:53 ` Roger Pau Monné
2019-02-04 21:58 ` Julien Grall
2019-02-05 8:40 ` Andrii Anisov
2019-02-05 9:45 ` Roger Pau Monné
2019-02-05 9:54 ` Andrii Anisov
2019-02-05 10:10 ` Roger Pau Monné
2019-02-06 20:20 ` Andrii Anisov
2019-02-06 21:03 ` Stefano Stabellini
2019-02-07 9:42 ` Andrii Anisov
2019-02-07 10:35 ` Roger Pau Monné
2019-02-07 10:59 ` Julien Grall
2019-02-12 18:21 ` Andrii Anisov
2019-02-12 19:21 ` Julien Grall
2019-02-14 14:18 ` Andrii Anisov
2019-02-14 17:29 ` Julien Grall
2019-02-15 11:30 ` Andrii Anisov
2019-02-15 17:13 ` Julien Grall
2019-02-15 17:41 ` Andrii Anisov
2019-02-16 8:42 ` Julien Grall
2019-02-12 18:21 ` Andrii Anisov
2019-02-14 16:29 ` Roger Pau Monné
2019-02-15 15:21 ` Andrii Anisov
2019-02-15 16:31 ` Julien Grall
2019-02-15 17:30 ` Andrii Anisov
2019-02-15 18:36 ` Julien Grall
2019-02-14 17:08 ` Julien Grall
2019-02-05 9:26 ` Roger Pau Monné
2019-02-01 10:07 ` Andrii Anisov
2019-02-01 10:16 ` Julien Grall
2019-02-01 10:35 ` Andrii Anisov
2019-02-01 10:51 ` Julien Grall
2019-02-01 18:00 ` Stefano Stabellini
2019-02-04 10:32 ` Andrii Anisov
2019-02-04 11:36 ` Julien Grall
2019-02-04 15:19 ` Andrii Anisov
2019-02-04 22:06 ` Julien Grall
2019-02-05 9:01 ` Andrii Anisov
2019-02-05 19:18 ` Stefano Stabellini
2019-02-07 10:53 ` Andrii Anisov
[not found] ` <CACrvCsbkFG=3To83qi7xxmtmgC_9PKvuLz73edhiaV7TsJAZqQ@mail.gmail.com>
2019-01-31 12:24 ` Julien Grall
2019-01-16 20:46 ` Andrii Anisov
2019-01-16 7:40 ` Andrii Anisov
2019-01-17 2:08 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
2018-12-28 17:35 ` LOPEZ, FUENTES NACARINO Jairo Eduardo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2a651c5d-3f94-378d-baf9-f52cab0cdc62@arm.com \
--to=julien.grall@arm.com \
--cc=andrii.anisov@gmail.com \
--cc=jairo@ruri.waseda.jp \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.