elease, to change it to kvm-89, and once right after the release to change it
back to kvm-89-devel)?
Signed-off-by: Chris Lalancette
diff --git a/KVM_VERSION b/KVM_VERSION
new file mode 100644
index 000..efd3e0e
--- /dev/null
+++ b/KVM_VERSION
@@ -0,0 +1 @@
+kvm-88-devel
inside their guests, and this
kvmclock change will "fight" with ntpd. Also, the command "# date 09091323" (or
whatever) ceases to work like it does on bare-metal, so I think it has to be an
opt-in feature.
--
Chris Lalancette
--
To unsubscribe from this list: send the line &q
> I believe.
>>>
>> For interrupts going through IOPIC, but we know this is not scalable
>> anyway.
>>
>
> Yes. We also wanted to convert the ioapic/pic to spinlocks so we could
> queue the interrupt from the PIT directly instead of using
> KVM_RE
> +}
The thing is, there are other valid reasons for vmentry failure. A while ago I
tracked
down a bug in the Linux kernel that was causing us to vmenter with invalid
segments;
this message would have been very misleading in that case. I think you'd have
to do
more complete analysis of th
r,
for efficiency reasons we may want to have one workqueue per guest. Opinions?
Chris Lalancette
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
We really want to "kvm_set_irq" during the hrtimer callback,
but that is risky because that is during interrupt context.
Instead, offload the work to a workqueue, which is a bit safer
and should provide most of the same functionality.
Signed-off-by: Chris Lalancette
---
arch/x86/k
If the guest wants to accept timer interrupts on a CPU other
than the BSP, we need to remove this gate.
Signed-off-by: Chris Lalancette
---
arch/x86/kvm/lapic.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index
Otherwise we might try to deliver a timer interrupt to a cpu that
can't possibly handle it.
Signed-off-by: Chris Lalancette
---
virt/kvm/irq_comm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
index 52f412f..06cf61e 1
one PIT workqueue per-guest
- Remember to cancel_work_sync when destroying the PIT
Chris Lalancette
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
We really want to "kvm_set_irq" during the hrtimer callback,
but that is risky because that is during interrupt context.
Instead, offload the work to a workqueue, which is a bit safer
and should provide most of the same functionality.
Signed-off-by: Chris Lalancette
---
arch/x86/k
Otherwise we might try to deliver a timer interrupt to a cpu that
can't possibly handle it.
Signed-off-by: Chris Lalancette
---
virt/kvm/irq_comm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
index 52f412f..06cf61e 1
If the guest wants to accept timer interrupts on a CPU other
than the BSP, we need to remove this gate.
Signed-off-by: Chris Lalancette
---
arch/x86/kvm/lapic.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index
ectly, upstream Qemu now has suppressed this warning
message, so the next time KVM syncs up, the message will disappear.
Chris Lalancette
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
->buf, f->buf_offset, f->buf_index);
Nit...whitespace damage.
...
Overall, seems to be a good refactoring, and seems to keep the original
semantics of qemu_fopen_bdrv() and qemu_fopen().
Chris Lalancette
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
;
> +}
> +}
> +}
> +
This one is yucky, as the FIXME points out. First, I'm guessing the point of
this is to do an ARP poison on the switch? If so, we probably want to do some
kind of ARP packet, although I'm not an expert on this. Also, why are we trying
at's fine. Actual people at the
console will pass that switch, and the management tools won't (or vice-versa; I
don't really care what the default is). This is really no different from the
situation we currently have in KVM, where you pass -d to do it in the
background, and pass no o
rs
> using an live savevm callback to avoid unnecessary guest down time.
Simple enough, and follows the pattern in the KVM migration.
Chris Lalancette
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
lse. The only other thing I can think of based on your command-line
below is something to do with your -net options; I've only successfully migrated
with -net tap before, I've never tried -net user.
Chris Lalancette
>
> Source : KVM-73, Cent OS 5.2, 64 bit.
>
> qemu-system
retty sure you have to test for it first; pre-64 bit x86 hardware doesn't
have the EFER register, so you'll fault on access. On the other hand pre-64 bit
x86 hardware doesn't usually (ever?) have VT extensions either.
--
Chris Lalancette
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
equivalent to hitting the soft
power button on a piece of hardware. In recent testing, I was able to use virsh
shutdown to shut down basically any 2.6 based Linux guest, and any Windows guest
using ACPI.
That said, doing the backup "inside" the guest, as suggested by Javier, i
that's not true (if I remember correctly). The uuid is exposed to
the guest
via the SMBIOS tables, so that might be causing the problem. Try setting the
UUID in the libvirt XML, and that may solve it.
--
Chris Lalancette
--
To unsubscribe from this list: send the line "unsubscribe kvm
e a Rev F (cpu_family 15 == 0xf in hex).
--
Chris Lalancette
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
bits 63:32 of this
field *must* be 0. Use vmcs_write32() where appropriate.
This fixes booting of an absolutely ancient Red Hat Linux 5.2
(not Enterprise Linux!) guest.
Signed-off-by: Chris Lalancette
---
arch/x86/kvm/vmx.c | 17 -
1 files changed, 16 insertions(+), 1 deletions
If we fail to handle a VMEXIT for some reason, print out a lot
more debugging information about the state of the GUEST VMCS
area. This does not fix a bug, but helps a lot when trying to
track down the cause of a VMEXIT/VMENTRY failure.
Signed-off-by: Chris Lalancette
---
arch/x86/kvm/vmx.c
Gleb Natapov wrote:
> On Tue, Oct 20, 2009 at 09:50:45AM +0200, Chris Lalancette wrote:
>> If we fail to handle a VMEXIT for some reason, print out a lot
>> more debugging information about the state of the GUEST VMCS
>> area. This does not fix a bug, but helps a lot when tr
Avi Kivity wrote:
> On 10/20/2009 04:50 PM, Chris Lalancette wrote:
>> If we fail to handle a VMEXIT for some reason, print out a lot
>> more debugging information about the state of the GUEST VMCS
>> area. This does not fix a bug, but helps a lot when trying to
>>
forgot that qemu dumps the register state to stderr before abort()'ing on an
unknown vm exit. Libvirt takes the output from stderr and stores it in
/var/log/libvirt/qemu/. So you would still be able to see this
output when using libvirt.
--
Chris Lalancette
--
To unsubscribe from this list:
>base = (unsigned)get_desc_base(seg_desc);
kvm_desct->limit = get_desc_limit(seg_desc);
if (seg_desc->g) {
kvm_desct->limit <<= 12;
--
Chris Lalancette
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t
the caller intended. This patch casts the entire thing
to unsigned before returning, which generates almost the
same assembly as the current code but replaces the final
"cltq" (sign extend) with a "mov %eax %eax" (zero-extend).
This fixes booting certain guests under KVM.
Signed
d; I got no response last time so I guess I sent it to
the wrong places)
Signed-off-by: Chris Lalancette
---
arch/x86/include/asm/desc.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index e8de2f6..617bd56 1006
This patch series aims to get kdump working inside a KVM guest.
The current problem with using kdump is that KVM always delivers
PIT interrupts to the BSP, and the BSP only. While this is
technically allowed by the MPS spec, most motherboards actually
deliver timer interrupts to *any* LAPIC in vi
Signed-off-by: Chris Lalancette
---
:100644 100644 34b700f... ba61f27... M arch/x86/kvm/svm.c
:100644 100644 38a2d20... cd6f92b... M virt/kvm/ioapic.c
:100644 100644 bd44fb4... c22bc17... M virt/kvm/kvm_main.c
arch/x86/kvm/svm.c |2 +-
virt/kvm/ioapic.c |2 +-
virt/kvm/kvm_main.c
h.
2) In __kvm_migrate_pit_timer, we have to migrate the PIT
around with the BSP, since hrtimers work on a per-CPU basis.
I've added a comment here to clarify why this is needed.
Signed-off-by: Chris Lalancette
---
:100644 100644 fab7440... d5c08fa... M arch/x86/kvm/i8254.c
:100644 100644 d4c1c7f... d7bc40b
.
I don't love the concept of doing kvm_irq_kick_vcpus() from
within pit_timer_fn(). A PIT is not connected to a CPU at all,
only to a PIC or APIC. However, if a CPU enters idle, this is
the only way to wake it up to check for the interrupt.
Signed-off-by: Chris Lalancette
---
:100644 1
The code in arch/x86/kvm/timer.c is not similar enough between
the various implementations to really share it. Move the
implementation into the LAPIC code, and then remove timer.c
Signed-off-by: Chris Lalancette
---
:100644 100644 31a7035... 8d9adf6... M arch/x86/kvm/Makefile
:100644 100644
KVM_REQ_PENDING_TIMER is set and cleared in a couple of places,
but it never seems to be actually checked. Remove it.
Signed-off-by: Chris Lalancette
---
:100644 100644 eea4043... 72b5144... M arch/x86/kvm/timer.c
:100644 100644 2ef39062.. 93a65b4... M arch/x86/kvm/x86.c
:100644 100644
Avi Kivity wrote:
> On 10/27/2009 06:41 PM, Chris Lalancette wrote:
>> This patch series aims to get kdump working inside a KVM guest.
>> The current problem with using kdump is that KVM always delivers
>> PIT interrupts to the BSP, and the BSP only. While this is
>>
Marcelo Tosatti wrote:
> On Tue, Oct 27, 2009 at 05:41:07PM +0100, Chris Lalancette wrote:
>> This patch is the main point of the series. In order for
>> kdump to properly work inside a KVM guest, we need to make
>> sure that all VCPUs in virtual wire APIC mode get kicked
resend, since no response to the last two submissions)
Signed-off-by: Chris Lalancette
---
arch/x86/include/asm/desc.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index e8de2f6..617bd56 100644
--- a/arch/x86
Avi Kivity wrote:
> On 10/28/2009 12:13 PM, Chris Lalancette wrote:
>>> The kick from i8254 code is pretty bad, as you mention. I forget why it
>>> is needed at all - shouldn't kvm_set_irq() end up kicking the correct
>>>
>> As I understand it, th
emu dumps
the state of all of the guest fields when it's going to crash like this, and
that can tell us if the GUEST_STATE is wrong.
2) Try the patch posted here: http://lkml.org/lkml/2009/10/28/201, and see if
it helps?
--
Chris Lalancette
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Marcelo Tosatti wrote:
> On Wed, Oct 28, 2009 at 11:21:42AM +0100, Chris Lalancette wrote:
>> Marcelo Tosatti wrote:
>>> On Tue, Oct 27, 2009 at 05:41:07PM +0100, Chris Lalancette wrote:
>>>> This patch is the main point of the series. In order for
>>>>
Marcelo Tosatti wrote:
> On Fri, Oct 30, 2009 at 01:23:57PM +0100, Chris Lalancette wrote:
>> Marcelo Tosatti wrote:
>>> On Wed, Oct 28, 2009 at 11:21:42AM +0100, Chris Lalancette wrote:
>>>> Marcelo Tosatti wrote:
>>>>> On Tue, Oct 27, 2009 at 05:41:07
Avi Kivity wrote:
> On 10/30/2009 02:23 PM, Chris Lalancette wrote:
>> In the meantime, I've gotten the "set_irq from IRQ context" that Avi
>> suggested
>> working, and the fixing up of this IOAPIC check is the last bit to actually
>> get
>> kdump
retry, no response to the previous 2)
Signed-off-by: Chris Lalancette
---
arch/x86/include/asm/desc.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index e8de2f6..617bd56 100644
--- a/arch/x86/include/asm/desc
Another version of the patch series to make kdump work inside KVM
guests. The current problem with using kdump is that KVM only
delivers PIT interrupts to the BSP. While this is technically
allowed by the MPS spec, most motherboards deliver timer interrupts
to *any* LAPIC in virtual wire mode.
Signed-off-by: Chris Lalancette
---
arch/x86/kvm/svm.c |2 +-
virt/kvm/ioapic.c |4 ++--
virt/kvm/kvm_main.c |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 3de0b37..68fe7f2 100644
--- a/arch/x86/kvm/svm.c
+++ b
Signed-off-by: Chris Lalancette
---
arch/x86/kvm/i8259.c |2 +-
arch/x86/kvm/irq.h |2 --
2 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/i8259.c b/arch/x86/kvm/i8259.c
index d057c0c..59a8a68 100644
--- a/arch/x86/kvm/i8259.c
+++ b/arch/x86/kvm/i8259.c
KVM_REQ_PENDING_TIMER is set and cleared in a couple of places,
but it never seems to be actually checked. Remove it.
Signed-off-by: Chris Lalancette
---
arch/x86/kvm/timer.c |5 +
arch/x86/kvm/x86.c |1 -
include/linux/kvm_host.h |1 -
3 files changed, 1 insertions
Since we want to be able to call kvm_pic_set_irq() in interrupt
context, convert the uses of spin_lock() to spin_lock_irqsave()
as appropriate in i8259.c
Signed-off-by: Chris Lalancette
---
arch/x86/kvm/i8259.c | 34 ++
1 files changed, 22 insertions(+), 12
In order to be able to call kvm_set_irq from an interrupt
context, the IOAPIC lock can't be a (possibly sleeping) mutex.
Convert it to a spinlock.
Signed-off-by: Chris Lalancette
---
virt/kvm/ioapic.c | 40 +---
virt/kvm/ioapic.h |2 +-
2 files ch
Only redirect IRQ 0 (i.e. timer interrupt) to the BSP if
the APIC destination is multiple vcpus.
Signed-off-by: Chris Lalancette
---
virt/kvm/ioapic.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
index 53f3166
The code in timer.c isn't really similar enough between
the i8254 and the lapic to share. Split these into
separate functions, and remove timer.c
Signed-off-by: Chris Lalancette
---
arch/x86/kvm/Makefile|3 +-
arch/x86/kvm/i8254.c | 27 -
arch/x8
Call it kvm_apic_in_virtual_wire_mode, which is more
correct. Also change it to not only operate properly
on the boot CPU, but on any CPU.
Signed-off-by: Chris Lalancette
---
arch/x86/kvm/i8259.c |2 +-
arch/x86/kvm/irq.c |4 ++--
arch/x86/kvm/lapic.c | 17 -
arch
Signed-off-by: Chris Lalancette
---
arch/x86/kvm/i8254.c | 101 +++---
arch/x86/kvm/i8254.h |1 -
arch/x86/kvm/irq.c | 10 +
arch/x86/kvm/irq.h |2 -
4 files changed, 23 insertions(+), 91 deletions(-)
diff --git a/arch/x86/kvm/i8254
While generally the PIT is used to signal only the BSP,
it's doesn't actually have to do that architecturally.
Allow the PIC to signal any VCPU that is in
Virtual Wire mode.
Signed-off-by: Chris Lalancette
---
arch/x86/kvm/i8259.c | 19 ++-
1 files changed, 10 insert
Make sure that we kick the appropriate vcpu when delivering
an interrupt. This makes sure that we wake any idle cpus
to cause a "vcpu_run" and an interrupt injection to occur.
Signed-off-by: Chris Lalancette
---
virt/kvm/irq_comm.c |5 -
1 files changed, 4 insertions(+), 1
Changes to the irq_ack variable in the pit_state must be
protected by the inject_lock spinlock; otherwise, we can
erroneously inject a timer interrupt into a guest.
Signed-off-by: Chris Lalancette
---
arch/x86/kvm/i8254.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git
On 12/01/2009 08:04 PM, Jan Kiszka wrote:
> Chris Lalancette wrote:
>> KVM_REQ_PENDING_TIMER is set and cleared in a couple of places,
>> but it never seems to be actually checked. Remove it.
>>
>
> I would suggest to study the introducing commit
> 06e05645661211
On 12/02/2009 04:44 PM, Gleb Natapov wrote:
> On Tue, Dec 01, 2009 at 03:36:41PM +0100, Chris Lalancette wrote:
>> Make sure that we kick the appropriate vcpu when delivering
>> an interrupt. This makes sure that we wake any idle cpus
>> to cause a "vcpu_run" and
As we've discussed previously, here is a series of patches to
fix some of the IRQ routing issues we have in KVM. With this series
in place I was able to successfully kdump a RHEL-5 64-bit, and RHEL-6
32- and 64-bit guest on CPU's other than the BSP. RHEL-5 32-bit kdump still
does not work; it get
We really want to "kvm_set_irq" during the hrtimer callback,
but that is risky because that is during interrupt context.
Instead, offload the work to a workqueue, which is a bit safer
and should provide most of the same functionality.
Signed-off-by: Chris Lalancette
---
arch/x86/k
If the guest wants to accept timer interrupts on a CPU other
than the BSP, we need to remove this gate.
Signed-off-by: Chris Lalancette
---
arch/x86/kvm/lapic.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index
Otherwise we might try to deliver a timer interrupt to a cpu that
can't possibly handle it.
Signed-off-by: Chris Lalancette
---
virt/kvm/irq_comm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
index 52f412f..06cf61e 1
As we've discussed previously, here is a series of patches to
fix some of the IRQ routing issues we have in KVM. With this series
in place I was able to successfully kdump a RHEL-5 64-bit, and RHEL-6
32- and 64-bit guest on CPU's other than the BSP. RHEL-5 32-bit kdump still
does not work; it get
We really want to "kvm_set_irq" during the hrtimer callback,
but that is risky because that is during interrupt context.
Instead, offload the work to a workqueue, which is a bit safer
and should provide most of the same functionality.
Signed-off-by: Chris Lalancette
---
arch/x86/k
Otherwise we might try to deliver a timer interrupt to a cpu that
can't possibly handle it.
Signed-off-by: Chris Lalancette
---
virt/kvm/irq_comm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
index 52f412f..06cf61e 1
If the guest wants to accept timer interrupts on a CPU other
than the BSP, we need to remove this gate.
Signed-off-by: Chris Lalancette
---
arch/x86/kvm/lapic.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index
s will have
exactly the same behavior as today; VCPU0 is always looked at
first, so it will always get out of the loop after the first
iteration. This will only go through the loop more than once
during a kexec/kdump, in which case it will only do it a few times
until the kexec'ed kernel program
If kvm is *not* detected, then the qemu/configure script gets upset. Add some
quotes to make it happier.
Signed-off-by: Chris Lalancette
diff --git a/qemu/configure b/qemu/configure
index ff4a462..107699a 100755
--- a/qemu/configure
+++ b/qemu/configure
@@ -1642,7 +1642,7
ot being emulated properly on the host side, but I'm not quite sure of
that, nor am I sure where to go from here. Does anybody have any ideas of what
I can do to further track this down?
--
Chris Lalancette
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the bod
Fix a modprobe virtio_blk ; rmmod virtio_blk ; modprobe virtio_blk crash; this
was basically because we weren't doing "del_gendisk()" in the remove path.
Signed-off-by: Chris Lalancette <[EMAIL PROTECTED]>
commit 9ae82ccb26be0155ad81b2630090e85639a0dc56
Author: Chris Lalance
register_virtio_device() is doing something silly by overwriting what the caller
put into .bus_id. This causes the interrupt line for all virtio devices to show
up as "0", "1", etc. in /proc/interrupts. The attached patch fixes it.
Signed-off-by: Chris Lalancette <[E
Jens Axboe wrote:
> On Thu, May 22 2008, Rusty Russell wrote:
>> On Wednesday 21 May 2008 23:12:39 Chris Lalancette wrote:
>>> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
>>> index 4962e62..c678ac5 100644
>>> --- a/drivers/block/
Rusty Russell wrote:
> On Wednesday 21 May 2008 23:13:05 Chris Lalancette wrote:
>> Author: Chris Lalancette <[EMAIL PROTECTED]>
>> Date: Thu May 15 09:04:55 2008 -0400
>>
>> register_virtio_device was doing something silly, in that it was
>> overwri
cting a GPF kills the guest.
Tested by me on RHEL-4 i386 and x86_64 guests, as well as F-9 guests.
Signed-off-by: Chris Lalancette <[EMAIL PROTECTED]>
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index aaa99ed..f28789e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@
Chris Lalancette wrote:
> Attached is a patch for fake emulating Intel perfctr MSRs, similar to the
> recent
> patch to fake emulate the AMD perfctr MSRs. This is needed for a reason
> similar
> for the previous patch; older linux guests (in this case, 2.6.9) can attempt
&g
cting a GPF kills the guest.
Tested by me on RHEL-4 i386 and x86_64 guests, as well as F-9 guests.
Signed-off-by: Chris Lalancette <[EMAIL PROTECTED]>
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index aaa99ed..f28789e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@
r the pointer. I didn't even see those additional #define's!
I'll respin the patch like you suggest.
Thanks,
Chris Lalancette
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Respin of my previous patch to fake emulate the Intel perfctr MSRs. As Sheng
Yang pointed out, I didn't need an additional include, and I could use other
#define's.
Signed-off-by: Chris Lalancette <[EMAIL PROTECTED]>
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index
nd the system will bring up the bridge at bootup and plug your
eth0 into it. I'm sure the other distributions have similar mechanisms.
Chris Lalancette
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
receive 4 bytes.
Avi, I don't know when you plan to next rebase KVM to upstream QEMU, but it's
probably a good idea to carry this patch so that live migration works at all.
Signed-off-by: Chris Lalancette <[EMAIL PROTECTED]>
diff --git a/qemu/hw/i2c.c b/qemu/hw/i2c.c
index 5d283fb
destination side was
expecting 4 bytes, while the i2c save on the sending side was only sending 1
byte, so they eventually timed out while waiting for each other.
Chris Lalancette
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EM
guests under AMD. After installing
WinDbg, it told me that it was a "Paging Request in Non-Paged memory" related to
the Video memory area. Does yours look similar to that? I have not had time to
track it further than that, though.
Chris Lalancette
--
To unsubscribe from this lis
r migration to start, and then complete
(qemu) info block
...etc.
Signed-off-by: Chris Lalancette <[EMAIL PROTECTED]>
diff --git a/qemu/monitor.c b/qemu/monitor.c
index 20dcca6..c11b82c 100644
--- a/qemu/monitor.c
+++ b/qemu/monitor.c
@@ -504,6 +504,25 @@ static void do_cont(void
has
the benefit of being similar to already existing Qemu commands. My preference
is for the monitor command since it seems a little more natural for a management
tool, but the nowait is clearly an option as well.
I'll also post a cleanup patch with Dan's suggestion for the monitor patch,
de so that you start up
the receiving side similar to:
qemu-kvm -M pc -S blah blah -incoming tcp://0:,nowait
Then you are able to interact with the monitor before the live migration takes
place.
Signed-off-by: Chris Lalancette <[EMAIL PROTECTED]>
diff --git a/qemu/migration.c b/qemu/m
vl.c
Actually, that won't quite work. We still need to share the incoming_monitor
flag between migration.c and monitor.c. However, your suggestion is better in
that this is a "migration-specific" flag, so I'll move it over like you suggest.
Chris Lalancette
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Chris Lalancette wrote:
> Sometimes you want to be able to start up the receiving side of a live
> migration
> and actually be able to run monitor commands before you do the migration.
> Libvirt, in particular, wants to do this for setting up the migration. This
> patch imple
d then
running "cont" in the monitor. In this case, the machine is already running,
and *also* listening for incoming migrate requests. Now you do exactly the same
on machine B, and you should be able to migrate back and forth between them at
will.
Chris Lalancette
--
To unsubscribe from
90 matches
Mail list logo
