All of lore.kernel.org
 help / color / mirror / Atom feed
* [ARM] gvirt_to_maddr fails when DomU is created
@ 2018-11-27 17:12 Volodymyr Babchuk
  2018-11-27 19:40 ` Julien Grall
  0 siblings, 1 reply; 12+ messages in thread
From: Volodymyr Babchuk @ 2018-11-27 17:12 UTC (permalink / raw)
  To: xen-devel; +Cc: Julien Grall

Hello community,

After creating domU, I'm seeing lots of this messages from hypervisor:

(XEN) p2m.c:1442: d1v0: gvirt_to_maddr failed va=0xffff80000efc7f0f
flags=0x1 par=0x809
(XEN) p2m.c:1442: d1v0: gvirt_to_maddr failed va=0xffff80000efc7f00
flags=0x1 par=0x809
(XEN) p2m.c:1442: d1v0: gvirt_to_maddr failed va=0xffff80000efc7f0f
flags=0x1 par=0x809

Interestingly, I'm getting them from both Dom0 and DomU:

(XEN) p2m.c:1442: d0v0: gvirt_to_maddr failed va=0xffff80003efd7f0f
flags=0x1 par=0x809
(XEN) p2m.c:1442: d1v0: gvirt_to_maddr failed va=0xffff80000efc7f0f
flags=0x1 par=0x809

But only after DomU is created.

I attached GDB and found that this is caused by update_runstate_area:

(gdb) bt
#0  get_page_from_gva (v=0x80005dbe2000, v@entry=0x22f2c8 <schedule+1236>,
    va=va@entry=18446603337277996815, flags=flags@entry=1) at p2m.c:1440
#1  0x000000000024e320 in translate_get_page (write=true, linear=true,
addr=18446603337277996815,
    info=...) at guestcopy.c:37
#2  copy_guest (buf=buf@entry=0x80005dbe20d7,
addr=addr@entry=18446603337277996815, len=len@entry=1,
    info=..., flags=flags@entry=6) at guestcopy.c:69
#3  0x000000000024e45c in raw_copy_to_guest (to=to@entry=0xffff80003efd7f0f,
    from=from@entry=0x80005dbe20d7, len=len@entry=1) at guestcopy.c:110
#4  0x00000000002497b4 in update_runstate_area
(v=v@entry=0x80005dbe2000) at domain.c:287
#5  0x0000000000249eb8 in context_switch (prev=prev@entry=0x80005dbe2000,
    next=next@entry=0x80005bf3c000) at domain.c:344
#6  0x000000000022f2c8 in schedule () at schedule.c:1583
#7  0x0000000000232c10 in __do_softirq
(ignore_mask=ignore_mask@entry=0) at softirq.c:50
#8  0x0000000000232ca4 in do_softirq () at softirq.c:64
#9  0x0000000000258254 in leave_hypervisor_tail () at traps.c:2302

This issue is encountered on QEMU-ARMv8. Dom0 kernel is Linux 4.19.0
My XEN master is at d8ffac1f7 "xen/arm: gic: Remove duplicated comment
in do_sgi"

The same setup worked perfectly with Xen 4.10.2

Julien, I saw on mailing list, that you paid attention to issues with
gvirt_to_maddr,
so maybe you can be interested in this.

-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babchuk@gmail.com

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

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [ARM] gvirt_to_maddr fails when DomU is created
@ 2018-11-29  9:51 Juergen Gross
  0 siblings, 0 replies; 12+ messages in thread
From: Juergen Gross @ 2018-11-29  9:51 UTC (permalink / raw)
  To: Jan Beulich, Andrew Cooper
  Cc: vlad.babchuk, xen-devel, Julien Grall, Stefano Stabellini,
	Boris Ostrovsky

On 29/11/2018 10:39, Jan Beulich wrote:
>>>> On 28.11.18 at 01:05, <andrew.cooper3@citrix.com> wrote:
>> update_runstate_area() using a virtual address is a complete misfeature,
>> and the sooner we can replace it, the better.  It's history is with x86
>> PV guests, where the early ABIs were designed in terms of Linux's
>> copy_{to,from}_user().
>>
>> It is similarly broken in x86 with meltdown mitigations, as well as SMAP
>> considerations (PAN in ARM, iirc).
>>
>> We've got two options.  Invent a new API which takes a gfn/gaddr, or
>> retrofit the API to be "you pass a virtual address, we translate to
>> gfn/gaddr, then update that".  Perhaps both.
>>
>> When this was last discussed, I think the "onetime translate to
>> gfn/gaddr" was a good enough compatibility to cope with existing guests,
>> but that we should have a more clean way for modern guests.
> 
> I don't think a one-time translate can be a replacement without
> the guest giving its consent, at which point the guest could as
> well be switched to whatever the replacement interface is going
> to be. Aiui (the introduction of the functionality predating my
> involvement with Xen) the original idea was that guests would
> specifically be allowed to context switch the mapping of the
> involved linear address.
> 
> Furthermore for x86-64 guests we already have logic to deal
> with the case where there is no present mapping at the time
> the write is to occur, as that's a common situation with x86-64
> guest user mode running with kernel page tables removed.
> For x86-32 guests with Meltdown mitigation in place something
> similar might indeed be needed. Whether something like this is
> doable on ARM depends on whether Xen has a way to know
> at which point missing mappings re-appear.

In any case we want some interface using gfn/gaddr for performance
reasons: Always having to do a vaddr->gaddr translation is expensive
(especially for HVM/PVH and probably on ARM, too), so we should try to
avoid that.


Juergen

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

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [ARM] gvirt_to_maddr fails when DomU is created
@ 2018-11-29 11:22 Julien Grall
  0 siblings, 0 replies; 12+ messages in thread
From: Julien Grall @ 2018-11-29 11:22 UTC (permalink / raw)
  To: Juergen Gross, Jan Beulich, Andrew Cooper
  Cc: vlad.babchuk, xen-devel, Boris Ostrovsky, Stefano Stabellini

Hi Juergen,

I have noticed on the last few threads that your e-mails don't get threaded
correctly. Looking at the source, I can't find the In-Reply-To tag. Do you have 
any issue with your e-mail?

On 29/11/2018 09:51, Juergen Gross wrote:
> On 29/11/2018 10:39, Jan Beulich wrote:
>>>>> On 28.11.18 at 01:05, <andrew.cooper3@citrix.com> wrote:
>>> update_runstate_area() using a virtual address is a complete misfeature,
>>> and the sooner we can replace it, the better.  It's history is with x86
>>> PV guests, where the early ABIs were designed in terms of Linux's
>>> copy_{to,from}_user().
>>>
>>> It is similarly broken in x86 with meltdown mitigations, as well as SMAP
>>> considerations (PAN in ARM, iirc).
>>>
>>> We've got two options.  Invent a new API which takes a gfn/gaddr, or
>>> retrofit the API to be "you pass a virtual address, we translate to
>>> gfn/gaddr, then update that".  Perhaps both.
>>>
>>> When this was last discussed, I think the "onetime translate to
>>> gfn/gaddr" was a good enough compatibility to cope with existing guests,
>>> but that we should have a more clean way for modern guests.
>>
>> I don't think a one-time translate can be a replacement without
>> the guest giving its consent, at which point the guest could as
>> well be switched to whatever the replacement interface is going
>> to be. Aiui (the introduction of the functionality predating my
>> involvement with Xen) the original idea was that guests would
>> specifically be allowed to context switch the mapping of the
>> involved linear address.
>>
>> Furthermore for x86-64 guests we already have logic to deal
>> with the case where there is no present mapping at the time
>> the write is to occur, as that's a common situation with x86-64
>> guest user mode running with kernel page tables removed.
>> For x86-32 guests with Meltdown mitigation in place something
>> similar might indeed be needed. Whether something like this is
>> doable on ARM depends on whether Xen has a way to know
>> at which point missing mappings re-appear.
> 
> In any case we want some interface using gfn/gaddr for performance
> reasons: Always having to do a vaddr->gaddr translation is expensive
> (especially for HVM/PVH and probably on ARM, too), so we should try to
> avoid that.

On Arm, performance is one of the reason, but not the main one. Using Virtual 
Address is by default unreliable as you have no way to prevent the guest to play 
with its page-tables. For instance, Arm requires to go through an invalid state 
when updating the page-tables entry under certain condition (e.g superpage <-> 
small mapping).

The long-term goal is to use guest physical address for all hypercalls rather 
than guest virtual address.

Cheers,

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 12+ messages in thread
end of thread, other threads:[~2018-11-29 11:22 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-27 17:12 [ARM] gvirt_to_maddr fails when DomU is created Volodymyr Babchuk
2018-11-27 19:40 ` Julien Grall
2018-11-27 22:43   ` Stefano Stabellini
2018-11-28  0:05   ` Andrew Cooper
2018-11-28  0:21     ` Andrew Cooper
2018-11-29  9:39     ` Jan Beulich
2018-11-29 10:03       ` Andrew Cooper
2018-11-29 10:12         ` Jan Beulich
2018-11-28 18:10   ` Volodymyr Babchuk
2018-11-28 21:31     ` Julien Grall
2018-11-29  9:51 Juergen Gross
2018-11-29 11:22 Julien Grall

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.