Hi,
This is version 4 of a series of patches that I originally posted in:
http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01989.html
http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01992.html
http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg01991.html
http:/
'target_get_irq_delivered' and 'target_reset_irq_delivered' point
to functions that are called by update_irq() to detect coalesced
interrupts. Initially they point to stub functions which pretend
successful interrupt injection. apic code calls two registration
functions to replace the stubs with ap
The new fields in HPETTimer are covered by a separate VMStateDescription
which is a subsection of 'vmstate_hpet_timer'. They are only migrated if
-global hpet.driftfix=on
Signed-off-by: Ulrich Obergfell
---
hw/hpet.c | 33 +
1 files changed, 33 insertions(+
update_irq() uses a similar method as in 'rtc_td_hack' to detect
coalesced interrupts. The function entry addresses are retrieved
from 'target_get_irq_delivered' and 'target_reset_irq_delivered'.
This change can be replaced if a generic feedback infrastructure to
track coalesced IRQs for periodic,
driftfix is a 'bit type' property. Compensation of delayed callbacks
and coalesced interrupts can be enabled with the command line option
-global hpet.driftfix=on
driftfix is 'off' (disabled) by default.
Signed-off-by: Ulrich Obergfell
---
hw/hpet.c |3 +++
1 files changed, 3 insertion
Loss of periodic timer interrupts caused by delayed callbacks and by
interrupt coalescing is compensated by gradually injecting additional
interrupts during subsequent timer intervals, starting at a rate of
one additional interrupt per interval. The injection of additional
interrupts is based on a
* Pekka Enberg wrote:
> Ingo Molnar reported that 'kill -3' didn't work on his machine:
>
> * Ingo Molnar wrote:
>
> > This is really cumbersome to debug - is there some good way to get to the
> RIP
> > that the guest is hanging in? If kvm would print that out to the host
> console
>
* Ingo Molnar wrote:
> The patch below addresses these concerns, serializes the output, tidies up
> the
> printout, resulting in this new output:
There's one bug remaining that my patch does not address: the vCPUs are not
printed in order:
# vCPU #0's dump:
# vCPU #2's dump:
# vCPU #24's du
On 5/3/11, Gleb Natapov wrote:
> Thanks you for digging dipper. I am sure this shouldn't be so
> complicated though. Can you share you experience with libvirt team?
>
> http://libvirt.org/contact.html
Sorry for the late response, I posted to the libvirtd mailing list as
you suggested. But I susp
On 05/07/2011 05:42 PM, Pekka Enberg wrote:
Document KVM_CAP_NR_VCPUS that can be used by the userspace to determine
maximum number of VCPUs it can create with the KVM_CREATE_VCPU ioctl.
This capability was added in 2.6.26; so the documentation should state
that if the capability is not avail
On 05/07/2011 10:35 AM, Takuya Yoshikawa wrote:
From: Takuya Yoshikawa
This way, we can avoid checking the user space address many times when
we read the guest memory.
Although we can do the same for write if we check which slots are
writable, we do not care write now: reading the guest memory
On 05/06/2011 01:25 PM, Carsten Otte wrote:
From: Carsten Otte
This patch gives userspace access to the guest visible storage keys. Three
operations are supported:
KVM_S390_KEYOP_SSKE for setting storage keys, similar to the set storage key
extended (SSKE) instruction.
KVM_S390_KEYOP_ISKE for re
On 05/06/2011 12:30 PM, Onkar Mahajan wrote:
Is it possible to migrate KVM guest to different paths like this:
path of the image of guest01 on host A
/home/joe/guest01.img
path of the image of guest01 on host B
/home/bill/image/temp/guest01.img
is this possible ?
if it is any pointers as to
On 05/05/2011 06:05 PM, Matteo wrote:
Hello to everybody,
I am working on KVM version 2.6.38
and I'm facing a new problem on an emulated instruction
whose implementation is already in kvm.
The error shows up after the emulation of the "RET" opcode (C3 Byte
Opcode).
When trying to emulate the
On 05/04/2011 07:35 PM, Paul E. McKenney wrote:
On Wed, May 04, 2011 at 04:31:03PM +0300, Gleb Natapov wrote:
> Provide rcu_virt_note_context_switch() for vitalization use to note
> quiescent state during guest entry.
Very good, queued on -rcu.
Unless you tell me otherwise, I will assume that
On 05/01/2011 08:21 PM, Takuya Yoshikawa wrote:
Patches 0-4: Just remove unused opt
Patch 5: grpX emulation cleanup
Patch 6: jmp far emulation cleanup
Some functions introduced in patch 5/6 will be called by
opcode::execute later.
Applied, thanks.
--
I have a truly marvellous patch that fixes
On 04/30/2011 08:00 PM, Chris Thompson wrote:
I'm trying to add a trace to qemu-kvm that will log the value of the
vcpu's clock when a specific interrupt gets pushed. I'm working with
qemu-kvm-0.14.0 on the 2.6.32-31 kernel. I've added the following to
kvm_arch_try_push_interrupts in qemu-kvm-x
On 05/08/2011 11:18 AM, Nadav Har'El wrote:
This patch includes a utility function for decoding pointer operands of VMX
instructions issued by L1 (a guest hypervisor)
+ /*
+* TODO: throw #GP (and return 1) in various cases that the VM*
+* instructions require it - e.g., off
On 05/08/2011 11:22 AM, Nadav Har'El wrote:
Move the setting of constant host-state fields (fields that do not change
throughout the life of the guest) from vmx_vcpu_setup to a new common function
vmx_set_constant_host_state(). This function will also be used to set the
host state when running L2
On 09.05.2011, at 10:43, Avi Kivity wrote:
> On 05/06/2011 01:25 PM, Carsten Otte wrote:
>> From: Carsten Otte
>>
>> This patch gives userspace access to the guest visible storage keys. Three
>> operations are supported:
>> KVM_S390_KEYOP_SSKE for setting storage keys, similar to the set storage
On 05/08/2011 11:23 AM, Nadav Har'El wrote:
This patch contains code to prepare the VMCS which can be used to actually
run the L2 guest, vmcs02. prepare_vmcs02 appropriately merges the information
in vmcs12 (the vmcs that L1 built for L2) and in vmcs01 (our desires for our
own guests).
+/*
+ * pr
On 05/07/2011 06:50 PM, Sasha Levin wrote:
> Signed-off-by: Sasha Levin
> ---
> tools/kvm/virtio/blk.c | 14 +++---
> 1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/tools/kvm/virtio/blk.c b/tools/kvm/virtio/blk.c
> index accfc3e..cc3dc78 100644
> --- a/tools/kvm/virt
Hi, and thanks again for the reviews.
On Mon, May 09, 2011, Avi Kivity wrote about "Re: [PATCH 17/30] nVMX: Prepare
vmcs02 from vmcs01 and vmcs12":
> >+vmcs_write64(TSC_OFFSET,
> >+vmx->nested.vmcs01_tsc_offset + vmcs12->tsc_offset);
>
> This is probably wrong (everything with ti
On Mon, May 09, 2011, Avi Kivity wrote about "Re: [PATCH 15/30] nVMX: Move
host-state field setup to a function":
> > static int vmx_vcpu_setup(struct vcpu_vmx *vmx)
> > {
> >-u32 host_sysenter_cs, msr_low, msr_high;
> >-u32 junk;
> >+u32 msr_low, msr_high;
>
>
> Unused?
Well, it'
On 05/08/2011 11:25 AM, Nadav Har'El wrote:
This patch implements nested_vmx_vmexit(), called when the nested L2 guest
exits and we want to run its L1 parent and let it handle this exit.
Note that this will not necessarily be called on every L2 exit. L0 may decide
to handle a particular exit on
On 05/09/2011 01:27 PM, Nadav Har'El wrote:
Hi, and thanks again for the reviews.
On Mon, May 09, 2011, Avi Kivity wrote about "Re: [PATCH 17/30] nVMX: Prepare vmcs02
from vmcs01 and vmcs12":
> >+ vmcs_write64(TSC_OFFSET,
> >+ vmx->nested.vmcs01_tsc_offset + vmcs12->tsc_offset
On 05/08/2011 11:26 AM, Nadav Har'El wrote:
When KVM wants to inject an interrupt, the guest should think a real interrupt
has happened. Normally (in the non-nested case) this means checking that the
guest doesn't block interrupts (and if it does, inject when it doesn't - using
the "interrupt win
On 05/08/2011 11:27 AM, Nadav Har'El wrote:
This patch adds correct handling of IDT_VECTORING_INFO_FIELD for the nested
case.
When a guest exits while handling an interrupt or exception, we get this
information in IDT_VECTORING_INFO_FIELD in the VMCS. When L2 exits to L1,
there's nothing we need
On 2011-05-05 17:17, Alex Williamson wrote:
>> And what about the host? When does Linux release the legacy range?
>> Always or only when a specific (!=vga/vesa) framebuffer driver is loaded?
>
> Well, that's where it'd be nice if the vga arbiter was actually in more
> widespread use. It currently
On 05/08/2011 11:15 AM, Nadav Har'El wrote:
Hi,
This is the ninth iteration of the nested VMX patch set. This iteration
addresses all of the comments and requests that were raised by reviewers in
the previous rounds, with only a few exception listed below.
Some of the issues which were solved i
On 05/09/2011 01:11 PM, Alexander Graf wrote:
>
> And not in main memory, either?
Nope - storage keys are only accessible using special instructions. They're not
in RAM (visible to a guest) :).
Interesting, so where are they kept? An on-chip memory? That would
limit the amount of main me
On Mon, 2011-05-09 at 18:35 +0800, Asias He wrote:
> On 05/07/2011 06:50 PM, Sasha Levin wrote:
> > Signed-off-by: Sasha Levin
> > ---
> > tools/kvm/virtio/blk.c | 14 +++---
> > 1 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/tools/kvm/virtio/blk.c b/tools/kvm/vi
On 09.05.2011, at 13:20, Avi Kivity wrote:
> On 05/09/2011 01:11 PM, Alexander Graf wrote:
>> >
>> > And not in main memory, either?
>>
>> Nope - storage keys are only accessible using special instructions. They're
>> not in RAM (visible to a guest) :).
>>
>
> Interesting, so where are they
On Mon, May 09, 2011, Avi Kivity wrote about "Re: [PATCH 0/30] nVMX: Nested
VMX, v9":
> Okay, truly excellent. The code is now a lot more readable, and I'm
> almost beginning to understand it. The code comments are also very
> good, I wish we had the same quality comments in the rest of kvm.
Please send in any agenda items you are interested in covering.
>From last week, we have already:
- import kvm headers into qemu, drop #ifdef maze (Jan)
Thanks, Juan.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More ma
On Mon, May 09, 2011 at 11:51:34AM +0300, Avi Kivity wrote:
> On 05/04/2011 07:35 PM, Paul E. McKenney wrote:
> >On Wed, May 04, 2011 at 04:31:03PM +0300, Gleb Natapov wrote:
> >> Provide rcu_virt_note_context_switch() for vitalization use to note
> >> quiescent state during guest entry.
> >
> >V
On Sat, Apr 30, 2011 at 6:00 PM, Chris Thompson wrote:
> I'm trying to add a trace to qemu-kvm that will log the value of the vcpu's
> clock when a specific interrupt gets pushed. I'm working with
> qemu-kvm-0.14.0 on the 2.6.32-31 kernel. I've added the following to
> kvm_arch_try_push_interrupts
Jan Kiszka wrote:
> Hi guys,
>
> can anyone comment on commit e4d6d49061 ("introduce VMSTATE_U64") in
> qemu-kvm again? I strongly suspect this thing was only introduced to be
> able to grab from a __u64 (for kvmclock) without generating a compiler
> warning that you may got when using uint64_t, r
On Mon, 2011-05-09 at 13:14 +0200, Jan Kiszka wrote:
> On 2011-05-05 17:17, Alex Williamson wrote:
> >> And what about the host? When does Linux release the legacy range?
> >> Always or only when a specific (!=vga/vesa) framebuffer driver is loaded?
> >
> > Well, that's where it'd be nice if the v
On Mon, May 9, 2011 at 12:14 PM, Jan Kiszka wrote:
> On 2011-05-05 17:17, Alex Williamson wrote:
>>> And what about the host? When does Linux release the legacy range?
>>> Always or only when a specific (!=vga/vesa) framebuffer driver is loaded?
>>
>> Well, that's where it'd be nice if the vga arb
On 2011-05-09 16:29, Alex Williamson wrote:
> On Mon, 2011-05-09 at 13:14 +0200, Jan Kiszka wrote:
>> On 2011-05-05 17:17, Alex Williamson wrote:
And what about the host? When does Linux release the legacy range?
Always or only when a specific (!=vga/vesa) framebuffer driver is loaded?
>>
On 2011-05-09 16:55, Prasad Joshi wrote:
> On Mon, May 9, 2011 at 12:14 PM, Jan Kiszka wrote:
>> On 2011-05-05 17:17, Alex Williamson wrote:
And what about the host? When does Linux release the legacy range?
Always or only when a specific (!=vga/vesa) framebuffer driver is loaded?
>>>
>>
On Mon, May 9, 2011 at 4:27 PM, Jan Kiszka wrote:
> On 2011-05-09 16:55, Prasad Joshi wrote:
>> On Mon, May 9, 2011 at 12:14 PM, Jan Kiszka wrote:
>>> On 2011-05-05 17:17, Alex Williamson wrote:
> And what about the host? When does Linux release the legacy range?
> Always or only when a s
On Mon, 2011-05-09 at 17:27 +0200, Jan Kiszka wrote:
> On 2011-05-09 16:55, Prasad Joshi wrote:
> > On Mon, May 9, 2011 at 12:14 PM, Jan Kiszka wrote:
> >> On 2011-05-05 17:17, Alex Williamson wrote:
> And what about the host? When does Linux release the legacy range?
> Always or only wh
On 2011-05-09 17:48, Alex Williamson wrote:
> On Mon, 2011-05-09 at 17:27 +0200, Jan Kiszka wrote:
>> On 2011-05-09 16:55, Prasad Joshi wrote:
>>> On Mon, May 9, 2011 at 12:14 PM, Jan Kiszka wrote:
On 2011-05-05 17:17, Alex Williamson wrote:
>> And what about the host? When does Linux rel
On 05/08/2011 01:29 AM, Nadav Har'El wrote:
In the unlikely case that L1 does not capture MSR_IA32_TSC, L0 needs to
emulate this MSR write by L2 by modifying vmcs02.tsc_offset. We also need to
set vmcs12.tsc_offset, for this change to survive the next nested entry (see
prepare_vmcs02()).
Bo
On 05/08/2011 12:06 PM, Nikola Ciprich wrote:
OK,
I see.. the problem is, that I'm trying to hunt down bug causing hangs
when 2.6.32 guests try to run tcpdump - this seems to be reproducible even on
latest 2.6.32.x, and seems like it depends on kvm-clock..
So I was thinking about bisecting betwe
The guest, because latest kernels do not suffer this problem, so I'd like to
find fix so it can be pushed to -stable (we're using 2.6.32.x)
host is currently 2.6.37 (and i'm currently testing 2.6.38 as well)
n.
On Mon, May 09, 2011 at 10:32:26AM -0700, Zachary Amsden wrote:
> On 05/08/2011 12:06 P
On 05/09/2011 11:25 AM, Nikola Ciprich wrote:
The guest, because latest kernels do not suffer this problem, so I'd like to
find fix so it can be pushed to -stable (we're using 2.6.32.x)
host is currently 2.6.37 (and i'm currently testing 2.6.38 as well)
n.
That's a pretty wide range to be bisec
> That's a pretty wide range to be bisecting, and I think we know for a
> fact there were some kvmclock related bugs in that range.
thats true, I might try to pick those that seem related and see if it
helpts..
>
> If you are looking for something causing problems with tcpdump, I'd
> suggest ge
Document KVM_CAP_NR_VCPUS that can be used by the userspace to determine
maximum number of VCPUs it can create with the KVM_CREATE_VCPU ioctl.
Cc: Avi Kivity
Cc: Marcelo Tosatti
Cc: Jan Kiszka
Signed-off-by: Pekka Enberg
---
Documentation/kvm/api.txt |5 -
1 files changed, 4 insertion
From: Cyrill Gorcunov
Subject: [PATCH] kvm tools: PCI -- Make PCI device numbers being unique v2
PCI device numbers must be unique on a bus (as a part
of Bus/Device/Function tuple).Make it so. Note the patch
is rather a fast fix since we need a bit more smart pci device
manager (in particular mu
On 05/09/2011 11:53 PM, Pekka Enberg wrote:
>> From: Cyrill Gorcunov
>> Subject: [PATCH] kvm tools: PCI -- Make PCI device numbers being unique v2
>>
>> PCI device numbers must be unique on a bus (as a part
>> of Bus/Device/Function tuple).Make it so. Note the patch
>> is rather a fast fix since w
On Wed, 20 Apr 2011 14:31:33 -0600
Alex Williamson wrote:
> -struct pci_cap_saved_state {
> - struct hlist_node next;
> +struct pci_cap_saved {
> char cap_nr;
> + unsigned int size;
> u32 data[0];
> };
>
> +struct pci_cap_saved_state {
> + struct hlist_node next;
> +
So I've been struggling with configuring a proper HA
stack using DRBD on two dedicated, back-end storage nodes and
using KVM on two dedicated, front-end nodes (so four machines
total).
I'm stuck at just keeping an exported iSCSI LUN
consistent for one VM while switching over on the
55 matches
Mail list logo
