linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Graf <graf@amazon.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Christoffer Dall" <christoffer.dall@arm.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Marc Zyngier" <maz@kernel.org>,
	"lkml - Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Heinrich Schuchardt" <xypron.glpk@gmx.de>,
	kvmarm@lists.cs.columbia.edu,
	arm-mail-list <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded
Date: Fri, 6 Sep 2019 16:12:51 +0200	[thread overview]
Message-ID: <f5af43d5-d8f6-58f1-bd25-909e4e94ddb0@amazon.com> (raw)
In-Reply-To: <CAFEAcA8HH-JeMLZ29h6GidDcLpb_oUHqoyEMJ0buo3hyTBj5jA@mail.gmail.com>



On 06.09.19 15:50, Peter Maydell wrote:
> On Fri, 6 Sep 2019 at 14:41, Alexander Graf <graf@amazon.com> wrote:
>> On 06.09.19 15:31, Peter Maydell wrote:
>>> (b) we try to reuse the code we already have that does TCG exception
>>> injection, which might or might not be a design mistake, and
>>
>> That's probably a design mistake, correct :)
> 
> Well, conceptually it's not necessarily a bad idea, because
> in both cases what we're doing is "change the system register
> state (PC, ESR_EL1, ELR_EL1 etc) so that the CPU looks like
> it's just taken an exception"; but some of what the
> TCG code needs to do isn't necessary for KVM and all of it
> was not written with the idea of KVM in mind at all...

Yes, and it probably makes sense to model the QEMU internal API 
similarly, so that exception generating code does not have to distinguish.

However, it's much easier for KVM to ensure exception prioritization as 
well as internal state synchronization. Conceptually, as you've seen, it 
really doesn't make a lot of sense to pull register state from KVM, 
wiggle it and then push it down when KVM has awareness of the same 
transformation anyway.

So I guess the path is clear: Create a generic interface for exception 
injection and a separate patch similar to what Christoffer already 
posted with the new CAP to route illegal MMIO traps into user space.

Connecting the two dots in user space really should be trivial then.

(famous last words)


Alex



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



  reply	other threads:[~2019-09-06 14:13 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-04 18:07 [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded Heinrich Schuchardt
2019-09-05  8:03 ` Marc Zyngier
2019-09-05  8:16   ` Peter Maydell
2019-09-05  8:25     ` Christoffer Dall
2019-09-05  8:32       ` Peter Maydell
2019-09-05  8:48     ` Heinrich Schuchardt
2019-09-05  8:52     ` Marc Zyngier
2019-09-05  8:56       ` Peter Maydell
2019-09-05  9:15         ` Marc Zyngier
2019-09-05  9:22         ` Christoffer Dall
2019-09-05 13:09           ` Marc Zyngier
2019-09-06  8:00             ` Christoffer Dall
2019-09-06 12:08               ` Alexander Graf
2019-09-06 12:34                 ` Marc Zyngier
2019-09-06 13:02                   ` [UNVERIFIED SENDER] " Alexander Graf
2019-09-06 13:12                 ` Christoffer Dall
2019-09-06 13:16                   ` Alexander Graf
2019-09-06 13:31                   ` Peter Maydell
2019-09-06 13:41                     ` Alexander Graf
2019-09-06 13:50                       ` Peter Maydell
2019-09-06 14:12                         ` Alexander Graf [this message]
2019-09-06 13:44                     ` Christoffer Dall
2019-09-05 13:25           ` Heinrich Schuchardt
2019-09-06  7:58             ` Christoffer Dall
2019-09-05  8:28   ` Heinrich Schuchardt
2019-09-05  9:11     ` Marc Zyngier
2019-09-05  9:20 ` Stefan Hajnoczi
2019-09-05  9:23   ` Daniel P. Berrangé
2019-09-05 12:01   ` Heinrich Schuchardt
2019-09-05 12:16     ` Christoffer Dall

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=f5af43d5-d8f6-58f1-bd25-909e4e94ddb0@amazon.com \
    --to=graf@amazon.com \
    --cc=berrange@redhat.com \
    --cc=christoffer.dall@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=peter.maydell@linaro.org \
    --cc=stefanha@redhat.com \
    --cc=xypron.glpk@gmx.de \
    /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).