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,
Arth
On Sat, May 4, 2013 at 4:47 PM, Jan Kiszka wrote:
> Please don't top-post.
>
> On 2013-05-04 10:45, 李春奇 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.
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 wrote:
> On 2013-05-04 09:50, 李春奇 wrote:
>> Hi Jan and All,
>> I find that when enable KVM with qemu, vendor ID of simulated CPU will be
>
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 wrote:
> Am 04.05.2013 10:33, schrieb 李春奇 :
>> Add ext_features of CPUID_EXT_VMX to the following CPUs as default
>> flag (now only
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.
Signed-o
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
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 num
SR support?
Besides, this bug has also been reported at Red Hat community
https://bugzilla.redhat.com/show_bug.cgi?id=892240
And for some specific kernel (e.g. kernel 3.8.4-202.fc18.x86_64 for
fedora18) it works well.
On Tue, Apr 16, 2013 at 3:03 PM, Jan Kiszka wrote:
> On 2013-04-16 05:4
e caused by VMENTRY failed. Because macro 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 Kis
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 the
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 addr:10.0.
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 -dev
12 matches
Mail list logo
