All of lore.kernel.org
 help / color / mirror / Atom feed
From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] KVM: ARM: ignore guest L2 cache control SMCs on Highbank and OMAP
Date: Wed, 14 Aug 2013 10:18:54 -0700	[thread overview]
Message-ID: <20130814171854.GA11390@cbox> (raw)
In-Reply-To: <abf9b3ef779ce43b1912bf9e3deea522@www.loen.fr>

On Wed, Aug 14, 2013 at 11:30:03AM +0100, Marc Zyngier wrote:
> On 2013-08-14 11:22, Peter Maydell wrote:
> > On 14 August 2013 10:32, Marc Zyngier <marc.zyngier@arm.com> wrote:
> >> On 2013-08-14 10:22, Andre Przywara wrote:
> >
> >>> +static int kvm_ignore_l2x0_call(struct kvm_vcpu *vcpu)
> >>> +{
> >>> +     unsigned long fn_nr = *vcpu_reg(vcpu, 12) & ~((u32) 0);
> >>> +
> >>> +     if (fn_nr == 0x102) {
> >>> +             kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
> >>> +             return 1;
> >>> +     }
> >>> +
> >>> +     return 0;
> >>> +}
> >>
> >> And what if I run mach-foo which uses r12 to request bar services 
> >> from
> >> secure mode? Is it safe to ignore it? We need something much better 
> >> than
> >> just testing random registers to guess what the guest wants.
> >
> > Definitely. This needs to be addressed via the kernel providing
> > some mechanism so that userspace and/or a KVM-specific bit
> > of 'firmware' running in the guest VM can handle the SMC
> > calls the guest tries to make, because it's totally board
> > specific.
> 
> Right. We're in violent agreement here.
> 
> What I can imagine is some kind of feature bit that would cause an exit 
> all the way to userspace, letting QEMU handle the call.
> 
> That would be simple enough to implement, I believe. At least on the 
> kernel side.
> 
How would we distinguish between a PSCI call that the kernel should
support and a call to secure firmware that needs to be forwarded to
QEMU?  Is this simply a binary config at VM creation time?

-Christoffer

  reply	other threads:[~2013-08-14 17:18 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-14  9:22 [PATCH] KVM: ARM: ignore guest L2 cache control SMCs on Highbank and OMAP Andre Przywara
2013-08-14  9:32 ` Marc Zyngier
2013-08-14  9:39   ` Andre Przywara
2013-08-14 10:22     ` Marc Zyngier
2013-08-14 10:41     ` Dave Martin
2013-08-14 17:21       ` Christoffer Dall
2013-08-14 10:22   ` Peter Maydell
2013-08-14 10:30     ` Marc Zyngier
2013-08-14 17:18       ` Christoffer Dall [this message]
2013-08-14 18:01         ` Peter Maydell
2013-08-14 18:13           ` Christoffer Dall
2013-08-14 18:22             ` Peter Maydell
2013-08-14 18:36               ` Christoffer Dall
2013-08-14 18:54 ` Rob Herring
2013-08-14 20:20   ` Andre Przywara
2013-08-14 20:43     ` Christoffer Dall
2013-08-14 22:05       ` Andre Przywara
2013-08-14 23:31         ` Christoffer Dall
2013-08-15  8:51       ` Peter Maydell

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=20130814171854.GA11390@cbox \
    --to=christoffer.dall@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.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.