On Tue, May 26, 2015 at 7:53 PM, Xiao Guangrong
wrote:
>
>
> On 05/26/2015 10:48 PM, Paolo Bonzini wrote:
>>
>>
>>
>> On 26/05/2015 16:45, Edward Cree wrote:
>
> This breaks older compilers that can't initialize anon structures.
>
> How old ? Even gcc 3.1 says you can use unnamed s
On 05/28/2015 01:05 AM, Paolo Bonzini wrote:
This is now very simple to do. The only interesting part is a simple
trick to find the right memslot in gfn_to_rmap, retrieving the address
space from the spte role word. The same trick is used in the auditing
code.
The comment on top of union kvm
On 05/28/2015 01:05 AM, Paolo Bonzini wrote:
This patch has no semantic change, but it prepares for the introduction
of a second address space for system management mode.
A new function x86_set_memory_region (and the "slots_lock taken"
counterpart __x86_set_memory_region) is introduced in orde
On 05/28/2015 01:05 AM, Paolo Bonzini wrote:
We need to hide SMRAM from guests not running in SMM. Therefore,
all uses of kvm_read_guest* and kvm_write_guest* must be changed to
check whether the VCPU is in system management mode and use a
different set of memslots. Switch from kvm_* to the n
On 05/28/2015 01:05 AM, Paolo Bonzini wrote:
This is always available (with one exception in the auditing code).
Later we will also use the role to look up the right memslots array.
return;
@@ -191,11 +191,15 @@ static void audit_write_protection(struct kvm *kvm,
str
On 05/28/2015 01:05 AM, Paolo Bonzini wrote:
/*
@@ -772,6 +776,7 @@ int __kvm_set_memory_region(struct kvm *kvm,
struct kvm_memory_slot *slot;
struct kvm_memory_slot old, new;
struct kvm_memslots *slots = NULL, *old_memslots;
+ int as_id, id;
enum
On 06/09/2015 08:36 AM, David Matlack wrote:
On Sat, May 30, 2015 at 3:59 AM, Xiao Guangrong
wrote:
It walks all MTRRs and gets all the memory cache type setting for the
specified range also it checks if the range is fully covered by MTRRs
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/mt
Thanks for your review, David!
On 06/09/2015 08:36 AM, David Matlack wrote:
static void update_mtrr(struct kvm_vcpu *vcpu, u32 msr)
{
struct kvm_mtrr *mtrr_state = &vcpu->arch.mtrr_state;
- gfn_t start, end, mask;
+ gfn_t start, end;
int index;
if (
On 6/8/15 10:15 PM, Paolo Bonzini wrote:
On 08/06/2015 12:33, Wanpeng Li wrote:
+if (kvm_check_request(KVM_REQ_SCAN_IOAPIC, vcpu)) {
+if (irqchip_split(vcpu->kvm)) {
+memset(vcpu->arch.eoi_exit_bitmaps, 0, 32);
+kvm_scan_ioapic_routes(
+
On Sat, May 30, 2015 at 3:59 AM, Xiao Guangrong
wrote:
> It walks all MTRRs and gets all the memory cache type setting for the
> specified range also it checks if the range is fully covered by MTRRs
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/kvm/mtrr.c | 183
> ++
On Sat, May 30, 2015 at 3:59 AM, Xiao Guangrong
wrote:
> It gets the range for the specified variable MTRR
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/kvm/mtrr.c | 19 +--
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/kvm/mtrr.c b/arch/x86/kv
On Sat, May 30, 2015 at 3:59 AM, Xiao Guangrong
wrote:
> Use union definition to avoid the decode/code workload and drop all the
> hard code
Thank you for doing this cleanup. The new code is much clearer!
>
> Signed-off-by: Xiao Guangrong
> ---
> arch/x86/include/asm/kvm_host.h | 12 ++
Hi Christoffer,
On 28/05/15 19:49, Christoffer Dall wrote:
> Until now we have been calling kvm_guest_exit after re-enabling
> interrupts when we come back from the guest, but this has the
> unfortunate effect that CPU time accounting done in the context of timer
> interrupts occurring while the g
On 08/06/15 11:54, Pavel Fedin wrote:
> Hi!
>
>> I'm afraid this is not enough. A write to GICR_TRANSLATER (DID+EID)
>> results in a (LPI,CPU) pair. Can you easily express the CPU part in
>> irqfd (this is a genuine question, I'm not familiar enough with that
>> part of the core)?
>
> But... As
Now that struct vgic_lr supports the LR_HW bit and carries a hwirq
field, we can encode that information into the list registers.
This patch provides implementations for both GICv2 and GICv3.
Signed-off-by: Marc Zyngier
---
include/linux/irqchip/arm-gic-v3.h | 3 +++
include/linux/irqchip/arm-
As we're about to cram more information in the vgic_lr structure
(HW interrupt number and additional state information), we switch
to a layout similar to the HW's:
- use bitfields to save space (we don't need more than 10 bits
to represent the irq numbers)
- source CPU and HW interrupt can share
In order to remove the crude hack where we sneak the masked bit
into the timer's control register, make use of the phys_irq_map
API control the active state of the interrupt.
Signed-off-by: Marc Zyngier
---
include/kvm/arm_arch_timer.h | 3 +++
virt/kvm/arm/arch_timer.c| 13 +++--
2
To allow a HW interrupt to be injected into a guest, we lookup the
guest virtual interrupt in the irq_phys_map rbtree, and if we have
a match, encode both interrupts in the LR.
We also mark the interrupt as "active" at the host distributor level.
On guest EOI on the virtual interrupt, the host in
In order to control the active state of an interrupt, introduce
a pair of accessors allowing the state to be set/queried.
This only affects the logical state, and the HW state will only be
applied at world-switch time.
Signed-off-by: Marc Zyngier
---
include/kvm/arm_vgic.h | 2 ++
virt/kvm/arm
So far, the only use of the HW interrupt facility is the timer,
implying that the active state is context-switched for each vcpu,
as the device is is shared across all vcpus.
This does not work for a device that has been assigned to a VM,
as the guest is entierely in control of that device (the HW
As we now inject the timer interrupt when we're about to enter
the guest, it makes a lot more sense to make sure this happens
before the vgic code queues the pending interrupts.
Otherwise, we get the interrupt on the following exit, which is
not great for latency (and leads to all kind of bizarre
As we're about to introduce some serious GIC-poking to the vgic code,
it is important to make sure that we're going to poke the part of
the GIC that belongs to the CPU we're about to run on (otherwise,
we'd end up with some unexpected interrupts firing)...
Introducing a non-preemptible section in
In order to be able to feed physical interrupts to a guest, we need
to be able to establish the virtual-physical mapping between the two
worlds.
The mapping is kept in a rbtree, indexed by virtual interrupts.
Signed-off-by: Marc Zyngier
---
include/kvm/arm_vgic.h | 18
virt/kvm/arm/vg
>From day 1, our timer code has been using a terrible hack: whenever
the guest is scheduled with a timer interrupt pending (i.e. the HW
timer has expired), we restore the timer state with the MASK bit set,
in order to avoid the physical interrupt to fire again. And again. And
again...
This is abso
We only set the irq_queued flag for level interrupts, meaning
that "!vgic_irq_is_queued(vcpu, irq)" is a good enough predicate
for all interrupts.
This will allow us to inject edge HW interrupts, for which the
state ACTIVE+PENDING is not allowed.
Signed-off-by: Marc Zyngier
---
virt/kvm/arm/vgi
On Sun, Jun 07, 2015 at 11:15:08AM +0200, Jan Kiszka wrote:
> From: Jan Kiszka
>
> ARAT signals that the APIC timer does not stop in power saving states.
> As our APICs are emulated, it's fine to expose this feature to guests,
> at least when asking for KVM host features or with CPU types that
>
On 07/06/2015 11:15, Jan Kiszka wrote:
> From: Jan Kiszka
>
> ARAT signals that the APIC timer does not stop in power saving states.
> As our APICs are emulated, it's fine to expose this feature to guests,
> at least when asking for KVM host features or with CPU types that
> include the flag. T
On 08/06/2015 12:33, Wanpeng Li wrote:
>> +if (kvm_check_request(KVM_REQ_SCAN_IOAPIC, vcpu)) {
>> +if (irqchip_split(vcpu->kvm)) {
>> +memset(vcpu->arch.eoi_exit_bitmaps, 0, 32);
>> +kvm_scan_ioapic_routes(
>> +vcpu, vcpu->ar
On Fri, Jun 05, 2015 at 05:24:07AM -0700, Mario Smarduch wrote:
> On 06/02/2015 02:27 AM, Christoffer Dall wrote:
> > On Mon, Jun 01, 2015 at 08:48:22AM -0700, Mario Smarduch wrote:
> >> On 05/30/2015 11:59 PM, Christoffer Dall wrote:
> >>> Hi Mario,
> >>>
> >>> On Fri, May 29, 2015 at 03:34:47PM -
Hi!
> I'm afraid this is not enough. A write to GICR_TRANSLATER (DID+EID)
> results in a (LPI,CPU) pair. Can you easily express the CPU part in
> irqfd (this is a genuine question, I'm not familiar enough with that
> part of the core)?
But... As far as i could understand, LPI is added to a coll
On 6/3/15 7:51 AM, Steve Rutherford wrote:
In order to support a userspace IOAPIC interacting with an in kernel
APIC, the EOI exit bitmaps need to be configurable.
If the IOAPIC is in userspace (i.e. the irqchip has been split), the
EOI exit bitmaps will be set whenever the GSI Routes are confi
On 06/06/2015 01:50, kbuild test robot wrote:
> tree: git://git.kernel.org/pub/scm/virt/kvm/kvm.git queue
> head: 6aa5e7eb06cff8d317328a0c4696b5f635ba6be3
> commit: 6aa5e7eb06cff8d317328a0c4696b5f635ba6be3 [76/76] kvm: irqchip: Break
> up high order allocations of kvm_irq_routing_table
> rep
Hi stable folk,
On 08/05/15 15:16, James Hogan wrote:
> On 07/05/15 13:47, Nicholas Mc Guire wrote:
>> Fix possible unintended sign extension in unsigned MMIO loads by casting
>> to uint16_t in the case of mmio_needed != 2.
>>
>> Signed-off-by: Nicholas Mc Guire
>
> Looks good to me. I wrote an
Hi Pavel,
On 08/06/15 07:53, Pavel Fedin wrote:
> Hello everybody!
>
>> The GICv3 ITS (Interrupt Translation Service) is a part of the
>> ARM GICv3 interrupt controller used for implementing MSIs.
>> It specifies a new kind of interrupts (LPIs), which are mapped to
>> establish a connection betw
34 matches
Mail list logo