From: Gavin Shan <gshan@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>, kvmarm@lists.cs.columbia.edu
Cc: maz@kernel.org, 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: Thu, 28 May 2020 16:14:52 +1000 [thread overview]
Message-ID: <a6addc25-29af-3690-8392-efa5e8381e98@redhat.com> (raw)
In-Reply-To: <81adf013-3de7-23e6-7648-8aec821b033c@redhat.com>
Hi Paolo,
On 5/27/20 4:48 PM, Paolo Bonzini wrote:
> I definitely appreciate the work, but this is repeating most of the
> mistakes done in the x86 implementation. In particular:
>
> - the page ready signal can be done as an interrupt, rather than an
> exception. This is because "page ready" can be handled asynchronously,
> in contrast to "page not present" which must be done on the same
> instruction that triggers it. You can refer to the recent series from
> Vitaly Kuznetsov that switched "page ready" to an interrupt.
>
Yeah, page ready can be handled asynchronously. I think it would be
nice for x86/arm64 to share same design. x86 has 256 vectors and it
seems 0xec is picked for the purpose. However, arm64 doesn't have so
many (interrupt/exception) vectors and PPI might be appropriate for
the purpose if I'm correct, because it has same INTD for all CPUs.
From this point, it's similar to x86's vector. There are 16 PPIs, which
are in range of 16 to 31, and we might reserve one for this. According
to GICv3/v4 spec, 22 - 30 have been assigned.
> - the page not present is reusing the memory abort exception, and
> there's really no reason to do so. I think it would be best if ARM
> could reserve one ESR exception code for the hypervisor. Mark, any
> ideas how to proceed here?
>
Well, a subclass of ESR exception code, whose DFSC (Data Fault Status
Code) is 0x34, was taken for the purpose in RFCv1. The code is IMPDEF
one and Mark suggested not to do so. I agree the page not present needs a
separately subclass of exception. With that, there will be less conflicts
and complexity. However, the question is which subclass or DFSC code I should
used for the purpose.
> - 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?
> - do not bother with using KVM_ASYNC_PF_SEND_ALWAYS, it's a fringe case
> that adds a lot of complexity.
>
Yeah, I don't consider it so far.
> Also, please include me on further iterations of the series.
>
Sure.
Thanks,
Gavin
[...]
next prev parent reply other threads:[~2020-05-28 6:15 UTC|newest]
Thread overview: 41+ 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 ` [PATCH RFCv2 1/9] arm64: Probe for the presence of KVM hypervisor services during boot 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 ` [PATCH RFCv2 3/9] kvm/arm64: Rename kvm_vcpu_get_hsr() to kvm_vcpu_get_esr() Gavin Shan
2020-05-26 10:42 ` Mark Rutland
2020-05-27 2:43 ` Gavin Shan
2020-05-27 7:20 ` Marc Zyngier
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-26 10:51 ` Mark Rutland
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-26 10:45 ` Mark Rutland
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-26 10:58 ` Mark Rutland
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-26 12:34 ` Mark Rutland
2020-05-27 4:05 ` Gavin Shan
2020-05-27 7:37 ` Marc Zyngier
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 ` [PATCH RFCv2 9/9] arm64: Support async page fault Gavin Shan
2020-05-26 12:56 ` Mark Rutland
2020-05-27 6:48 ` Paolo Bonzini
2020-05-28 6:14 ` Gavin Shan [this message]
2020-05-28 7:03 ` Marc Zyngier
2020-05-28 10:53 ` Paolo Bonzini
2020-05-28 10:48 ` Paolo Bonzini
2020-05-28 23:02 ` Gavin Shan
2020-05-29 9:41 ` Marc Zyngier
2020-05-29 11:11 ` Paolo Bonzini
2020-05-31 12:44 ` Marc Zyngier
2020-06-01 9:21 ` Paolo Bonzini
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-26 13:09 ` Mark Rutland
2020-05-27 2:39 ` Gavin Shan
2020-05-27 7:48 ` Marc Zyngier
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=a6addc25-29af-3690-8392-efa5e8381e98@redhat.com \
--to=gshan@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).