VFIO has proved itself a much better option than KVM's built-in
device assignment. It is mature, provides better isolation because
it enforces ACS, and even the userspace code is being tested on
a wider variety of hardware these days than the legacy support.
Disable legacy device assignment by de
Malicious (or egregiously buggy) userspace can trigger it, but it
should never happen in normal operation.
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/lapic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/lapic.h b/arch/x86/kvm/lapic.h
index 71b150cae5f9..9d8
On 06/03/2015 03:55 PM, Paolo Bonzini wrote:
On 03/06/2015 04:56, Xiao Guangrong wrote:
On 06/01/2015 05:36 PM, Paolo Bonzini wrote:
On 30/05/2015 12:59, Xiao Guangrong wrote:
Currently guest MTRR is completely prohibited if cache snoop is
supported on
IOMMU (!noncoherent_dma) and host
On 06/04/2015 04:23 PM, Xiao Guangrong wrote:
On 06/03/2015 03:55 PM, Paolo Bonzini wrote:
On 03/06/2015 04:56, Xiao Guangrong wrote:
On 06/01/2015 05:36 PM, Paolo Bonzini wrote:
On 30/05/2015 12:59, Xiao Guangrong wrote:
Currently guest MTRR is completely prohibited if cache snoop
On 04/06/2015 10:26, Xiao Guangrong wrote:
>>
>> CR0.CD is always 0 in both host and guest, i guess it's why we cleared
>> CR0.CD and CR0.NW in vmx_set_cr0().
>
> It reminds me that we should check guest CR0.CD before check guest MTRR
> and disable guest PAT if guest CR0.CD = 1.
I think it can
On 04/06/2015 10:23, Xiao Guangrong wrote:
>>
>> So, why do you need to always use IPAT=0? Can patch 15 keep the current
>> logic for RAM, like this:
>>
>> if (is_mmio || kvm_arch_has_noncoherent_dma(vcpu->kvm))
>> ret = kvm_mtrr_get_guest_memory_type(vcpu, gfn) <<
>> V
This was noticed by Radim while reviewing the implementation of
system management mode.
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/x86.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 79dde1656db6..bd6bcd54cd44 100644
--- a/arch/x86/kvm/x86
Do not process INITs immediately while in system management mode, keep
it instead in apic->pending_events. Tell userspace if an INIT is
pending when they issue GET_VCPU_EVENTS, and similarly handle the
new field in SET_VCPU_EVENTS.
Note that the same treatment should be done while in VMX non-root
Do not process INITs immediately while in system management mode, keep
it instead in apic->pending_events. Tell userspace if an INIT is
pending when they issue GET_VCPU_EVENTS, and similarly handle the
new field in SET_VCPU_EVENTS.
Note that the same treatment should be done while in VMX non-root
On 06/01/2015 04:24 PM, David Gibson wrote:
On Fri, May 29, 2015 at 06:44:41PM +1000, Alexey Kardashevskiy wrote:
Modern IBM POWERPC systems support multiple (currently two) TCE tables
per IOMMU group (a.k.a. PE). This adds a iommu_table_group container
for TCE tables. Right now just one table i
On Thu, May 28, 2015 at 10:43:06AM +0100, Alex Bennée wrote:
> The elr_el2 and spsr_el2 registers in fact contain the processor state
> before entry into the hypervisor code.
be careful with your use of the hypervisor, in the KVM design the
hypervisor is split across EL1 and EL2.
> In the case of
On 04/06/15 10:34, Christoffer Dall wrote:
> On Thu, May 28, 2015 at 10:43:06AM +0100, Alex Bennée wrote:
>> The elr_el2 and spsr_el2 registers in fact contain the processor state
>> before entry into the hypervisor code.
>
> be careful with your use of the hypervisor, in the KVM design the
> hype
Marc Zyngier writes:
> On 04/06/15 10:34, Christoffer Dall wrote:
>> On Thu, May 28, 2015 at 10:43:06AM +0100, Alex Bennée wrote:
>>> The elr_el2 and spsr_el2 registers in fact contain the processor state
>>> before entry into the hypervisor code.
>>
>> be careful with your use of the hyperviso
On Fri, May 29, 2015 at 10:30:24AM +0100, Alex Bennée wrote:
> This is a pre-cursor to sharing the code with the guest debug support.
> This replaces the big macro that fishes data out of a fixed location
> with a more general helper macro to restore a set of debug registers. It
> uses macro substi
On 04/06/15 11:20, Alex Bennée wrote:
>
> Marc Zyngier writes:
>
>> On 04/06/15 10:34, Christoffer Dall wrote:
>>> On Thu, May 28, 2015 at 10:43:06AM +0100, Alex Bennée wrote:
The elr_el2 and spsr_el2 registers in fact contain the processor state
before entry into the hypervisor code.
Christoffer Dall writes:
> On Fri, May 29, 2015 at 10:30:24AM +0100, Alex Bennée wrote:
>> This is a pre-cursor to sharing the code with the guest debug support.
>> This replaces the big macro that fishes data out of a fixed location
>> with a more general helper macro to restore a set of debug
Marc Zyngier writes:
> On 04/06/15 11:20, Alex Bennée wrote:
>>
>> Marc Zyngier writes:
>>
>>> On 04/06/15 10:34, Christoffer Dall wrote:
On Thu, May 28, 2015 at 10:43:06AM +0100, Alex Bennée wrote:
> The elr_el2 and spsr_el2 registers in fact contain the processor state
> before
On 04/06/15 11:46, Alex Bennée wrote:
>
> Marc Zyngier writes:
>
>> On 04/06/15 11:20, Alex Bennée wrote:
>>>
>>> Marc Zyngier writes:
>>>
On 04/06/15 10:34, Christoffer Dall wrote:
> On Thu, May 28, 2015 at 10:43:06AM +0100, Alex Bennée wrote:
>> The elr_el2 and spsr_el2 registers
On 29 May 2015 at 16:19, Alex Bennée wrote:
> As we haven't always had guest debug support we need to probe for it.
> Additionally we don't do this in the start-up capability code so we
> don't fall over on old kernels.
>
> Signed-off-by: Alex Bennée
> ---
Reviewed-by: Peter Maydell
thanks
--
On Fri, May 29, 2015 at 10:30:25AM +0100, Alex Bennée wrote:
> This introduces a level of indirection for the debug registers. Instead
> of using the sys_regs[] directly we store registers in a structure in
> the vcpu. As we are no longer tied to the layout of the sys_regs[] we
> can make the copie
On 29 May 2015 at 16:19, Alex Bennée wrote:
> These don't involve messing around with debug registers, just setting
> the breakpoint instruction in memory. GDB will not use this mechanism if
> it can't access the memory to write the breakpoint.
>
> All the kernel has to do is ensure the hypervisor
On 29 May 2015 at 16:19, Alex Bennée wrote:
> This adds support for single-step. There isn't much to do on the QEMU
> side as after we set-up the request for single step via the debug ioctl
> it is all handled within the kernel.
>
> Signed-off-by: Alex Bennée
>
> ---
> v2
> - convert to using H
On Fri, May 29, 2015 at 10:30:26AM +0100, Alex Bennée wrote:
> This adds support for userspace to control the HW debug registers for
> guest debug. In the debug ioctl we copy the IMPDEF defined number of
> registers into a new register set called host_debug_state. There is now
> a new vcpu paramete
On Fri, May 29, 2015 at 10:30:23AM +0100, Alex Bennée wrote:
> This adds support for single-stepping the guest. To do this we need to
> manipulate the guests PSTATE.SS and MDSCR_EL1.SS bits which we do in the
> kvm_arm_setup/clear_debug() so we don't affect the apparent state of the
> guest. Additi
On Fri, May 29, 2015 at 10:30:21AM +0100, Alex Bennée wrote:
> This is a precursor for later patches which will need to do more to
> setup debug state before entering the hyp.S switch code. The existing
> functionality for setting mdcr_el2 has been moved out of hyp.S and now
> uses the value kept i
On Fri, May 29, 2015 at 10:30:19AM +0100, Alex Bennée wrote:
> This commit defines the API headers for guest debugging. There are two
> architecture specific debug structures:
>
> - kvm_guest_debug_arch, allows us to pass in HW debug registers
> - kvm_debug_exit_arch, signals exception and pos
On 29 May 2015 at 16:19, Alex Bennée wrote:
> This adds basic support for HW assisted debug. The ioctl interface to
> KVM allows us to pass an implementation defined number of break and
> watch point registers. When KVM_GUESTDBG_USE_HW_BP is specified these
> debug registers will be installed in p
On Thu, Jun 04, 2015 at 11:34:46AM +0100, Alex Bennée wrote:
>
> Christoffer Dall writes:
>
> > On Fri, May 29, 2015 at 10:30:24AM +0100, Alex Bennée wrote:
> >> This is a pre-cursor to sharing the code with the guest debug support.
> >> This replaces the big macro that fishes data out of a fixe
On 29 May 2015 at 16:19, Alex Bennée wrote:
> From: Alex Bennée
>
> If we can't find details for the debug exception in our debug state
> then we can assume the exception is due to debugging inside the guest.
> To inject the exception into the guest state we re-use the TCG exception
> code (do_in
2015-06-04 08:14+0200, Paolo Bonzini:
> On 03/06/2015 21:02, Radim Krčmář wrote:
>>> + r = kvm_write_guest(vcpu->kvm, vcpu->arch.smbase + 0xfe00, buf,
>>> sizeof(buf));
>>
>> The state is saved in SMRAM, but we are accessing it using the non-SMM
>> address space ... how did it pass testing?
>>
On 29 May 2015 at 16:19, Alex Bennée wrote:
> You may be wondering what happened to v3 and v4. They do exist but
> they didn't change much from the the original patches as I've been
> mostly looking the kernel side of the equation. So in summary the
> changes are:
>
> - updates to the kernel ABI
2015-05-27 19:05+0200, Paolo Bonzini:
> This brings together the remaining parts of SMM. For now I've left the
> "weird" interaction between SMM and NMI blocking, and I'm using the same
> format for the state save area (which is also the one used by QEMU) as
> the RFC.
>
> It builds on the previo
The elr_el2 and spsr_el2 registers in fact contain the processor state
before entry into EL2. In the case of guest state it could be in either
el0 or el1.
Signed-off-by: Alex Bennée
---
v2
- s/hypervisor code/EL2/
- comment: pc/pstate before entering/on return from el2
---
arch/arm64/kvm/hy
Christoffer Dall writes:
> On Fri, May 29, 2015 at 10:30:23AM +0100, Alex Bennée wrote:
>> This adds support for single-stepping the guest. To do this we need to
>> manipulate the guests PSTATE.SS and MDSCR_EL1.SS bits which we do in the
>> kvm_arm_setup/clear_debug() so we don't affect the appa
Christoffer Dall writes:
> On Fri, May 29, 2015 at 10:30:19AM +0100, Alex Bennée wrote:
>> This commit defines the API headers for guest debugging. There are two
>> architecture specific debug structures:
>>
>> - kvm_guest_debug_arch, allows us to pass in HW debug registers
>> - kvm_debug_e
On 04/06/2015 14:26, Radim Krčmář wrote:
> A list of minor stuff I noticed (you'll probably agree with [12/13]):
Good eyes. :) I'll fix at least these:
> [06/13] get_smstate can't be a valid C function, CAPS would be clearer
> [06/13] mangled whitespace in trace_kvm_enter_smm
> [08/13] '(u16)'
On 03/06/2015 21:02, Radim Krčmář wrote:
> > + if (r < 0)
> > + return;
>
> And if we fail to write it, is there other option than throwing an error
> to userspace? (Unset HF_SMM_MASK and pretend that nothing happened
> doesn't find much support in docs.)
Just do nothing, I guess.
On 04/06/2015 16:31, Bandan Das wrote:
> > VFIO has proved itself a much better option than KVM's built-in
> > device assignment. It is mature, provides better isolation because
> > it enforces ACS, and even the userspace code is being tested on
> > a wider variety of hardware these days than th
Paolo Bonzini writes:
> VFIO has proved itself a much better option than KVM's built-in
> device assignment. It is mature, provides better isolation because
> it enforces ACS, and even the userspace code is being tested on
> a wider variety of hardware these days than the legacy support.
>
> Dis
On Thu, Jun 04, 2015 at 02:49:17PM +0100, Alex Bennée wrote:
>
> Christoffer Dall writes:
>
> > On Fri, May 29, 2015 at 10:30:19AM +0100, Alex Bennée wrote:
> >> This commit defines the API headers for guest debugging. There are two
> >> architecture specific debug structures:
> >>
> >> - kvm
On Thu, 2015-06-04 at 16:33 +0200, Paolo Bonzini wrote:
>
> On 04/06/2015 16:31, Bandan Das wrote:
> > > VFIO has proved itself a much better option than KVM's built-in
> > > device assignment. It is mature, provides better isolation because
> > > it enforces ACS, and even the userspace code is b
Paolo Bonzini writes:
> On 04/06/2015 16:31, Bandan Das wrote:
>> > VFIO has proved itself a much better option than KVM's built-in
>> > device assignment. It is mature, provides better isolation because
>> > it enforces ACS, and even the userspace code is being tested on
>> > a wider variety of
In PCI config space there is an interrupt line field (offset 0x3f),
which is used to initially communicate the IRQ line number from
firmware to the OS. _Hardware_ should never use this information,
as the OS is free to write any information in there.
But kvmtool uses this number when it triggers IR
On Wed, Jun 03, 2015 at 11:38:21AM +0200, Paolo Bonzini wrote:
> However, why is the roundtrip to userspace necessary? Could you pass
> the extint index directly as an argument to KVM_INTERRUPT? It's
> backwards-compatible, because KVM_INTERRUPT so far could not be used
> together with an in-ke
On Wed, Jun 03, 2015 at 10:54:41AM +0200, Paolo Bonzini wrote:
>
>
> On 03/06/2015 01:51, Steve Rutherford wrote:
> > First patch in a series which enables the relocation of the
> > PIC/IOAPIC to userspace.
> >
> > Adds capability KVM_CAP_SPLIT_IRQCHIP;
> >
> > KVM_CAP_SPLIT_IRQCHIP enables the
On Wed, Jun 03, 2015 at 11:16:16AM +0200, Paolo Bonzini wrote:
>
>
> On 03/06/2015 01:51, Steve Rutherford wrote:
> > +static inline void kvm_arch_irq_routing_update(struct kvm *kvm)
> > +{
> > +}
>
> Please add the static inline to all arches instead of putting it in
> #ifndef __KVM_HAVE_IOAPIC
On Fri, May 29, 2015 at 06:44:57PM +1000, Alexey Kardashevskiy wrote:
>The existing implementation accounts the whole DMA window in
>the locked_vm counter. This is going to be worse with multiple
>containers and huge DMA windows. Also, real-time accounting would requite
>additional tracking of acco
On Fri, May 29, 2015 at 06:44:29PM +1000, Alexey Kardashevskiy wrote:
>At the moment iommu_free_table() only releases memory if
>the table was initialized for the platform code use, i.e. it had
>it_map initialized (which purpose is to track DMA memory space use).
>
>With dynamic DMA windows, we wil
On Fri, May 29, 2015 at 06:44:40PM +1000, Alexey Kardashevskiy wrote:
>Modern IBM POWERPC systems support multiple (currently two) TCE tables
>per IOMMU group (a.k.a. PE). This adds a iommu_table_group container
>for TCE tables. Right now just one table is supported.
>
>This defines iommu_table_gro
On Fri, May 29, 2015 at 06:44:44PM +1000, Alexey Kardashevskiy wrote:
>At the moment the DMA setup code looks for the "ibm,opal-tce-kill"
>property which contains the TCE kill register address. Writing to
>this register invalidates TCE cache on IODA/IODA2 hub.
>
>This moves the register address fro
On Fri, May 29, 2015 at 06:44:45PM +1000, Alexey Kardashevskiy wrote:
>The iommu_table struct keeps a list of IOMMU groups it is used for.
>At the moment there is just a single group attached but further
>patches will add TCE table sharing. When sharing is enabled, TCE cache
>in each PE needs to be
On 06/05/2015 10:27 AM, Gavin Shan wrote:
On Fri, May 29, 2015 at 06:44:45PM +1000, Alexey Kardashevskiy wrote:
The iommu_table struct keeps a list of IOMMU groups it is used for.
At the moment there is just a single group attached but further
patches will add TCE table sharing. When sharing is
This patch splits existing vPMU code into a common vPMU interface (pmc.c)
and Intel specific vPMU code (pmu_intel.c) using the following steps:
- Part of arechitectural vPMU code is extracted and moved to pmu_intel.c
file. They are hooked up with the newly-defined intel_pmu_ops, which will
be
This patch enables AMD guest VM to access (R/W) PMU related MSRs, which
include PERFCTR[0..3] and EVNTSEL[0..3].
Reviewed-by: Radim Krčmář
Signed-off-by: Wei Huang
---
arch/x86/kvm/x86.c | 51 +--
1 file changed, 9 insertions(+), 42 deletions(-)
This patch defines a new function pointer struct (kvm_pmu_ops) to
support vPMU for both Intel and AMD. The functions pointers defined in
this new struct will be linked with Intel and AMD functions later. In the
meanwhile the struct that maps from event_sel bits to PERF_TYPE_HARDWARE
events is renam
Currently KVM only supports vPMU for Intel CPUs. This patchset enables
KVM vPMU support for AMD platform by creating a common PMU interface for
x86. By refractoring, PMU related MSR accesses from guest VMs are dispatched
to corresponding functions defined in arch specific files.
V4:
* Change vPM
This patch replaces the empty AMD vPMU functions (in pmu_amd.c) with real
implementation.
Signed-off-by: Wei Huang
---
arch/x86/kvm/pmu_amd.c | 122 ++---
1 file changed, 116 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/pmu_amd.c b/arch/x86
Hi Christoffer and Marc,
Ping. Any comments on this patchset for V2?
Thanks,
-Wei
On 5/28/15 00:23, Wei Huang wrote:
Initial ACPI support for ARM64 has been accepted into Linux kernel recently.
Now it is a good time to re-visit ACPI support for KVM. This patchset
enables ACPI for both arch_ti
[ CCed Zhang Yang ]
On 06/04/2015 04:36 PM, Paolo Bonzini wrote:
On 04/06/2015 10:23, Xiao Guangrong wrote:
So, why do you need to always use IPAT=0? Can patch 15 keep the current
logic for RAM, like this:
if (is_mmio || kvm_arch_has_noncoherent_dma(vcpu->kvm))
ret = kvm_mtr
59 matches
Mail list logo
