On 27/11/2018 19:40, Julien Grall wrote:
> (+ Stefano)
>
> On 11/27/18 5:12 PM, Volodymyr Babchuk wrote:
>> Hello community,
>
> Hi Volodymyr,
>
>>
>> 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
>
> The message is only printed in debug build. Do you have CONFIG_DEBUG
> enabled?
>
>>
>> Julien, I saw on mailing list, that you paid attention to issues with
>> gvirt_to_maddr,
>> so maybe you can be interested in this.
>
> Which thread are you speaking about? The problem is not because of
> gvirt_to_maddr but of how update_runstate_area is working at the moment.
>
> update_runstate_area is using a guest virtual address to update the
> vCPU runstate. It blindly assumes the vCPU runstate will always be
> mapped in stage-1 page-tables. However, if KPTI (Kernel Page Table
> Isolation) is enabled the kernel address space (and therefore the vCPU
> runstate) will not be mapped when running at EL0.
>
> So if you are restoring a vCPU that was executing code at EL0 then
> update_runstate_area will fail as the address is not mapped. There are
> a few solution suggested on the ML (see [1]). However I haven't had
> time to look at properly how to implement them.
>
> KPTI is getting used more widely (e.g meltdown and KASLR). So it would
> be good if we try to solve this problem sooner. I would be happy to
> review patches and/or provide advice if you want to tackle the problem.
>
> Cheers,
>
> [1] https://lists.xen.org/archives/html/xen-devel/2018-03/msg00223.html
>
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.
~Andrew
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
