Hi Marc,
On 2020/3/20 17:01, Marc Zyngier wrote:
Hi Zenghui,
On 2020-03-20 03:53, Zenghui Yu wrote:
Hi Marc,
On 2020/3/19 20:10, Marc Zyngier wrote:
But I wonder that should we use nassgireq to *only* keep track what
the guest had written into the GICD_CTLR.nASSGIreq. If not, we may
lose
On 2020-03-23 08:22, Lev Aronsky wrote:
On Sun, Mar 22, 2020 at 05:29:52PM +, Marc Zyngier wrote:
On 2020-03-22 14:20, Lev Aronsky wrote:
> On Sun, Mar 22, 2020 at 11:34:35AM +, Marc Zyngier wrote:
> > Hi Lev,
> >
> > Thanks for this.
> >
> > On 2020-03-22 09:36, aron...@gmail.com
On Mon, Mar 23, 2020 at 09:07:12AM +, Marc Zyngier wrote:
> On 2020-03-23 08:22, Lev Aronsky wrote:
> > On Sun, Mar 22, 2020 at 05:29:52PM +, Marc Zyngier wrote:
> > > On 2020-03-22 14:20, Lev Aronsky wrote:
> > > > On Sun, Mar 22, 2020 at 11:34:35AM +, Marc Zyngier wrote:
> > > > > Hi
Hi Zenghui,
[...]
And actually, maybe we can handle that pretty cheaply. If userspace
tries to restore GICD_TYPER2 to a value that isn't what KVM can
offer, we just return an error. Exactly like we do for GICD_IIDR.
Hence the following patch:
diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c
On Sun, Mar 22, 2020 at 05:29:52PM +, Marc Zyngier wrote:
> On 2020-03-22 14:20, Lev Aronsky wrote:
> > On Sun, Mar 22, 2020 at 11:34:35AM +, Marc Zyngier wrote:
> > > Hi Lev,
> > >
> > > Thanks for this.
> > >
> > > On 2020-03-22 09:36, aron...@gmail.com wrote:
> > > > From: Lev Aronsky
On 2020-03-23 09:41, Lev Aronsky wrote:
On Mon, Mar 23, 2020 at 09:07:12AM +, Marc Zyngier wrote:
On 2020-03-23 08:22, Lev Aronsky wrote:
[...]
> We're running it on an ARM cloud server (we were hoping to be able to
> use SBCs for the project, but iOS uses 16K pages for kernel mode, and
Some of the ARMv7 & ARMv8 load/store instructions might trigger a data abort
exception with no valid ISS info to be decoded. The lack of decode info
makes it at least tricky to emulate the instruction which is one of the
(many) reasons why KVM will not even try to do so.
So far, if a guest made
Injecting external data abort through KVM might trigger
an issue on kernels that do not get updated to include the KVM fix.
For those and aarch32 guests, the injected abort gets misconfigured
to be an implementation defined exception. This leads to the guest
repeatedly re-running the faulting
On ARMv7 & ARMv8 some load/store instructions might trigger a data abort
exception with no valid ISS info to be decoded. The lack of decode info
makes it at least tricky to emulate those instruction which is one of the
(many) reasons why KVM will not even try to do so.
Add support for handling
On Mon, Mar 23, 2020 at 11:32:26AM +, Beata Michalska wrote:
> On ARMv7 & ARMv8 some load/store instructions might trigger a data abort
> exception with no valid ISS info to be decoded. The lack of decode info
> makes it at least tricky to emulate those instruction which is one of the
> (many)
On Mon, Mar 23, 2020 at 10:26:18AM +, Marc Zyngier wrote:
> On 2020-03-23 09:41, Lev Aronsky wrote:
> > On Mon, Mar 23, 2020 at 09:07:12AM +, Marc Zyngier wrote:
> > > On 2020-03-23 08:22, Lev Aronsky wrote:
[...]
> > >
> > > I'm pretty sure this wouldn't work with HW virtualization. I
Hi Marc,
On 2020/3/23 16:25, Marc Zyngier wrote:
Hi Zenghui,
[...]
And actually, maybe we can handle that pretty cheaply. If userspace
tries to restore GICD_TYPER2 to a value that isn't what KVM can
offer, we just return an error. Exactly like we do for GICD_IIDR.
Hence the following patch:
On Mon, Mar 23, 2020 at 01:10:40PM +0100, Vitaly Kuznetsov wrote:
> Sean Christopherson writes:
>
> > +
> > + .runtime_ops = _x86_ops,
> > +};
>
> Unrelated to your patch but I think we can make the naming of some of
> these functions more consistend on SVM/VMX, in particular I'd suggest
>
Sean Christopherson writes:
> Move the kvm_x86_ops functions that are used only within the scope of
> kvm_init() into a separate struct, kvm_x86_init_ops. In addition to
> identifying the init-only functions without restorting to code comments,
> this also sets the stage for waiting until after
Sean Christopherson writes:
> Move VMX's hardware_setup() below its vmx_x86_ops definition so that a
> future patch can refactor hardware_setup() to modify vmx_x86_ops
> directly instead of indirectly modifying the ops via the global
> kvm_x86_ops.
>
> No functional change intended.
>
>
On Mon, Mar 23, 2020 at 01:44:46PM +0100, Vitaly Kuznetsov wrote:
> (OK, I have to admit I trust the fact that GCC is still able to build
> KVM modules more than my own eyes)
Ha, yep, I trust gcc far more than my grep skills.
___
kvmarm mailing list
Sean Christopherson writes:
> Replace the kvm_x86_ops pointer in common x86 with an instance of the
> struct to save one memory instance when invoking function. Copy the
> struct by value to set the ops during kvm_init().
>
> Arbitrarily use kvm_x86_ops.hardware_enable to track whether or not
Sean Christopherson writes:
> Configure VMX's runtime hooks by modifying vmx_x86_ops directly instead
> of using the global kvm_x86_ops. This sets the stage for waiting until
> after ->hardware_setup() to set kvm_x86_ops with the vendor's
> implementation.
>
> Signed-off-by: Sean Christopherson
Sean Christopherson writes:
> Tag svm_x86_ops with __initdata now the the struct is copied by value to
Same typo, "now that the struct".
> a common x86 instance of kvm_x86_ops as part of kvm_init().
>
> Signed-off-by: Sean Christopherson
> ---
> arch/x86/kvm/svm.c | 2 +-
> 1 file changed, 1
Sean Christopherson writes:
> Remove the __exit annotation from VMX hardware_unsetup(), the hook
> can be reached during kvm_init() by way of kvm_arch_hardware_unsetup()
> if failure occurs at various points during initialization.
>
> Note, there is no known functional issue with the __exit
Sean Christopherson writes:
> Tag vmx_x86_ops with __initdata now the the struct is copied by value
Typo, "now that the struct".
> to a common x86 instance of kvm_x86_ops as part of kvm_init().
>
> Signed-off-by: Sean Christopherson
> ---
> arch/x86/kvm/vmx/vmx.c | 2 +-
> 1 file changed, 1
On Mon, Mar 23, 2020 at 01:27:28PM +0100, Vitaly Kuznetsov wrote:
> Sean Christopherson writes:
>
> > Configure VMX's runtime hooks by modifying vmx_x86_ops directly instead
> > of using the global kvm_x86_ops. This sets the stage for waiting until
> > after ->hardware_setup() to set
On Mon, Mar 23, 2020 at 05:24:56PM +0100, Vitaly Kuznetsov wrote:
> Sean Christopherson writes:
>
> > On Mon, Mar 23, 2020 at 01:10:40PM +0100, Vitaly Kuznetsov wrote:
> >> Sean Christopherson writes:
> >>
> >> > +
> >> > +.runtime_ops = _x86_ops,
> >> > +};
> >>
> >> Unrelated to
On 3/23/20 4:32 AM, Beata Michalska wrote:
> uint8_t ext_dabt_pending; /* Request for injecting ext DABT */
> +uint8_t ext_dabt_raised; /* Tracking/verifying injection of ext DABT */
Is there a reason these are uint8_t and not bool?
r~
___
On 23/03/20 17:24, Vitaly Kuznetsov wrote:
> Sounds cool! (not sure that with only two implementations people won't
> call it 'over-engineered' but cool).
Yes, something like
#define KVM_X86_OP(name) .name = vmx_##name
(svm_##name for svm.c) and then
KVM_X86_OP(check_nested_events)
On 23/03/20 13:27, Vitaly Kuznetsov wrote:
>> -kvm_x86_ops->check_nested_events = vmx_check_nested_events;
>> -kvm_x86_ops->get_nested_state = vmx_get_nested_state;
>> -kvm_x86_ops->set_nested_state = vmx_set_nested_state;
>> -kvm_x86_ops->get_vmcs12_pages =
Hi Marc,
On 2020/3/21 2:23, Marc Zyngier wrote:
Allocate per-VPE SGIs when initializing the GIC-specific part of the
VPE data structure.
Signed-off-by: Marc Zyngier
Reviewed-by: Zenghui Yu
Link: https://lore.kernel.org/r/20200304203330.4967-15-...@kernel.org
---
On Sat, Mar 21, 2020 at 01:25:55PM -0700, Sean Christopherson wrote:
> Pass @opaque to kvm_arch_hardware_setup() and
> kvm_arch_check_processor_compat() to allow architecture specific code to
> reference @opaque without having to stash it away in a temporary global
> variable. This will enable
On 2020/3/21 2:23, Marc Zyngier wrote:
+static int its_sgi_set_affinity(struct irq_data *d,
+ const struct cpumask *mask_val,
+ bool force)
+{
+ /*
+* There is no notion of affinity for virtual SGIs, at least
+*
29 matches
Mail list logo
