Hi there,
I'm now reading codes of kvm-unit-tests and I found that some of the
test cases for x86 is only designed for x86_64 (including access.flat,
apic.flat, emulator.flat, idt_test.flat and so on). I wonder why these
cases are not designed for i386? Or is there any other concerns?
Thanks,
Hi Jan and All,
I find that when enable KVM with qemu, vendor ID of simulated CPU will be
set the same as host, but other features such as level, family, model,
stepping are not changed. This may bring out a confusing result, the
simulated CPU has a vendor name of GenuineIntel but with family
Hi all,
There's a patch for some simulated Intel CPU with default flag of VMX, now
only core(2)duo are with VMX flag by default.
Add default ext_features of CPUID_EXT_VMX to the following CPUs:
kvm64, kvm32, Penryn, Nehalem, Westmere, SandyBridge, Haswell.
Other CPUs of AMD and lower versions of
Add ext_features of CPUID_EXT_VMX to the following CPUs as default
flag (now only core(2)duo with VMX flag by default):
kvm64, kvm32, Penryn, Nehalem, Westmere, SandyBridge, Haswell.
Other CPUs of AMD and lower versions of Intel CPU without VMX support
don't add this feature by default.
I send this mail before receiving your previous mail. I will check all
this things.
Thanks,
Arthur
On Sat, May 4, 2013 at 4:39 PM, Andreas Färber afaer...@suse.de wrote:
Am 04.05.2013 10:33, schrieb 李春奇 Arthur Chunqi Li:
Add ext_features of CPUID_EXT_VMX to the following CPUs as default
flag
But will the difference between the vendor ID and family number cause
confusion to the OS in VM?
On Sat, May 4, 2013 at 4:05 PM, Jan Kiszka jan.kis...@web.de wrote:
On 2013-05-04 09:50, 李春奇 Arthur Chunqi Li wrote:
Hi Jan and All,
I find that when enable KVM with qemu, vendor ID of simulated
On Sat, May 4, 2013 at 4:47 PM, Jan Kiszka jan.kis...@web.de wrote:
Please don't top-post.
On 2013-05-04 10:45, 李春奇 Arthur Chunqi Li wrote:
But will the difference between the vendor ID and family number cause
confusion to the OS in VM?
The confusion is not yet clear to me. About which -cpu
, 李春奇 Arthur Chunqi Li wrote:
I changed to the latest version of kvm kernel but the bug also occured.
On the startup of L1 VM on the host, the host kern.log will output:
Apr 16 11:28:22 Blade1-02 kernel: [ 4908.458090] kvm [2808]: vcpu0
unhandled rdmsr: 0x345
Apr 16 11:28:22 Blade1-02
Hi all,
In a nested virtualization environment of qemu+KVM, some emulated CPU (such
as core2duo) may cause L2 guest crash after booting for a while. Here's my
configuration:
Host:
Linux 3.5.7
Qemu is the latest version from git repository.
Emulated CPU : core2duo
L1 guest:
Linux 3.5.7
Qemu is
VMX_EXIT_REASONS_FAILED_VMENTRY
is 0x8000 and the output errno is 0x7, so this error is caused by the
second branch. I'm not very clear what the result of
vmcs_read32(VM_INSTRUCTION_ERROR) refers to.
Thanks,
Arthur
On Mon, Apr 15, 2013 at 3:43 PM, Jan Kiszka jan.kis...@web.de wrote:
On 2013-04-15 08:24, 李春奇 Arthur
Hi all,
I install qemu from git repository with KVM, and connect network with
bridge. The connection to the vm sometimes cannot establish.
The network configure of host OS is here:
root@Blade1-02:~/qemu.git# ifconfig
br0 Link encap:Ethernet HWaddr 00:26:b9:fa:de:48
inet
Hi all,
I initialized qemu-ga failed according the manul of
http://wiki.qemu.org/Features/QAPI/GuestAgent. My commands are here:
root@Blade3-01:/nfs# qemu-system-x86_64 vdisk.img -m 1024 -daemonize -vnc
localhost:1 -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0
-device virtio-serial
12 matches
Mail list logo
