Siddha, Suresh B wrote:
> On Wed, 2009-05-06 at 23:16 -0700, Han, Weidong wrote:
>> @@ -634,6 +694,44 @@ static int ir_parse_ioapic_scope(struct
>> acpi_dmar_header *header, " 0x%Lx\n",
>> scope->enumeration_id, drhd->address);
>>
>> +
Dong, Eddie wrote:
There is not point referring to current code. Current code does not
handle serial exceptions properly. So fix it in your patch otherwise I
propose to use my patch that fixes current code
(http://patchwork.kernel.org/patch/21829/).
I would like Avi to decide.
I would
On Mon, May 11, 2009 at 09:04:52AM +0800, Dong, Eddie wrote:
>
> > There is not point referring to current code. Current code does not
> > handle serial exceptions properly. So fix it in your patch otherwise I
> > propose to use my patch that fixes current code
> > (http://patchwork.kernel.org/pat
Thanks for your advice and hope your continue attention on Luvalley.
Regards,
Xiaodong
2009/5/11 Dong, Eddie :
> Xiaodong Yi wrote:
>> It is not a typo. I copied from UnixBench output directly. Howver, it
>> must be a bug of Luvalley because even the native Linux benchmark on
>> Double-Precision
Are the instructions for passing a device at:
http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM
supposed to work for passing one of four onboard nics to a guest? I ask
because not only did it not work, it made my server a very unhappy camper.
Server: HP DL380 G6, 1 E5540, 6
On Sat, 2009-05-09 at 05:08 +0800, Anthony Liguori wrote:
> Huang Ying wrote:
> > - MCE features are initialized when VCPU is intialized according to CPUID.
> > - A monitor command "mce" is added to inject a MCE.
> > - A new interrupt mask: CPU_INTERRUPT_MCE is added to inject the MCE.
> >
> > Sign
Xiaodong Yi wrote:
> It is not a typo. I copied from UnixBench output directly. Howver, it
> must be a bug of Luvalley because even the native Linux benchmark on
> Double-Precision Whetstone is not that high. I also noticed that other
> benchmarks are all lower than native Linux.
>
> About timing,
> There is not point referring to current code. Current code does not
> handle serial exceptions properly. So fix it in your patch otherwise I
> propose to use my patch that fixes current code
> (http://patchwork.kernel.org/patch/21829/).
>
I would like Avi to decide. As comments to the differen
I have tried debugging with netconsole but I am not getting anything
directly preceding the hardlock, only:
kvm: 4682: cpu0 unhandled wrmsr: 0xc0010117 data 0
on every startup (also manages to be logged when kvm hangs at the very
beginning).
--
Best Regards,
Piotr Jaroszyński
--
To unsubscribe fr
Hello,
kvm-85 with vanilla kernel 2.6.29.3 (kvm modules from kernel) hard locks for me:
- sometimes at the very beginning, just after the QEMU window opens,
but nothing is displayed before the hardlock.
- sometimes during runtime with various guests: e.g. Windows XP 64bit
and Exherbo 64bit [1]. Th
Am Sunday 10 May 2009 06:07:06 schrieb Rusty Russell:
> Yes, and in fact a rough look at your patch reveals that we don't actually
> need del_vq: now we track them, we can just do that as part of vdev
> destruction, right?
Some of my students are working on a test module for virtio. Its a driver
Gregory Haskins wrote:
Anthony Liguori wrote:
I'm surprised so much effort is going into this, is there any
indication that this is even close to a bottleneck in any circumstance?
Yes. Each 1us of overhead is a 4% regression in something as trivial as
a 25us UDP/ICMP rtt "ping".m
mtosa...@redhat.com wrote:
Disallow the deletion of memory slots (and aliases, for x86 case), if a
vcpu contains a cr3 that points to such slot/alias.
This complements commit 6c20e1442bb1c62914bb85b7f4a38973d2a423ba.
v2:
- set KVM_REQ_TRIPLE_FAULT
- use __KVM_HAVE_ARCH_CAN_FREE_MEMSLOT to avoid
mtosa...@redhat.com wrote:
Addressing comments.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
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.kern
Xu, Jiajun wrote:
Hi All,
This is our Weekly KVM Testing Report against lastest kvm.git
66b0aed4a9e15a2ea3a00763f362b6ee0b28d538 and qemu-kvm.git
6e57bb9a636cefdaba7decbd5ac10f1508ff64c0. There is a Live Migration bug found
in this two weeks.
One New Issue:
Hi All,
This is our Weekly KVM Testing Report against lastest kvm.git
66b0aed4a9e15a2ea3a00763f362b6ee0b28d538 and qemu-kvm.git
6e57bb9a636cefdaba7decbd5ac10f1508ff64c0. There is a Live Migration bug found
in this two weeks.
One New Issue:
1. Dest
Bugs item #2789729, was opened at 2009-05-10 08:09
Message generated for change (Tracker Item Submitted) made by jiajun
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2789729&group_id=180599
Please note that this message will contain a full copy of the c
kvm misreports MCA, MCE, MTRR, and PAT as unsupported. This causes Vista to
fail. Since QEMU does not support any version of kvm that does not actually
support these features, it is safe to enable them unconditionally.
These features are needed by Vista x64 to boot.
Signed-off-by: Avi Kivity
-
Glauber Costa wrote:
we currently unblock shadow interrupt state when we skip an instruction,
but failing to do so when we actually emulate one. This blocks interrupts
in key instruction blocks, in particular sti; hlt; sequences
If the instruction emulated is an sti, we have to block shadow inte
Glauber Costa wrote:
This patch replaces drop_interrupt_shadow with the more
general set_interrupt_shadow, that can either drop or raise
it, depending on its parameter.
void (*skip_emulated_instruction)(struct kvm_vcpu *vcpu);
+ void (*set_interrupt_shadow)(struct kvm_vcpu *vcpu, i
Glauber Costa wrote:
Due to a small messup in version checking, migration was not working.
fix it.
Signed-off-by: Glauber Costa
---
migration-tcp.c |1 +
savevm.c |1 +
target-i386/helper.c |1 +
target-i386/machine.c |8
4 files changed, 7 insertio
kvm misreports MCA, MCE, MTRR, and PAT as unsupported. This causes Vista to
fail. Since QEMU does not support any version of kvm that does not actually
support these features, it is safe to enable them unconditionally.
These features are needed by Vista x64 to boot.
Signed-off-by: Avi Kivity
-
Gregory Haskins wrote:
That only works if the device exposes a pio port, and the hypervisor
exposes HC_PIO. If the device exposes the hypercall, things break
once you assign it.
Well, true. But normally I would think you would resurface the device
from G1 to G2 anyway, so any relevant t
On Sun, May 10, 2009 at 10:38:18AM +0200, Federico Fissore wrote:
> Gleb Natapov, il 10/05/2009 07:21, ha scritto:
>> On Sat, May 09, 2009 at 07:53:50PM +0200, Federico Fissore wrote:
>>> I've a windows (virtual) box with windows xp originally installed and
>>> a windows 2k lately installed
>>>
>
Gleb Natapov, il 10/05/2009 07:21, ha scritto:
On Sat, May 09, 2009 at 07:53:50PM +0200, Federico Fissore wrote:
I've a windows (virtual) box with windows xp originally installed and a
windows 2k lately installed
Are they both installed on the same disk?
yes they are
If I run kvm from
On Fri, May 08, 2009 at 04:23:05PM -0400, Glauber Costa wrote:
> Hi,
>
> This is the same patch you're all used to by now, but split in two per
> Avi request.
>
>
Acked-by: Gleb Natapov
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the bo
On Sun, May 10, 2009 at 01:37:06PM +0930, Rusty Russell wrote:
> Yes, and in fact a rough look at your patch reveals that we don't actually
> need del_vq: now we track them, we can just do that as part of vdev
> destruction, right?
Let's assume that a driver encounters an error in probe
after it
27 matches
Mail list logo