From: Marc Zyngier <maz@kernel.org>
To: Gavin Shan <gshan@redhat.com>
Cc: catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
shan.gavin@gmail.com, Paolo Bonzini <pbonzini@redhat.com>,
will@kernel.org, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFCv2 9/9] arm64: Support async page fault
Date: Fri, 29 May 2020 10:41:44 +0100 [thread overview]
Message-ID: <6965aaf641a23fab64fbe2ceeb790272@kernel.org> (raw)
In-Reply-To: <6a4a82a4-af01-98c2-c854-9199f55f7bd3@redhat.com>
On 2020-05-29 00:02, Gavin Shan wrote:
> Hi Paolo,
>
> On 5/28/20 8:48 PM, Paolo Bonzini wrote:
>> On 28/05/20 08:14, Gavin Shan wrote:
>>>> - for x86 we're also thinking of initiating the page fault from the
>>>> exception handler, rather than doing so from the hypervisor before
>>>> injecting the exception. If ARM leads the way here, we would do our
>>>> best to share code when x86 does the same.
>>>
>>> Sorry, Paolo, I don't follow your idea here. Could you please provide
>>> more details?
>>
>> The idea is to inject stage2 page faults into the guest even before
>> the
>> host starts populates the page. The guest then invokes a hypercall,
>> telling the host to populate the page table and inject the 'page
>> ready'
>> event (interrupt) when it's done.
>>
>> For x86 the advantage is that the processor can take care of raising
>> the
>> stage2 page fault in the guest, so it's faster.
>>
> I think there might be too much overhead if the page can be populated
> quickly by host. For example, it's fast to populate the pages if swapin
> isn't involved.
>
> If I'm correct enough, it seems arm64 doesn't have similar mechanism,
> routing stage2 page fault to guest.
Indeed, this isn't a thing on arm64. Exception caused by a S2 fault are
always routed to EL2.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Gavin Shan <gshan@redhat.com>
Cc: catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
shan.gavin@gmail.com, Paolo Bonzini <pbonzini@redhat.com>,
will@kernel.org, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFCv2 9/9] arm64: Support async page fault
Date: Fri, 29 May 2020 10:41:44 +0100 [thread overview]
Message-ID: <6965aaf641a23fab64fbe2ceeb790272@kernel.org> (raw)
In-Reply-To: <6a4a82a4-af01-98c2-c854-9199f55f7bd3@redhat.com>
On 2020-05-29 00:02, Gavin Shan wrote:
> Hi Paolo,
>
> On 5/28/20 8:48 PM, Paolo Bonzini wrote:
>> On 28/05/20 08:14, Gavin Shan wrote:
>>>> - for x86 we're also thinking of initiating the page fault from the
>>>> exception handler, rather than doing so from the hypervisor before
>>>> injecting the exception. If ARM leads the way here, we would do our
>>>> best to share code when x86 does the same.
>>>
>>> Sorry, Paolo, I don't follow your idea here. Could you please provide
>>> more details?
>>
>> The idea is to inject stage2 page faults into the guest even before
>> the
>> host starts populates the page. The guest then invokes a hypercall,
>> telling the host to populate the page table and inject the 'page
>> ready'
>> event (interrupt) when it's done.
>>
>> For x86 the advantage is that the processor can take care of raising
>> the
>> stage2 page fault in the guest, so it's faster.
>>
> I think there might be too much overhead if the page can be populated
> quickly by host. For example, it's fast to populate the pages if swapin
> isn't involved.
>
> If I'm correct enough, it seems arm64 doesn't have similar mechanism,
> routing stage2 page fault to guest.
Indeed, this isn't a thing on arm64. Exception caused by a S2 fault are
always routed to EL2.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Gavin Shan <gshan@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
shan.gavin@gmail.com, catalin.marinas@arm.com, will@kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFCv2 9/9] arm64: Support async page fault
Date: Fri, 29 May 2020 10:41:44 +0100 [thread overview]
Message-ID: <6965aaf641a23fab64fbe2ceeb790272@kernel.org> (raw)
In-Reply-To: <6a4a82a4-af01-98c2-c854-9199f55f7bd3@redhat.com>
On 2020-05-29 00:02, Gavin Shan wrote:
> Hi Paolo,
>
> On 5/28/20 8:48 PM, Paolo Bonzini wrote:
>> On 28/05/20 08:14, Gavin Shan wrote:
>>>> - for x86 we're also thinking of initiating the page fault from the
>>>> exception handler, rather than doing so from the hypervisor before
>>>> injecting the exception. If ARM leads the way here, we would do our
>>>> best to share code when x86 does the same.
>>>
>>> Sorry, Paolo, I don't follow your idea here. Could you please provide
>>> more details?
>>
>> The idea is to inject stage2 page faults into the guest even before
>> the
>> host starts populates the page. The guest then invokes a hypercall,
>> telling the host to populate the page table and inject the 'page
>> ready'
>> event (interrupt) when it's done.
>>
>> For x86 the advantage is that the processor can take care of raising
>> the
>> stage2 page fault in the guest, so it's faster.
>>
> I think there might be too much overhead if the page can be populated
> quickly by host. For example, it's fast to populate the pages if swapin
> isn't involved.
>
> If I'm correct enough, it seems arm64 doesn't have similar mechanism,
> routing stage2 page fault to guest.
Indeed, this isn't a thing on arm64. Exception caused by a S2 fault are
always routed to EL2.
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2020-05-29 9:41 UTC|newest]
Thread overview: 123+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-08 3:29 [PATCH RFCv2 0/9] kvm/arm64: Support Async Page Fault Gavin Shan
2020-05-08 3:29 ` Gavin Shan
2020-05-08 3:29 ` Gavin Shan
2020-05-08 3:29 ` [PATCH RFCv2 1/9] arm64: Probe for the presence of KVM hypervisor services during boot Gavin Shan
2020-05-08 3:29 ` Gavin Shan
2020-05-08 3:29 ` Gavin Shan
2020-05-08 3:29 ` [PATCH RFCv2 2/9] arm/arm64: KVM: Advertise KVM UID to guests via SMCCC Gavin Shan
2020-05-08 3:29 ` Gavin Shan
2020-05-08 3:29 ` Gavin Shan
2020-05-08 3:29 ` [PATCH RFCv2 3/9] kvm/arm64: Rename kvm_vcpu_get_hsr() to kvm_vcpu_get_esr() Gavin Shan
2020-05-08 3:29 ` Gavin Shan
2020-05-08 3:29 ` Gavin Shan
2020-05-26 10:42 ` Mark Rutland
2020-05-26 10:42 ` Mark Rutland
2020-05-26 10:42 ` Mark Rutland
2020-05-27 2:43 ` Gavin Shan
2020-05-27 2:43 ` Gavin Shan
2020-05-27 2:43 ` Gavin Shan
2020-05-27 7:20 ` Marc Zyngier
2020-05-27 7:20 ` Marc Zyngier
2020-05-27 7:20 ` Marc Zyngier
2020-05-28 6:34 ` Gavin Shan
2020-05-28 6:34 ` Gavin Shan
2020-05-28 6:34 ` Gavin Shan
2020-05-08 3:29 ` [PATCH RFCv2 4/9] kvm/arm64: Detach ESR operator from vCPU struct Gavin Shan
2020-05-08 3:29 ` Gavin Shan
2020-05-08 3:29 ` Gavin Shan
2020-05-26 10:51 ` Mark Rutland
2020-05-26 10:51 ` Mark Rutland
2020-05-26 10:51 ` Mark Rutland
2020-05-27 2:55 ` Gavin Shan
2020-05-27 2:55 ` Gavin Shan
2020-05-27 2:55 ` Gavin Shan
2020-05-08 3:29 ` [PATCH RFCv2 5/9] kvm/arm64: Replace hsr with esr Gavin Shan
2020-05-08 3:29 ` Gavin Shan
2020-05-08 3:29 ` Gavin Shan
2020-05-26 10:45 ` Mark Rutland
2020-05-26 10:45 ` Mark Rutland
2020-05-26 10:45 ` Mark Rutland
2020-05-27 2:56 ` Gavin Shan
2020-05-27 2:56 ` Gavin Shan
2020-05-27 2:56 ` Gavin Shan
2020-05-08 3:29 ` [PATCH RFCv2 6/9] kvm/arm64: Export kvm_handle_user_mem_abort() with prefault mode Gavin Shan
2020-05-08 3:29 ` Gavin Shan
2020-05-08 3:29 ` Gavin Shan
2020-05-26 10:58 ` Mark Rutland
2020-05-26 10:58 ` Mark Rutland
2020-05-26 10:58 ` Mark Rutland
2020-05-27 3:01 ` Gavin Shan
2020-05-27 3:01 ` Gavin Shan
2020-05-27 3:01 ` Gavin Shan
2020-05-08 3:29 ` [PATCH RFCv2 7/9] kvm/arm64: Support async page fault Gavin Shan
2020-05-08 3:29 ` Gavin Shan
2020-05-08 3:29 ` Gavin Shan
2020-05-26 12:34 ` Mark Rutland
2020-05-26 12:34 ` Mark Rutland
2020-05-26 12:34 ` Mark Rutland
2020-05-27 4:05 ` Gavin Shan
2020-05-27 4:05 ` Gavin Shan
2020-05-27 4:05 ` Gavin Shan
2020-05-27 7:37 ` Marc Zyngier
2020-05-27 7:37 ` Marc Zyngier
2020-05-27 7:37 ` Marc Zyngier
2020-05-28 6:32 ` Gavin Shan
2020-05-28 6:32 ` Gavin Shan
2020-05-28 6:32 ` Gavin Shan
2020-05-08 3:29 ` [PATCH RFCv2 8/9] kernel/sched: Add cpu_rq_is_locked() Gavin Shan
2020-05-08 3:29 ` Gavin Shan
2020-05-08 3:29 ` Gavin Shan
2020-05-08 3:29 ` [PATCH RFCv2 9/9] arm64: Support async page fault Gavin Shan
2020-05-08 3:29 ` Gavin Shan
2020-05-08 3:29 ` Gavin Shan
2020-05-26 12:56 ` Mark Rutland
2020-05-26 12:56 ` Mark Rutland
2020-05-26 12:56 ` Mark Rutland
2020-05-27 6:48 ` Paolo Bonzini
2020-05-27 6:48 ` Paolo Bonzini
2020-05-27 6:48 ` Paolo Bonzini
2020-05-28 6:14 ` Gavin Shan
2020-05-28 6:14 ` Gavin Shan
2020-05-28 6:14 ` Gavin Shan
2020-05-28 7:03 ` Marc Zyngier
2020-05-28 7:03 ` Marc Zyngier
2020-05-28 7:03 ` Marc Zyngier
2020-05-28 10:53 ` Paolo Bonzini
2020-05-28 10:53 ` Paolo Bonzini
2020-05-28 10:53 ` Paolo Bonzini
2020-05-28 10:48 ` Paolo Bonzini
2020-05-28 10:48 ` Paolo Bonzini
2020-05-28 10:48 ` Paolo Bonzini
2020-05-28 23:02 ` Gavin Shan
2020-05-28 23:02 ` Gavin Shan
2020-05-28 23:02 ` Gavin Shan
2020-05-29 9:41 ` Marc Zyngier [this message]
2020-05-29 9:41 ` Marc Zyngier
2020-05-29 9:41 ` Marc Zyngier
2020-05-29 11:11 ` Paolo Bonzini
2020-05-29 11:11 ` Paolo Bonzini
2020-05-29 11:11 ` Paolo Bonzini
2020-05-31 12:44 ` Marc Zyngier
2020-05-31 12:44 ` Marc Zyngier
2020-05-31 12:44 ` Marc Zyngier
2020-06-01 9:21 ` Paolo Bonzini
2020-06-01 9:21 ` Paolo Bonzini
2020-06-01 9:21 ` Paolo Bonzini
2020-06-02 5:44 ` Gavin Shan
2020-06-02 5:44 ` Gavin Shan
2020-06-02 5:44 ` Gavin Shan
2020-05-25 23:39 ` [PATCH RFCv2 0/9] kvm/arm64: Support Async Page Fault Gavin Shan
2020-05-25 23:39 ` Gavin Shan
2020-05-25 23:39 ` Gavin Shan
2020-05-26 13:09 ` Mark Rutland
2020-05-26 13:09 ` Mark Rutland
2020-05-26 13:09 ` Mark Rutland
2020-05-27 2:39 ` Gavin Shan
2020-05-27 2:39 ` Gavin Shan
2020-05-27 2:39 ` Gavin Shan
2020-05-27 7:48 ` Marc Zyngier
2020-05-27 7:48 ` Marc Zyngier
2020-05-27 7:48 ` Marc Zyngier
2020-05-27 16:10 ` Paolo Bonzini
2020-05-27 16:10 ` Paolo Bonzini
2020-05-27 16:10 ` Paolo Bonzini
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=6965aaf641a23fab64fbe2ceeb790272@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=gshan@redhat.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=shan.gavin@gmail.com \
--cc=will@kernel.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.