Re: [Qemu-devel] [PATCH uq/master V2] kvm: Add CPUID support for VIA CPU
From: BrillyWu
Hi, Jan
I'm very sorry for these bugs in the patch. Now I have made a
new patch based on the
newest uq/master where the patch has been applied to fix these bugs,
is it feasible? If it is
not acceptable, should I re-generate a patch based on previous
uq/master, or what else?
Signed-off-by: BrillyWu
Signed-off-by: KaryJin
---
target-i386/cpu.h |4
target-i386/cpuid.c | 18 +++---
target-i386/2 files changed, 15 insertions(+), 7 deletions(-)
--- a/target-i386/cpu.h 2011-05-30 10:14:30.184533002 +0800
+++ b/target-i386/cpu.h 2011-05-30 10:41:45.704533001 +0800
@@ -441,6 +441,10 @@
#define CPUID_VENDOR_AMD_2 0x69746e65 /* "enti" */
#define CPUID_VENDOR_AMD_3 0x444d4163 /* "cAMD" */
+#define CPUID_VENDOR_VIA_1 0x746e6543 /* "Cent" */
+#define CPUID_VENDOR_VIA_2 0x48727561 /* "aurH" */
+#define CPUID_VENDOR_VIA_3 0x736c7561 /* "auls" */
+
#define CPUID_MWAIT_IBE (1 << 1) /* Interrupts can exit capability */
#define CPUID_MWAIT_EMX (1 << 0) /* enumeration supported */
--- a/target-i386/cpuid.c 2011-05-30 10:14:30.194533005 +0800
+++ b/target-i386/cpuid.c 2011-05-30 15:07:18.794532910 +0800
@@ -1051,14 +1051,18 @@ void cpu_x86_cpuid(CPUX86State *env, uin
uint32_t *ecx, uint32_t *edx)
{
/* test if maximum index reached */
-if ((index & 0xC00f) == index) {
-/* Handle the Centaur's CPUID instruction. */
-if (index > env->cpuid_xlevel2) {
-index = env->cpuid_xlevel2;
+if (index & 0x8000) {
+if (index > env->cpuid_xlevel) {
+if (env->cpuid_xlevel2 > 0) {
+/* Handle the Centaur's CPUID instruction. */
+if (index > env->cpuid_xlevel2) {
+index = env->cpuid_xlevel2;
+} else if (index < 0xC000) {
+index = env->cpuid_xlevel;
+}
+} else
+index = env->cpuid_xlevel;
}
-} else if (index & 0x8000) {
-if (index > env->cpuid_xlevel)
-index = env->cpuid_level;
} else {
if (index > env->cpuid_level)
index = env->cpuid_level;
Re: [Qemu-devel] [PATCH uq/master V2] kvm: Add CPUID support for VIA CPU
On 2011-05-30 09:40, BrillyWu wrote: > From: BrillyWu > > Hi, Jan > I'm very sorry for these bugs in the patch. Now I have made a > new patch based on the > newest uq/master where the patch has been applied to fix these bugs, > is it feasible? If it is > not acceptable, should I re-generate a patch based on previous > uq/master, or what else? A clean patch (which passed checkpatch...) against uq/master without the broken version is required. We can't push a non-bisectable series upstream. Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] [PATCH] VMDK: add monolithic flat image support
VMDK multiple file images can not be recognized for now. This patch is
adding monolithic flat support to it, that is the image type with two
files, one text descriptor file and a plain data file. This type of
image can be created in VMWare, with the options "allocate all disk
space now" and "store virtual disk as a single file" checked.
A VmdkExtent structure is introduced to hold the image "extent"
information, which makes further adding multi extents support of VMDK
easy. An image creating option "flat" is added for creating flat
(preallocated) image.
Signed-off-by: Feiran (Fam) Zheng
---
block/vmdk.c | 686 +-
block_int.h |2 +
qemu-img.c | 12 +-
3 files changed, 542 insertions(+), 158 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index 8fc9d67..726ad3a 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -30,6 +30,8 @@
#define VMDK3_MAGIC (('C' << 24) | ('O' << 16) | ('W' << 8) | 'D')
#define VMDK4_MAGIC (('K' << 24) | ('D' << 16) | ('M' << 8) | 'V')
+#define VMDK_FLAT_BACKING 0
+
typedef struct {
uint32_t version;
uint32_t flags;
@@ -60,7 +62,10 @@ typedef struct {
#define L2_CACHE_SIZE 16
-typedef struct BDRVVmdkState {
+typedef struct VmdkExtent {
+BlockDriverState *file;
+int flat;
+int64_t sectors;
int64_t l1_table_offset;
int64_t l1_backup_table_offset;
uint32_t *l1_table;
@@ -73,8 +78,15 @@ typedef struct BDRVVmdkState {
uint32_t l2_cache_offsets[L2_CACHE_SIZE];
uint32_t l2_cache_counts[L2_CACHE_SIZE];
-unsigned int cluster_sectors;
uint32_t parent_cid;
+unsigned int cluster_sectors;
+} VmdkExtent;
+
+typedef struct BDRVVmdkState {
+int has_descriptor_file;
+int extent_size;
+int cid_update;
+VmdkExtent *extents;
} BDRVVmdkState;
typedef struct VmdkMetaData {
@@ -88,21 +100,30 @@ typedef struct VmdkMetaData {
static int vmdk_probe(const uint8_t *buf, int buf_size, const char *filename)
{
uint32_t magic;
-
+char *cid_p, *ct_p, *extent_p;
+char cid_str[] = "CID";
+char ct_str[] = "createType";
+char extent_str[] = "RW";
if (buf_size < 4)
return 0;
magic = be32_to_cpu(*(uint32_t *)buf);
if (magic == VMDK3_MAGIC ||
-magic == VMDK4_MAGIC)
+magic == VMDK4_MAGIC) {
return 100;
-else
+} else {
+cid_p = strstr((char *)buf, cid_str);
+ct_p = strstr((char *)buf, ct_str);
+extent_p = strstr((char *)buf, extent_str);
+if (cid_p && ct_p && extent_p)
+return 100;
+}
return 0;
}
#define CHECK_CID 1
#define SECTOR_SIZE 512
-#define DESC_SIZE 20*SECTOR_SIZE // 20 sectors of 512 bytes each
+#define DESC_SIZE (20 * SECTOR_SIZE)// 20 sectors of 512 bytes each
#define HEADER_SIZE 512// first sector of 512 bytes
static uint32_t vmdk_read_cid(BlockDriverState *bs, int parent)
@@ -111,11 +132,11 @@ static uint32_t vmdk_read_cid(BlockDriverState
*bs, int parent)
uint32_t cid;
const char *p_name, *cid_str;
size_t cid_str_size;
+BDRVVmdkState *s = bs->opaque;
+int desc_offset = s->has_descriptor_file ? 0 : 0x200;
-/* the descriptor offset = 0x200 */
-if (bdrv_pread(bs->file, 0x200, desc, DESC_SIZE) != DESC_SIZE)
+if (bdrv_pread(bs->file, desc_offset, desc, DESC_SIZE) != DESC_SIZE)
return 0;
-
if (parent) {
cid_str = "parentCID";
cid_str_size = sizeof("parentCID");
@@ -128,19 +149,52 @@ static uint32_t vmdk_read_cid(BlockDriverState
*bs, int parent)
p_name += cid_str_size;
sscanf(p_name,"%x",&cid);
}
-
return cid;
}
+#ifdef _WIN32
+static int64_t get_file_size(const char *filename)
+{
+typedef DWORD (WINAPI * get_compressed_t)
+(const char *filename, DWORD *high);
+get_compressed_t get_compressed;
+struct _stati64 st;
+
+/* WinNT support GetCompressedFileSize to determine allocate size */
+get_compressed = (get_compressed_t)
+GetProcAddress(GetModuleHandle("kernel32"), "GetCompressedFileSizeA");
+if (get_compressed) {
+DWORD high, low;
+low = get_compressed(filename, &high);
+if (low != 0xlu || GetLastError() == NO_ERROR)
+return (((int64_t) high) << 32) + low;
+}
+
+if (_stati64(filename, &st) < 0)
+return -1;
+return st.st_size;
+}
+#else
+static int64_t get_file_size(const char *filename)
+{
+struct stat st;
+if (stat(filename, &st) < 0)
+return -1;
+return st.st_size;
+}
+#endif
+
static int vmdk_write_cid(BlockDriverState *bs, uint32_t cid)
{
char desc[DESC_SIZE], tmp_desc[DESC_SIZE];
char *p_name, *tmp_str;
-
-/* the descriptor offset = 0x200 */
-if (bdrv_pread(bs->file, 0x200, desc, DESC_SIZE) != DESC_SIZE)
+BDRVVmdkState * s = bs->opaque;
+int desc_offset = s->has_descriptor_file ? 0 : 0x200;
+int desc_size = s->has_descript
Re: [Qemu-devel] [RFC] darwin: work around sigfd
On 05/29/2011 06:50 PM, Andreas Färber wrote: Am 08.05.2011 um 11:15 schrieb Andreas Färber: Am 05.05.2011 um 15:15 schrieb Alexander Graf: On 05.05.2011, at 14:56, Paolo Bonzini wrote: On 05/05/2011 11:36 AM, Alexander Graf wrote: When running qemu-system on Darwin, the vcpu processes guest code, but I don't get to see anything on the cocoa screen. Out of curiosity, does it work with iothread? Seems to work with -nographic, yes. With cocoa it doesn't seem as happy :o. It certainly gets a lot further than without. -nographic has issues with --enable-io-thread, too. Ping? The patch is obviously masking the real issue, I don't think Alex meant it to be applied. I would really like to look at iothread under Mac OS X, but I just don't have the time right now. Paolo
Re: [Qemu-devel] [PATCH 2/3] QMP: Add BLOCK_MEDIA_EJECT event documentation
Am 27.05.2011 21:31, schrieb Luiz Capitulino:
> Signed-off-by: Luiz Capitulino
> ---
> QMP/qmp-events.txt | 18 ++
> 1 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
> index 0ce5d4e..d53c129 100644
> --- a/QMP/qmp-events.txt
> +++ b/QMP/qmp-events.txt
> @@ -1,6 +1,24 @@
> QEMU Monitor Protocol Events
>
>
> +BLOCK_MEDIA_EJECT
> +-
> +
> +Emitted when a removable disk media (such as a CDROM or floppy) is ejected.
> +
> +Data:
> +
> +- "device": device name (json-string)
> +
> +Example:
> +
> +{ "event": "BLOCK_MEDIA_EJECT",
> +"data": { "device": "ide1-cd0" },
> +"timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
> +
> +NOTE: A disk media can be ejected by the guest or by monitor commands (such
> +as "eject" and "change")
The monitor command 'eject' already caused a lot of confusion, please
don't make the same mistake in this event name. Even though I know more
or less what eject can mean in qemu, I'm not sure what "eject" means for
you in the context of this event.
The 'eject' monitor command means that the image is closed and the
BlockDriverState doesn't point to any image file any more. And then
there's bdrv_eject(), which is what the guest can do, and it's about the
virtual tray status.
Having a single event for both doesn't make sense because they are
fundamentally different. Something like BLOCKDEV_CLOSE would be the
right name for the 'eject' monitor command and maybe something like
BLOCKDEV_TRAY_STATUS for the other one.
Kevin
Re: [Qemu-devel] [PATCH 3/7] cpu model bug fixes and definition corrections: Add kvm emulated x2apic flag to config defined cpu models
On Sat, May 28, 2011 at 04:39:13AM -0400, Jan Kiszka wrote: > Jörg, how to deal with -enable-nesting in qemu-kvm to align behavior > with upstream? My personal preference is to just remove it. In upstream-qemu it is enabled/disabled by +/-svm. -enable-nesting is just a historic thing which can be wiped out. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
Re: [Qemu-devel] Qcow2
Hello Stefan, I can see some error messages May 30 11:36:49 sd0005srv01 libvirtd: 11:36:49.044: error : internal error Timed out while reading console log output May 30 11:36:49 sd0005srv01 libvirtd: 11:36:49.044: error : internal error unable to start guest: I am using ubuntu 9.04 Thanks, -Arun -Original Message- From: Stefan Hajnoczi [mailto:stefa...@gmail.com] Sent: Friday, May 20, 2011 12:35 AM To: Arun Sasi V (WI01 - Manage IT) Cc: stefa...@linux.vnet.ibm.com; qemu-devel@nongnu.org; libvirt-us...@redhat.com Subject: Re: [Qemu-devel] Qcow2 On Thu, May 19, 2011 at 3:24 PM, wrote: > I couldn't find any error when I do consistency check on the image file... Good, so there are no problems with your data. > What can be the reason for not starting the VM. Did you find any more error messages besides the sound related errors in /var/log/libvirt/qemu/.log? > Here I am suspecting when the base server go for reboot lesser image will start and it cached and larger image will take more time to create the cache... > > Was this correct... if yes could you please help me how to increase the caching... No, there is no "cache creation". There is no startup delay for qcow2 image files. Stefan Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
Re: [Qemu-devel] [PATCH uq/master V2] kvm: Add CPUID support for VIA CPU
>From brill...@viatech.com.cn
Hi, Jan
Thank you for you review and guide.
I have fixed the bugs and re-generated a clean patch which has
been checked. It can be compiled
without any error and work normally.
The patch v3 is here now.
Signed-off-by: BrillyWu
Signed-off-by: KaryJin
---
target-i386/cpu.h |7 +++
target-i386/cpuid.c | 52 ++--
target-i386/kvm.c | 15 +++
3 files changed, 72 insertions(+), 2 deletions(-)
--- a/target-i386/cpu.h 2011-05-30 16:20:57.261342707 +0800
+++ b/target-i386/cpu.h 2011-05-30 10:41:45.704533001 +0800
@@ -441,6 +441,10 @@
#define CPUID_VENDOR_AMD_2 0x69746e65 /* "enti" */
#define CPUID_VENDOR_AMD_3 0x444d4163 /* "cAMD" */
+#define CPUID_VENDOR_VIA_1 0x746e6543 /* "Cent" */
+#define CPUID_VENDOR_VIA_2 0x48727561 /* "aurH" */
+#define CPUID_VENDOR_VIA_3 0x736c7561 /* "auls" */
+
#define CPUID_MWAIT_IBE (1 << 1) /* Interrupts can exit capability */
#define CPUID_MWAIT_EMX (1 << 0) /* enumeration supported */
@@ -730,6 +734,9 @@ typedef struct CPUX86State {
uint32_t cpuid_ext3_features;
uint32_t cpuid_apic_id;
int cpuid_vendor_override;
+/* Store the results of Centaur's CPUID instructions */
+uint32_t cpuid_xlevel2;
+uint32_t cpuid_ext4_features;
/* MTRRs */
uint64_t mtrr_fixed[11];
--- a/target-i386/cpuid.c 2011-05-30 16:20:57.261342707 +0800
+++ b/target-i386/cpuid.c 2011-05-30 15:07:18.794532910 +0800
@@ -230,6 +230,9 @@ typedef struct x86_def_t {
char model_id[48];
int vendor_override;
uint32_t flags;
+/* Store the results of Centaur's CPUID instructions */
+uint32_t ext4_features;
+uint32_t xlevel2;
} x86_def_t;
#define I486_FEATURES (CPUID_FP87 | CPUID_VME | CPUID_PSE)
@@ -522,6 +525,18 @@ static int cpu_x86_fill_host(x86_def_t *
cpu_x86_fill_model_id(x86_cpu_def->model_id);
x86_cpu_def->vendor_override = 0;
+/* Call Centaur's CPUID instruction. */
+if (x86_cpu_def->vendor1 == CPUID_VENDOR_VIA_1 &&
+x86_cpu_def->vendor2 == CPUID_VENDOR_VIA_2 &&
+x86_cpu_def->vendor3 == CPUID_VENDOR_VIA_3) {
+host_cpuid(0xC000, 0, &eax, &ebx, &ecx, &edx);
+if (eax >= 0xC001) {
+/* Support VIA max extended level */
+x86_cpu_def->xlevel2 = eax;
+host_cpuid(0xC001, 0, &eax, &ebx, &ecx, &edx);
+x86_cpu_def->ext4_features = edx;
+}
+}
/*
* Every SVM feature requires emulation support in KVM - so we can't just
@@ -855,6 +870,8 @@ int cpu_x86_register (CPUX86State *env,
env->cpuid_xlevel = def->xlevel;
env->cpuid_kvm_features = def->kvm_features;
env->cpuid_svm_features = def->svm_features;
+env->cpuid_ext4_features = def->ext4_features;
+env->cpuid_xlevel2 = def->xlevel2;
if (!kvm_enabled()) {
env->cpuid_features &= TCG_FEATURES;
env->cpuid_ext_features &= TCG_EXT_FEATURES;
@@ -1035,8 +1052,17 @@ void cpu_x86_cpuid(CPUX86State *env, uin
{
/* test if maximum index reached */
if (index & 0x8000) {
-if (index > env->cpuid_xlevel)
-index = env->cpuid_level;
+if (index > env->cpuid_xlevel) {
+if (env->cpuid_xlevel2 > 0) {
+/* Handle the Centaur's CPUID instruction. */
+if (index > env->cpuid_xlevel2) {
+index = env->cpuid_xlevel2;
+} else if (index < 0xC000) {
+index = env->cpuid_xlevel;
+}
+} else
+index = env->cpuid_xlevel;
+}
} else {
if (index > env->cpuid_level)
index = env->cpuid_level;
@@ -1231,6 +1257,28 @@ void cpu_x86_cpuid(CPUX86State *env, uin
*edx = 0;
}
break;
+case 0xC000:
+*eax = env->cpuid_xlevel2;
+*ebx = 0;
+*ecx = 0;
+*edx = 0;
+break;
+case 0xC001:
+/* Support for VIA CPU's CPUID instruction */
+*eax = env->cpuid_version;
+*ebx = 0;
+*ecx = 0;
+*edx = env->cpuid_ext4_features;
+break;
+case 0xC002:
+case 0xC003:
+case 0xC004:
+/* Reserved for the future, and now filled with zero */
+*eax = 0;
+*ebx = 0;
+*ecx = 0;
+*edx = 0;
+break;
default:
/* reserved values: zero */
*eax = 0;
--- a/target-i386/kvm.c 2011-05-30 16:21:05.431342033 +0800
+++ b/target-i386/kvm.c 2011-05-30 10:16:03.284532914 +0800
@@ -482,6 +482,21 @@ int kvm_arch_init_vcpu(CPUState *env)
cpu_x86_cpuid(env, i, 0, &c->eax, &c->ebx, &c->ecx, &c->edx);
}
+/* Call Centaur's CPUID instructions they are supported. */
+if (env->cpuid_xlevel2 > 0) {
+env->cpuid_ext4_features &=
+kvm_arch_get_supported_cpuid(env, 0xC001, 0, R_EDX);
+cpu_x
Re: [Qemu-devel] [PATCH] #include cleanliness
On 05/30/2011 01:06 AM, Anthony Liguori wrote: On 05/19/2011 09:17 AM, Avi Kivity wrote: My mother always told me to explicitly #include any headers need to compile a file, instead of relying on other #includes to bring them in. This patch fixes up targphys.h and cpu-common.h in this regard. Signed-off-by: Avi Kivity --- cpu-common.h |4 targphys.h |2 ++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/cpu-common.h b/cpu-common.h index 151c32c..2009adc 100644 --- a/cpu-common.h +++ b/cpu-common.h @@ -18,6 +18,10 @@ #include "bswap.h" #include "qemu-queue.h" +#include "qemu-common.h" + +#include qemu-common.h should include stdbool. The idea behind qemu-common.h is to avoid direct includes to help with portability. Okay. But note qemu-common.h #includes cpu.h #includes qemu-common.h... I think osdep.h matches the "help with portability" label better, no? -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] virtio scsi host draft specification, v2
On 05/28/2011 09:33 PM, Stefan Hajnoczi wrote:
Virtqueues
0:control transmitq
1:control receiveq
I find these names weird because control commands are actually processed
and completed on the transmitq. The receiveq is only for receiving
asynchronous notifications.
0:control commandq
1:control eventq
This seems clearer to me although it's not as generic as
transmit/receive if we want to extend its semantics in the future.
I took the names from virtio-serial, IIRC. But now I simplified your
proposal further to controlq/eventq.
The driver queues requests to the virtqueue, and they are used by the device
(not necessarily in order).
What do you mean by "no necessarily in order"? Doesn't the SAM already
define the available ordering semantics and how the target processes
requests - I think there is no need to mention anything here.
Right.
Requests have the following format:
struct virtio_scsi_req_cmd {
u8 lun[8];
u64 id;
u8 task_attr;
u8 prio;
u8 crn;
u32 num_dataout, num_datain;
These fields can be discovered from the in and out counts that virtio
provides. They seem redundant to me.
I'm not sure, perhaps in the future more variable-sized fields may be
added. I added a note that requests will be failed if the driver
detects inconsistencies between the actual number of buffers, and the
count specified in num_dataout/num_datain.
SAMr4 5.1 The Execute Command procedure call:
"The CRN value zero shall be reserved for use as defined by the SCSI
transport protocol."
FWIW the SRP spec simply doesn't include CRN and I think we could do the
same. I don't know what it is actually used for in other transports...
I wasn't sure of what would happen in the case of SCSI passthrough to
protocols that do use CRN. It seems "free" to leave it in.
The request shall have num_dataout read-only data buffers and
num_datain write-only data buffers. One of these two values must be
zero if the VIRTIO_SCSI_F_INOUT has not been negotiated.
What happens if this VIRTIO_SCSI_F_INOUT has not been negotiated and
both values are non-zero? Perhaps the request should be immediately
returned with response = VIRTIO_SCSI_S_FAILURE.
I think we should define behavior for all inputs - otherwise we end up
with QEMU-side code that calls abort() which is bad ;).
I agree, and I made the change.
The outcome of the task management function is written by the device
in the response field. Return values map 1-to-1 with those defined
in SAM.
We have no transport-specific response field here like we do with CDBs.
I guess this is okay because the SAM defines SERVICE DELIVERY OR TARGET
FAILURE, which we could use if there is a problem.
Yes, that is VIRTIO_SCSI_S_FAILURE.
The control receiveq is used by the device to report information on
logical units that are attached to it. The driver should always
leave a few (?) buffers ready in the control receiveq. The device may
"The driver should always leave buffers ready in the control receiveq"
Also, I think it should say "the device must drop events if it finds no
buffer ready". The spec goes into detail on how to notify about dropped
events, using "must" instead of "may" seems right.
"Must" seems too strong. Dropped events are a racy event, so it is not
really possible to guve any guarantee. I changed it to "will" though.
Paolo
Re: [Qemu-devel] Qcow2
Hello Team, Please help me to solve this... Find the below error May 30 12:21:29 sd0005srv01 kernel: [19836592.317217] device vnet0 entered promiscuous mode May 30 12:21:29 sd0005srv01 kernel: [19836592.319449] br0: port 2(vnet0) entering learning state May 30 12:21:29 sd0005srv01 nm-system-settings:SCPlugin-Ifupdown: device added (udi: /org/freedesktop/Hal/devices/net_ce_1b_36_05_70_14, iface: vnet0): not well known May 30 12:21:30 sd0005srv01 avahi-daemon[3449]: Registering new address record for fe80::cc1b:36ff:fe05:7014 on vnet0.*. May 30 12:21:33 sd0005srv01 nm-system-settings: Added default wired connection 'Auto vnet0' for /org/freedesktop/Hal/devices/net_ce_1b_36_05_70_14 May 30 12:21:38 sd0005srv01 kernel: [19836601.316008] br0: topology change detected, propagating May 30 12:21:38 sd0005srv01 kernel: [19836601.316014] br0: port 2(vnet0) entering forwarding state May 30 12:21:39 sd0005srv01 kernel: [19836602.949751] vnet0: no IPv6 routers present May 30 12:21:59 sd0005srv01 libvirtd: 12:21:59.278: error : internal error Timed out while reading console log output May 30 12:21:59 sd0005srv01 libvirtd: 12:21:59.278: error : internal error unable to start guest: May 30 12:21:59 sd0005srv01 avahi-daemon[3449]: Withdrawing address record for fe80::cc1b:36ff:fe05:7014 on vnet0. May 30 12:21:59 sd0005srv01 kernel: [19836622.479659] br0: port 2(vnet0) entering disabled state May 30 12:21:59 sd0005srv01 kernel: [19836622.493771] device vnet0 left promiscuous mode May 30 12:21:59 sd0005srv01 kernel: [19836622.493773] br0: port 2(vnet0) entering disabled state May 30 12:21:59 sd0005srv01 nm-system-settings:SCPlugin-Ifupdown: devices removed (udi: /org/freedesktop/Hal/ Thanks, -Arun -Original Message- From: Arun Sasi V (WI01 - Manage IT) Sent: Monday, May 30, 2011 2:24 PM To: 'Stefan Hajnoczi' Cc: 'stefa...@linux.vnet.ibm.com'; 'qemu-devel@nongnu.org'; 'libvirt-us...@redhat.com' Subject: RE: [Qemu-devel] Qcow2 Hello Stefan, I can see some error messages May 30 11:36:49 sd0005srv01 libvirtd: 11:36:49.044: error : internal error Timed out while reading console log output May 30 11:36:49 sd0005srv01 libvirtd: 11:36:49.044: error : internal error unable to start guest: I am using ubuntu 9.04 Thanks, -Arun -Original Message- From: Stefan Hajnoczi [mailto:stefa...@gmail.com] Sent: Friday, May 20, 2011 12:35 AM To: Arun Sasi V (WI01 - Manage IT) Cc: stefa...@linux.vnet.ibm.com; qemu-devel@nongnu.org; libvirt-us...@redhat.com Subject: Re: [Qemu-devel] Qcow2 On Thu, May 19, 2011 at 3:24 PM, wrote: > I couldn't find any error when I do consistency check on the image file... Good, so there are no problems with your data. > What can be the reason for not starting the VM. Did you find any more error messages besides the sound related errors in /var/log/libvirt/qemu/.log? > Here I am suspecting when the base server go for reboot lesser image will start and it cached and larger image will take more time to create the cache... > > Was this correct... if yes could you please help me how to increase the caching... No, there is no "cache creation". There is no startup delay for qcow2 image files. Stefan Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
[Qemu-devel] [PATCH 0/2] Fix unused-but-set-variable warnings
Hi, Here are Hans's patches split and with the various issues that were pointed out fixed. I'm not sure how I'm supposed to handle acks, original author, ... when reworking patches this way, let me know if I should proceed differently. Christophe Christophe Fergeau (2): tcg: Fix unused-but-set-variable warning kvm: Fix unused-but-set-variable warning target-i386/kvm.c |3 +-- tcg/tcg.c |4 ++-- 2 files changed, 3 insertions(+), 4 deletions(-) -- 1.7.5.2
[Qemu-devel] [PATCH 1/2] tcg: Fix unused-but-set-variable warning
Based on a patch from Hans de Goede
This warning is new in gcc 4.6.
Acked-by: Amit Shah
---
tcg/tcg.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tcg/tcg.c b/tcg/tcg.c
index 8748c05..e53b54c 100644
--- a/tcg/tcg.c
+++ b/tcg/tcg.c
@@ -585,7 +585,7 @@ void tcg_register_helper(void *func, const char *name)
void tcg_gen_callN(TCGContext *s, TCGv_ptr func, unsigned int flags,
int sizemask, TCGArg ret, int nargs, TCGArg *args)
{
-#ifdef TCG_TARGET_I386
+#if defined(TCG_TARGET_I386) && TCG_TARGET_REG_BITS < 64
int call_type;
#endif
int i;
@@ -612,7 +612,7 @@ void tcg_gen_callN(TCGContext *s, TCGv_ptr func, unsigned
int flags,
*gen_opc_ptr++ = INDEX_op_call;
nparam = gen_opparam_ptr++;
-#ifdef TCG_TARGET_I386
+#if defined(TCG_TARGET_I386) && TCG_TARGET_REG_BITS < 64
call_type = (flags & TCG_CALL_TYPE_MASK);
#endif
if (ret != TCG_CALL_DUMMY_ARG) {
--
1.7.5.2
[Qemu-devel] [PATCH 2/2] kvm: Fix unused-but-set-variable warning
Based on a patch from Hans de Goede
This warning is new in gcc 4.6.
Acked-by: Amit Shah
---
target-i386/kvm.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index faedc6c..58a70bc 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -970,7 +970,7 @@ static int kvm_get_xsave(CPUState *env)
#ifdef KVM_CAP_XSAVE
struct kvm_xsave* xsave;
int ret, i;
-uint16_t cwd, swd, twd, fop;
+uint16_t cwd, swd, twd;
if (!kvm_has_xsave()) {
return kvm_get_fpu(env);
@@ -986,7 +986,6 @@ static int kvm_get_xsave(CPUState *env)
cwd = (uint16_t)xsave->region[0];
swd = (uint16_t)(xsave->region[0] >> 16);
twd = (uint16_t)xsave->region[1];
-fop = (uint16_t)(xsave->region[1] >> 16);
env->fpstt = (swd >> 11) & 7;
env->fpus = swd;
env->fpuc = cwd;
--
1.7.5.2
Re: [Qemu-devel] Webcams under KVM and Linux
Hi, I was told I could try to add a complete host controller to the guest, but am not entirely sure I understand what that means? Looking for specifics? Is there a suggestion for doing this during install of the KVM guest, or can this be done while the guest is running, or otherwise? Independent of the ongoing EHCI work, I remember a patch specifically for webcams a while ago, try searching the archives for V4L. Latest master (aka upcoming 0.15) has a bunch of iso xfer fixes merged and using usb 1.1 webcams with usb-host should work reasonable well. Using usb 2.0 cams with usb-host obviously depend on upcoming EHCI for usb 2.0 support. There are also some glitches not tracked down yet. The usb 2.0 cam in built into my Lenovo T500 starts streaming but stops quickly (after 1-2 frames) for not-yet known reasons. I think people are also working on camera emulation, i.e. pass any (even non-usb) v4l devices as usb webcam to the guest. No idea what the status here is. cheers, Gerd
Re: [Qemu-devel] [PATCH uq/master V2] kvm: Add CPUID support for VIA CPU
On 2011-05-30 10:59, BrillyWu wrote: > From brill...@viatech.com.cn > Hi, Jan > Thank you for you review and guide. > I have fixed the bugs and re-generated a clean patch which has > been checked. It can be compiled > without any error and work normally. > The patch v3 is here now. The above text can't be used as a commit log, so this needs to be fixed. Moreover, your patch still contains at least on style issues scripts/checkpatch.pl should have caught. Are you sure you ran it? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 0/2] Fix unused-but-set-variable warnings
On (Mon) 30 May 2011 [12:28:01], Christophe Fergeau wrote: > Hi, > > Here are Hans's patches split and with the various issues that were pointed > out fixed. I'm not sure how I'm supposed to handle acks, original author, > ... when reworking patches this way, let me know if I should proceed > differently. You should keep From: as the same person, keep his Signed-off-by, add your Signed-off-by and mention what you have changed in the series. Thanks for re-sending this, btw. Amit
[Qemu-devel] Hello Would You Like To Earn
Hello qemu-devel Would you like to earn an extra $200 everyday?, for just 45 minutes work? You could quit your job and make double the money at home working for yourself. visit->http:tinyurl.com/3brnlpx Regards, Sharon Burns Survey Human Resources Dept.
Re: [Qemu-devel] [PATCH] VMDK: add monolithic flat image support
Am 30.05.2011 09:49, schrieb Fam Zheng:
> VMDK multiple file images can not be recognized for now. This patch is
> adding monolithic flat support to it, that is the image type with two
> files, one text descriptor file and a plain data file. This type of
> image can be created in VMWare, with the options "allocate all disk
> space now" and "store virtual disk as a single file" checked.
>
> A VmdkExtent structure is introduced to hold the image "extent"
> information, which makes further adding multi extents support of VMDK
> easy. An image creating option "flat" is added for creating flat
> (preallocated) image.
>
> Signed-off-by: Feiran (Fam) Zheng
> ---
> block/vmdk.c | 686
> +-
> block_int.h |2 +
> qemu-img.c | 12 +-
> 3 files changed, 542 insertions(+), 158 deletions(-)
>
> diff --git a/block/vmdk.c b/block/vmdk.c
> index 8fc9d67..726ad3a 100644
> --- a/block/vmdk.c
> +++ b/block/vmdk.c
> @@ -30,6 +30,8 @@
> #define VMDK3_MAGIC (('C' << 24) | ('O' << 16) | ('W' << 8) | 'D')
> #define VMDK4_MAGIC (('K' << 24) | ('D' << 16) | ('M' << 8) | 'V')
>
> +#define VMDK_FLAT_BACKING 0
Is there any specific reason why it's useful to enable the corresponding
code only conditionally? Generally no code that is #ifdefed out should
be committed.
> +
> typedef struct {
> uint32_t version;
> uint32_t flags;
> @@ -60,7 +62,10 @@ typedef struct {
>
> #define L2_CACHE_SIZE 16
>
> -typedef struct BDRVVmdkState {
> +typedef struct VmdkExtent {
> +BlockDriverState *file;
> +int flat;
bool?
And just to make sure I understand the terminology: flat means !sparse,
i.e. doesn't have L1/L2 tables?
> +int64_t sectors;
> int64_t l1_table_offset;
> int64_t l1_backup_table_offset;
> uint32_t *l1_table;
> @@ -73,8 +78,15 @@ typedef struct BDRVVmdkState {
> uint32_t l2_cache_offsets[L2_CACHE_SIZE];
> uint32_t l2_cache_counts[L2_CACHE_SIZE];
>
> -unsigned int cluster_sectors;
> uint32_t parent_cid;
> +unsigned int cluster_sectors;
> +} VmdkExtent;
> +
> +typedef struct BDRVVmdkState {
> +int has_descriptor_file;
bool
> +int extent_size;
Is this the array size of extents? If so, num_extents would be a better
name.
> +int cid_update;
> +VmdkExtent *extents;
> } BDRVVmdkState;
>
> typedef struct VmdkMetaData {
> @@ -88,21 +100,30 @@ typedef struct VmdkMetaData {
> static int vmdk_probe(const uint8_t *buf, int buf_size, const char *filename)
> {
> uint32_t magic;
> -
> +char *cid_p, *ct_p, *extent_p;
> +char cid_str[] = "CID";
> +char ct_str[] = "createType";
> +char extent_str[] = "RW";
Don't use variables for this but just use the literal strings below.
> if (buf_size < 4)
> return 0;
> magic = be32_to_cpu(*(uint32_t *)buf);
> if (magic == VMDK3_MAGIC ||
> -magic == VMDK4_MAGIC)
> +magic == VMDK4_MAGIC) {
> return 100;
> -else
> +} else {
> +cid_p = strstr((char *)buf, cid_str);
> +ct_p = strstr((char *)buf, ct_str);
> +extent_p = strstr((char *)buf, extent_str);
> +if (cid_p && ct_p && extent_p)
> +return 100;
> +}
> return 0;
The return 0; isn't correctly indented any more.
> }
>
> #define CHECK_CID 1
>
> #define SECTOR_SIZE 512
> -#define DESC_SIZE 20*SECTOR_SIZE // 20 sectors of 512 bytes each
> +#define DESC_SIZE (20 * SECTOR_SIZE)// 20 sectors of 512 bytes each
> #define HEADER_SIZE 512 // first sector of 512 bytes
>
> static uint32_t vmdk_read_cid(BlockDriverState *bs, int parent)
> @@ -111,11 +132,11 @@ static uint32_t vmdk_read_cid(BlockDriverState
> *bs, int parent)
> uint32_t cid;
> const char *p_name, *cid_str;
> size_t cid_str_size;
> +BDRVVmdkState *s = bs->opaque;
> +int desc_offset = s->has_descriptor_file ? 0 : 0x200;
>
> -/* the descriptor offset = 0x200 */
> -if (bdrv_pread(bs->file, 0x200, desc, DESC_SIZE) != DESC_SIZE)
> +if (bdrv_pread(bs->file, desc_offset, desc, DESC_SIZE) != DESC_SIZE)
> return 0;
> -
> if (parent) {
> cid_str = "parentCID";
> cid_str_size = sizeof("parentCID");
> @@ -128,19 +149,52 @@ static uint32_t vmdk_read_cid(BlockDriverState
> *bs, int parent)
> p_name += cid_str_size;
> sscanf(p_name,"%x",&cid);
> }
> -
> return cid;
> }
>
> +#ifdef _WIN32
> +static int64_t get_file_size(const char *filename)
> +{
> +typedef DWORD (WINAPI * get_compressed_t)
> +(const char *filename, DWORD *high);
> +get_compressed_t get_compressed;
> +struct _stati64 st;
> +
> +/* WinNT support GetCompressedFileSize to determine allocate size */
> +get_compressed = (get_compressed_t)
> +GetProcAddress(GetModuleHandle("kernel32"),
> "GetCompressedFileSizeA");
> +if (get_compressed) {
> +DWORD high, low;
> +low = get_com
Re: [Qemu-devel] [PATCH] VMDK: add monolithic flat image support
Am 30.05.2011 09:49, schrieb Fam Zheng: > VMDK multiple file images can not be recognized for now. This patch is > adding monolithic flat support to it, that is the image type with two > files, one text descriptor file and a plain data file. This type of > image can be created in VMWare, with the options "allocate all disk > space now" and "store virtual disk as a single file" checked. > > A VmdkExtent structure is introduced to hold the image "extent" > information, which makes further adding multi extents support of VMDK > easy. An image creating option "flat" is added for creating flat > (preallocated) image. > > Signed-off-by: Feiran (Fam) Zheng Ok, seems I commented on so many details that in the end I forgot to add the general comment. :-) I think this patch is too big to be well reviewable. You should always try to make only one logical change in one patch. I think you can split this at least in two parts: First adding the VmdkExtent data structure without adding any new functionality, and second adding the monolithic flat support. Depending on how big the second patch is, you can split it further into image creation and the rest (or any other split that you feel is natural). On two or three hunks I commented that they probably aren't required for monolithic flat support. They should be separate bugfix or cleanup patches. Kevin
Re: [Qemu-devel] Webcams under KVM and Linux
Exactly what my webcam does is: Takes a frame from ANY available V4L2 device (/dev/video0), caches it, and sends it completely to the guest before requesting any other frame. With this way you need your host driver loaded, but you will get never a blackout. What it happens is a thing commonly known in game emulators (like for example ePSX) as framedrop, that is, you get a slower framerate but not blackouts. The guest sees a common USB Video Class Device webcam with no controls (this can be enhanced easily), so basically you cannot change any parameter. However all the webcams I tested automatically managed that in the firmware with no intervention from any of the drivers (host or guest), changing white balance and brightness to the adequate values. You can see it working without KVM in: http://www.youtube.com/watch?v=_Yo9TWPDXCo http://www.youtube.com/watch?v=fzGYvjZzx6E The webcam emulation works with TCG (without KVM), albeit slower, enough to do videoconference because of the following: Using direct connection method (USB passthrough) even when the ISO xfers and ECHI 2.0 are completely emulated will always find the following: the host is faster than the guest, so the real webcam will always be streaming faster than the guest can process it. Frames are sent in pieces, and if the frame does not arrive completely from start to end on all pieces the guest will blackout, and continue black until it receives a complete frame. With fast webcams, like 60 fps ones, this will happen so commonly that there will be no image at all. You can easily see this in VMWare, Parallels or VirtualBox, all of them emulate ISO xfers and EHCI 2.0 and when using a webcam it's not really practical. Framedrop prevents that. From the 60 frames sent in a second by the host, if the guest can process only 10, it will receive 10 complete frames, and see the webcam as a 10fps one. That's atomic. Also my patch supports, as I already said, any V4L2 device including webcams, DV cameras, TV tuners from any kind of interface be it Firewire, USB, PCI, Serial, AGP, so on. El 29/05/2011, a las 15:03, Peter Baitz escribió: > Hello Natalia and Andreas, > > Thank you for the replies and suggestions. I will lookup V4L. > > Natalia, > > So your patch creates a generic webcam under KVM/Qemu to allow many webcams > to work? > > My only concern is the following: I use specific Philips webcams, and one > in particular has a long exposure modification that the PWC driver (Fedora 11 > guest on Fedora 15 host) coupled with Qastrocam-G2 (v4.9) allows the > "shutter" to remain open through USB control of the LED. If the guest > restorts to using a generic webcam driver, I think this would preclude > functionality that the native driver supports ? > > Also, can you tell me - when KVM is running my guest, should the PWC webcam > driver be loaded and/or the /dev/video0 on the HOST (F15), versus the guest > (F11) ? I am confused as to which components are supposed to be enabled or > disabled while running the guest webcam. What I see is when I enable the > webcam USB device in KVM, it appears to disable the /dev/video0 on the host > an brings it up in the guest. And the pwc driver loads and remains on both > host and guest. > > Peter > > > --- On Sun, 5/29/11, Natalia Portillo wrote: > > From: Natalia Portillo > Subject: Re: [Qemu-devel] Webcams under KVM and Linux > To: "Andreas Färber" > Cc: "Peter Baitz" , "QEMU Developers" > > Date: Sunday, May 29, 2011, 1:53 PM > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > More concretely search for patches sent by me. > > Even when EHCI is finished still is the problem of isochronous transfer not > working well because of timing issues on QEMU. > > My patches overcome the need for ISO transfer and EHCI controllers > completely, as well as providing an universal device to the guest that works > with every Windows >XP, every Linux and even Mac OS X. > > El 29/05/2011, a las 14:37, Andreas Färber escribió: > > > Hello, > > > > Am 29.05.2011 um 15:01 schrieb Peter Baitz: > > > >> > >>> [...] You should notice that it is not just adding > >>> ISOC and USB 2.0 support, but also to prioritize the processing of isoc > >>> packets on a virtual environment, and to provide enough throughput for > >>> video streams > >> > >> [...] Please check the qemu-devel mailing list archive, specifically > >> regarding recent discussions about EHCI (USB 2.0). Some of those threads > >> address isochronous transfer as well. > >> > >> In the meantime, you could also try to assign a complete host controller > >> to the guest to get a webcam working. I tried this a while ago, though the > >> result was only moderately well working here. > > > >> [...] I would indeed like to hear more about what the project is adding to > >> KVM - Qemu to allow video to work with webcams > > [...] > >> I was told I could try to add a complete host controller to the
Re: [Qemu-devel] [PATCH 0/2] Fix unused-but-set-variable warnings
On Mon, May 30, 2011 at 04:23:43PM +0530, Amit Shah wrote: > You should keep From: as the same person, keep his Signed-off-by, add > your Signed-off-by and mention what you have changed in the series. Hans's patches didn't have a S-o-b. I can resend the same patches again with my S-o-b (I'm fine with doing this without Hans's since I came up with exactly the same patches independently from Hans) and detailing the changes from the initial patch. Does that sound good? Christophe pgpmNHpihEPbk.pgp Description: PGP signature
[Qemu-devel] drop -enable-nesting (was: [PATCH 3/7] cpu model bug fixes and definition corrections...)
On 2011-05-30 10:18, Roedel, Joerg wrote: > On Sat, May 28, 2011 at 04:39:13AM -0400, Jan Kiszka wrote: > >> Jörg, how to deal with -enable-nesting in qemu-kvm to align behavior >> with upstream? > > My personal preference is to just remove it. In upstream-qemu it is > enabled/disabled by +/-svm. -enable-nesting is just a historic thing > which can be wiped out. Does any user land depend on it? I guess we have to flag it deprecated first, trigger some console output when it's specified, and then remove it one or more releases later (the same applies to many other qemu-kvm-specific switches). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 3/3] QMP: Introduce the BLOCK_MEDIA_EJECT event
On Sat, 28 May 2011 09:58:24 +0200
Markus Armbruster wrote:
> Luiz Capitulino writes:
>
> > Conforms to the event specification defined in the
> > QMP/qmp-events.txt file.
>
> I'd squash PATCH 2+3.
I agree this would be more logical, but people have complained that it's hard
to review new commands/events when its documentation is hidden or mixed with
code somewhere in the series. I think that make sense.
Maybe, it would be better to copy & paste the documentation in patch 0/0...
> > Please, note the following details:
> >
> > o The event should be emitted only by devices which support the
> >eject operation, which currently are: CDROMs (IDE and SCSI)
> >and floppies
> >
> > o Human monitor commands "eject" and "change" also cause the
> >event to be emitted
> >
> > o The event is only emitted when there's a tray transition from
> >closed to opened. To implement this in the human monitor, we
> >only emit the event if the device is removable and a media is
> >present
>
> Rationale?
This implementation covers the basic use case, which is to let clients know
that an already inserted media has been ejected. I was under the assumption
that this is the most important thing a client wants to know, as it will
have to update its internal state and that only has to be done for the media
it knows about (ie. the ones inserted by the client itself).
But...
> Wouldn't it be easier if we just report tray status change, regardless
> of media?
Yes, this seems to make sense.
> > Signed-off-by: Luiz Capitulino
> > ---
> > block.c| 12
> > block.h|1 +
> > blockdev.c |5 +
> > monitor.c |3 +++
> > monitor.h |1 +
> > 5 files changed, 22 insertions(+), 0 deletions(-)
> >
>
> Copied from PATCH 2 for review purposes:
>
> diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
> index 0ce5d4e..d53c129 100644
> --- a/QMP/qmp-events.txt
> +++ b/QMP/qmp-events.txt
> @@ -1,6 +1,24 @@
> QEMU Monitor Protocol Events
>
>
> +BLOCK_MEDIA_EJECT
> +-
> +
> +Emitted when a removable disk media (such as a CDROM or floppy) is ejected.
> +
> +Data:
> +
> +- "device": device name (json-string)
> +
> +Example:
> +
> +{ "event": "BLOCK_MEDIA_EJECT",
> +"data": { "device": "ide1-cd0" },
> +"timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
> +
> +NOTE: A disk media can be ejected by the guest or by monitor commands (such
> +as "eject" and "change")
> +
>BLOCK_IO_ERROR
>--
>
> The event reports "tray opening". Do we need one for "tray closing" as
> well?
At first I thought it wouldn't be needed (and maybe most use cases don't
require it), but reporting the tray status is more general and easier to do,
so I think it's what I'm going to do.
> > diff --git a/block.c b/block.c
> > index f5014cf..dbe813b 100644
> > --- a/block.c
> > +++ b/block.c
> > @@ -1656,6 +1656,15 @@ int bdrv_is_allocated(BlockDriverState *bs, int64_t
> > sector_num, int nb_sectors,
> > return bs->drv->bdrv_is_allocated(bs, sector_num, nb_sectors, pnum);
> > }
> >
> > +void bdrv_eject_mon_event(const BlockDriverState *bdrv)
> > +{
> > +QObject *data;
> > +
> > +data = qobject_from_jsonf("{ 'device': %s }", bdrv->device_name);
> > +monitor_protocol_event(QEVENT_BLOCK_MEDIA_EJECT, data);
> > +qobject_decref(data);
> > +}
> > +
> > void bdrv_error_mon_event(const BlockDriverState *bdrv,
> >BlockMonEventAction action, int is_read)
> > {
> > @@ -2770,6 +2779,9 @@ int bdrv_eject(BlockDriverState *bs, int eject_flag)
> > ret = 0;
> > }
> > if (ret >= 0) {
> > +if (eject_flag && !bs->tray_open) {
> > +bdrv_eject_mon_event(bs);
> > +}
> > bs->tray_open = eject_flag;
> > }
> >
>
> This covers guest-initiated eject.
>
>
> The event is suppressed when the tray is already open.
Yes, because there's no visible state change.
> The event is not suppressed when the tray is empty, is it? Contradicts
> spec.
Why does it contradicts the spec? No media is ejected if the tray is empty.
But this is probably not going to be an issue when we implement the more
general BLOCK_TRAY_STATUS (or something like it).
> > diff --git a/block.h b/block.h
> > index 1f58eab..e4053dd 100644
> > --- a/block.h
> > +++ b/block.h
> > @@ -50,6 +50,7 @@ typedef enum {
> > BDRV_ACTION_REPORT, BDRV_ACTION_IGNORE, BDRV_ACTION_STOP
> > } BlockMonEventAction;
> >
> > +void bdrv_eject_mon_event(const BlockDriverState *bdrv);
> > void bdrv_error_mon_event(const BlockDriverState *bdrv,
> >BlockMonEventAction action, int is_read);
> > void bdrv_info_print(Monitor *mon, const QObject *data);
> > diff --git a/blockdev.c b/blockdev.c
> > index 6e0eb83..5fd0043 100644
> > --- a/blockdev.c
> > +++ b/blockdev.c
> > @@
Re: [Qemu-devel] [PATCH 2/3] QMP: Add BLOCK_MEDIA_EJECT event documentation
On Mon, 30 May 2011 10:46:07 +0200
Kevin Wolf wrote:
> Am 27.05.2011 21:31, schrieb Luiz Capitulino:
> > Signed-off-by: Luiz Capitulino
> > ---
> > QMP/qmp-events.txt | 18 ++
> > 1 files changed, 18 insertions(+), 0 deletions(-)
> >
> > diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
> > index 0ce5d4e..d53c129 100644
> > --- a/QMP/qmp-events.txt
> > +++ b/QMP/qmp-events.txt
> > @@ -1,6 +1,24 @@
> > QEMU Monitor Protocol Events
> >
> >
> > +BLOCK_MEDIA_EJECT
> > +-
> > +
> > +Emitted when a removable disk media (such as a CDROM or floppy) is ejected.
> > +
> > +Data:
> > +
> > +- "device": device name (json-string)
> > +
> > +Example:
> > +
> > +{ "event": "BLOCK_MEDIA_EJECT",
> > +"data": { "device": "ide1-cd0" },
> > +"timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
> > +
> > +NOTE: A disk media can be ejected by the guest or by monitor commands (such
> > +as "eject" and "change")
>
> The monitor command 'eject' already caused a lot of confusion, please
> don't make the same mistake in this event name. Even though I know more
> or less what eject can mean in qemu, I'm not sure what "eject" means for
> you in the context of this event.
I'll change it to report the tray status instead, as suggested by Markus.
> The 'eject' monitor command means that the image is closed and the
> BlockDriverState doesn't point to any image file any more. And then
> there's bdrv_eject(), which is what the guest can do, and it's about the
> virtual tray status.
>
> Having a single event for both doesn't make sense because they are
> fundamentally different. Something like BLOCKDEV_CLOSE would be the
> right name for the 'eject' monitor command and maybe something like
> BLOCKDEV_TRAY_STATUS for the other one.
Well, there are two problems here. First, we shouldn't report something
like BLOCKDEV_CLOSE because closing a BlockDriverState is something
internal to qemu that clients/users shouldn't know about. The second
problem is that, unfortunately, clients do use "eject" to eject a
removable media. Actually it's _the_ interface available for that, so
not emitting the event there will probably confuse clients as much as
not having the event at all.
Maybe, a better solution is to fix eject to really eject the media
instead of closing its BlockDriverState and drop the event from the change
command.
Re: [Qemu-devel] drop -enable-nesting (was: [PATCH 3/7] cpu model bug fixes and definition corrections...)
On Mon, May 30, 2011, Jan Kiszka wrote about "drop -enable-nesting (was: [PATCH 3/7] cpu model bug fixes and definition corrections...)": > On 2011-05-30 10:18, Roedel, Joerg wrote: > > On Sat, May 28, 2011 at 04:39:13AM -0400, Jan Kiszka wrote: > > > >> Jצrg, how to deal with -enable-nesting in qemu-kvm to align behavior > >> with upstream? > > > > My personal preference is to just remove it. In upstream-qemu it is > > enabled/disabled by +/-svm. -enable-nesting is just a historic thing > > which can be wiped out. "-enable-nesting" could remain as a synonym for enabling either VMX or SVM in the guest, depending on what was available in the host (because KVM now supports both nested SVM and nested VMX, but not SVM-on-VMX or vice versa). -- Nadav Har'El| Monday, May 30 2011, 26 Iyyar 5771 n...@math.technion.ac.il |- Phone +972-523-790466, ICQ 13349191 |Software is like sex, it is better when http://nadav.harel.org.il |it's free -- Linus Torvalds
Re: [Qemu-devel] [PATCH 3/3] QMP: Introduce the BLOCK_MEDIA_EJECT event
Luiz Capitulino writes:
> On Sat, 28 May 2011 09:58:24 +0200
> Markus Armbruster wrote:
>
>> Luiz Capitulino writes:
>>
>> > Conforms to the event specification defined in the
>> > QMP/qmp-events.txt file.
>>
>> I'd squash PATCH 2+3.
>
> I agree this would be more logical, but people have complained that it's hard
> to review new commands/events when its documentation is hidden or mixed with
> code somewhere in the series. I think that make sense.
>
> Maybe, it would be better to copy & paste the documentation in patch 0/0...
>
>> > Please, note the following details:
>> >
>> > o The event should be emitted only by devices which support the
>> >eject operation, which currently are: CDROMs (IDE and SCSI)
>> >and floppies
>> >
>> > o Human monitor commands "eject" and "change" also cause the
>> >event to be emitted
>> >
>> > o The event is only emitted when there's a tray transition from
>> >closed to opened. To implement this in the human monitor, we
>> >only emit the event if the device is removable and a media is
>> >present
>>
>> Rationale?
>
> This implementation covers the basic use case, which is to let clients know
> that an already inserted media has been ejected. I was under the assumption
> that this is the most important thing a client wants to know, as it will
> have to update its internal state and that only has to be done for the media
> it knows about (ie. the ones inserted by the client itself).
>
> But...
>
>> Wouldn't it be easier if we just report tray status change, regardless
>> of media?
>
> Yes, this seems to make sense.
>
>> > Signed-off-by: Luiz Capitulino
>> > ---
>> > block.c| 12
>> > block.h|1 +
>> > blockdev.c |5 +
>> > monitor.c |3 +++
>> > monitor.h |1 +
>> > 5 files changed, 22 insertions(+), 0 deletions(-)
>> >
>>
>> Copied from PATCH 2 for review purposes:
>>
>> diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
>> index 0ce5d4e..d53c129 100644
>> --- a/QMP/qmp-events.txt
>> +++ b/QMP/qmp-events.txt
>> @@ -1,6 +1,24 @@
>> QEMU Monitor Protocol Events
>>
>>
>> +BLOCK_MEDIA_EJECT
>> +-
>> +
>> +Emitted when a removable disk media (such as a CDROM or floppy) is
>> ejected.
>> +
>> +Data:
>> +
>> +- "device": device name (json-string)
>> +
>> +Example:
>> +
>> +{ "event": "BLOCK_MEDIA_EJECT",
>> +"data": { "device": "ide1-cd0" },
>> +"timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
>> +
>> +NOTE: A disk media can be ejected by the guest or by monitor commands
>> (such
>> +as "eject" and "change")
>> +
>>BLOCK_IO_ERROR
>>--
>>
>> The event reports "tray opening". Do we need one for "tray closing" as
>> well?
>
> At first I thought it wouldn't be needed (and maybe most use cases don't
> require it), but reporting the tray status is more general and easier to do,
> so I think it's what I'm going to do.
>
>> > diff --git a/block.c b/block.c
>> > index f5014cf..dbe813b 100644
>> > --- a/block.c
>> > +++ b/block.c
>> > @@ -1656,6 +1656,15 @@ int bdrv_is_allocated(BlockDriverState *bs, int64_t
>> > sector_num, int nb_sectors,
>> > return bs->drv->bdrv_is_allocated(bs, sector_num, nb_sectors, pnum);
>> > }
>> >
>> > +void bdrv_eject_mon_event(const BlockDriverState *bdrv)
>> > +{
>> > +QObject *data;
>> > +
>> > +data = qobject_from_jsonf("{ 'device': %s }", bdrv->device_name);
>> > +monitor_protocol_event(QEVENT_BLOCK_MEDIA_EJECT, data);
>> > +qobject_decref(data);
>> > +}
>> > +
>> > void bdrv_error_mon_event(const BlockDriverState *bdrv,
>> >BlockMonEventAction action, int is_read)
>> > {
>> > @@ -2770,6 +2779,9 @@ int bdrv_eject(BlockDriverState *bs, int eject_flag)
>> > ret = 0;
>> > }
>> > if (ret >= 0) {
>> > +if (eject_flag && !bs->tray_open) {
>> > +bdrv_eject_mon_event(bs);
>> > +}
>> > bs->tray_open = eject_flag;
>> > }
>> >
>>
>> This covers guest-initiated eject.
>>
>>
>> The event is suppressed when the tray is already open.
>
> Yes, because there's no visible state change.
No objection to that, as long as it's consistently done.
>> The event is not suppressed when the tray is empty, is it? Contradicts
>> spec.
>
> Why does it contradicts the spec? No media is ejected if the tray is empty.
Yes. Nevertheless, the event is triggered.
> But this is probably not going to be an issue when we implement the more
> general BLOCK_TRAY_STATUS (or something like it).
No need to debate the fine points of "media eject" then.
>> > diff --git a/block.h b/block.h
>> > index 1f58eab..e4053dd 100644
>> > --- a/block.h
>> > +++ b/block.h
>> > @@ -50,6 +50,7 @@ typedef enum {
>> > BDRV_ACTION_REPORT, BDRV_ACTION_IGNORE, BDRV_ACTION_STOP
>> > } BlockMonEventAction;
>> >
>> > +void bdrv_ejec
Re: [Qemu-devel] [PATCH 2/3] QMP: Add BLOCK_MEDIA_EJECT event documentation
Luiz Capitulino writes:
> On Mon, 30 May 2011 10:46:07 +0200
> Kevin Wolf wrote:
>
>> Am 27.05.2011 21:31, schrieb Luiz Capitulino:
>> > Signed-off-by: Luiz Capitulino
>> > ---
>> > QMP/qmp-events.txt | 18 ++
>> > 1 files changed, 18 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
>> > index 0ce5d4e..d53c129 100644
>> > --- a/QMP/qmp-events.txt
>> > +++ b/QMP/qmp-events.txt
>> > @@ -1,6 +1,24 @@
>> > QEMU Monitor Protocol Events
>> >
>> >
>> > +BLOCK_MEDIA_EJECT
>> > +-
>> > +
>> > +Emitted when a removable disk media (such as a CDROM or floppy) is
>> > ejected.
>> > +
>> > +Data:
>> > +
>> > +- "device": device name (json-string)
>> > +
>> > +Example:
>> > +
>> > +{ "event": "BLOCK_MEDIA_EJECT",
>> > +"data": { "device": "ide1-cd0" },
>> > +"timestamp": { "seconds": 1265044230, "microseconds": 450486 } }
>> > +
>> > +NOTE: A disk media can be ejected by the guest or by monitor commands
>> > (such
>> > +as "eject" and "change")
>>
>> The monitor command 'eject' already caused a lot of confusion, please
>> don't make the same mistake in this event name. Even though I know more
>> or less what eject can mean in qemu, I'm not sure what "eject" means for
>> you in the context of this event.
>
> I'll change it to report the tray status instead, as suggested by Markus.
>
>> The 'eject' monitor command means that the image is closed and the
>> BlockDriverState doesn't point to any image file any more. And then
>> there's bdrv_eject(), which is what the guest can do, and it's about the
>> virtual tray status.
>>
>> Having a single event for both doesn't make sense because they are
>> fundamentally different. Something like BLOCKDEV_CLOSE would be the
>> right name for the 'eject' monitor command and maybe something like
>> BLOCKDEV_TRAY_STATUS for the other one.
>
> Well, there are two problems here. First, we shouldn't report something
> like BLOCKDEV_CLOSE because closing a BlockDriverState is something
> internal to qemu that clients/users shouldn't know about. The second
> problem is that, unfortunately, clients do use "eject" to eject a
> removable media. Actually it's _the_ interface available for that, so
> not emitting the event there will probably confuse clients as much as
> not having the event at all.
>
> Maybe, a better solution is to fix eject to really eject the media
> instead of closing its BlockDriverState and drop the event from the change
> command.
Monitor command "eject" conflates three actions: open tray, remove media
(if any), close tray.
Monitor command "change" conflates four actions: open tray, remove media
(if any), insert media, close tray.
Except they don't really move the tray in a guest-visible manner. They
teleport the media. I figure that should be changed.
Re: [Qemu-devel] Webcams under KVM and Linux
On 05/30/11 14:50, Natalia Portillo wrote: Exactly what my webcam does is: Takes a frame from ANY available V4L2 device (/dev/video0), caches it, and sends it completely to the guest before requesting any other frame. I think you can double-buffer (i.e. let the host driver fill one buffer while sending the other one to the guest). Probably gives a slightly higher frame rate, but maybe at cost of added latencies. The guest sees a common USB Video Class Device webcam with no controls (this can be enhanced easily), so basically you cannot change any parameter. However all the webcams I tested automatically managed that in the firmware with no intervention from any of the drivers (host or guest), changing white balance and brightness to the adequate values. Nice. Patches are waiting for EHCI being merged I guess? cheers, Gerd
Re: [Qemu-devel] drop -enable-nesting
On 2011-05-30 16:38, Nadav Har'El wrote: > On Mon, May 30, 2011, Jan Kiszka wrote about "drop -enable-nesting (was: > [PATCH 3/7] cpu model bug fixes and definition corrections...)": >> On 2011-05-30 10:18, Roedel, Joerg wrote: >>> On Sat, May 28, 2011 at 04:39:13AM -0400, Jan Kiszka wrote: >>> Jצrg, how to deal with -enable-nesting in qemu-kvm to align behavior with upstream? >>> >>> My personal preference is to just remove it. In upstream-qemu it is >>> enabled/disabled by +/-svm. -enable-nesting is just a historic thing >>> which can be wiped out. > > "-enable-nesting" could remain as a synonym for enabling either VMX or SVM > in the guest, depending on what was available in the host (because KVM now > supports both nested SVM and nested VMX, but not SVM-on-VMX or vice versa). Why? Once nesting is stable (I think SVM already is), there is no reason for an explicit enable. And you can always mask it out via -cpu. BTW, what are the defaults for SVM right now in qemu-kvm and upstream? Enable if the modeled CPU supports it? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] drop -enable-nesting
On Mon, May 30, 2011 at 11:04:02AM -0400, Jan Kiszka wrote: > On 2011-05-30 16:38, Nadav Har'El wrote: > > On Mon, May 30, 2011, Jan Kiszka wrote about "drop -enable-nesting (was: > > [PATCH 3/7] cpu model bug fixes and definition corrections...)": > >> On 2011-05-30 10:18, Roedel, Joerg wrote: > >>> On Sat, May 28, 2011 at 04:39:13AM -0400, Jan Kiszka wrote: > >>> > J�rg, how to deal with -enable-nesting in qemu-kvm to align behavior > with upstream? > >>> > >>> My personal preference is to just remove it. In upstream-qemu it is > >>> enabled/disabled by +/-svm. -enable-nesting is just a historic thing > >>> which can be wiped out. > > > > "-enable-nesting" could remain as a synonym for enabling either VMX or SVM > > in the guest, depending on what was available in the host (because KVM now > > supports both nested SVM and nested VMX, but not SVM-on-VMX or vice versa). > > Why? Once nesting is stable (I think SVM already is), there is no reason > for an explicit enable. And you can always mask it out via -cpu. > > BTW, what are the defaults for SVM right now in qemu-kvm and upstream? > Enable if the modeled CPU supports it? qemu-kvm still needs -enable-nesting, otherwise it is disabled. Upstream qemu should enable it unconditionally (can be disabled with -cpu ,-svm). Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
Re: [Qemu-devel] drop -enable-nesting
On 2011-05-30 17:10, Roedel, Joerg wrote: > On Mon, May 30, 2011 at 11:04:02AM -0400, Jan Kiszka wrote: >> On 2011-05-30 16:38, Nadav Har'El wrote: >>> On Mon, May 30, 2011, Jan Kiszka wrote about "drop -enable-nesting (was: >>> [PATCH 3/7] cpu model bug fixes and definition corrections...)": On 2011-05-30 10:18, Roedel, Joerg wrote: > On Sat, May 28, 2011 at 04:39:13AM -0400, Jan Kiszka wrote: > >> J�rg, how to deal with -enable-nesting in qemu-kvm to align behavior >> with upstream? > > My personal preference is to just remove it. In upstream-qemu it is > enabled/disabled by +/-svm. -enable-nesting is just a historic thing > which can be wiped out. >>> >>> "-enable-nesting" could remain as a synonym for enabling either VMX or SVM >>> in the guest, depending on what was available in the host (because KVM now >>> supports both nested SVM and nested VMX, but not SVM-on-VMX or vice versa). >> >> Why? Once nesting is stable (I think SVM already is), there is no reason >> for an explicit enable. And you can always mask it out via -cpu. >> >> BTW, what are the defaults for SVM right now in qemu-kvm and upstream? >> Enable if the modeled CPU supports it? > > qemu-kvm still needs -enable-nesting, otherwise it is disabled. Upstream > qemu should enable it unconditionally (can be disabled with -cpu ,-svm). Then let's start with aligning qemu-kvm defaults to upstream? I guess that's what the diff I was citing yesterday is responsible for. In the same run, -enable-nesting could dump a warning on the console that this switch is obsolete and will be removed from future versions. For VMX, I would suggest to keep it off by default until it matured, asking the user to issue -cpu ...,+vmx. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] drop -enable-nesting
On Mon, May 30, 2011, Jan Kiszka wrote about "Re: drop -enable-nesting": > > "-enable-nesting" could remain as a synonym for enabling either VMX or SVM > > in the guest, depending on what was available in the host (because KVM now > > supports both nested SVM and nested VMX, but not SVM-on-VMX or vice versa). > > Why? Once nesting is stable (I think SVM already is), there is no reason > for an explicit enable. And you can always mask it out via -cpu. As far as I understand (and this was previously discussed on the QEMU mailing list), the default emulated CPU does not include the "vmx" capability, and you need to enable it with something like "-cpu qemu64,+vmx" (or "-cpu host"). I am not sure if it does enable the "svm" capability. If it does, it isn't useful when KVM is enabled and the underlying host has VMX, not SVM. Nadav. -- Nadav Har'El| Monday, May 30 2011, 27 Iyyar 5771 n...@math.technion.ac.il |- Phone +972-523-790466, ICQ 13349191 |Why do we drive on a parkway and park on http://nadav.harel.org.il |a driveway?
Re: [Qemu-devel] drop -enable-nesting
On 05/30/2011 06:15 PM, Jan Kiszka wrote: On 2011-05-30 17:10, Roedel, Joerg wrote: > On Mon, May 30, 2011 at 11:04:02AM -0400, Jan Kiszka wrote: >> On 2011-05-30 16:38, Nadav Har'El wrote: >>> On Mon, May 30, 2011, Jan Kiszka wrote about "drop -enable-nesting (was: [PATCH 3/7] cpu model bug fixes and definition corrections...)": On 2011-05-30 10:18, Roedel, Joerg wrote: > On Sat, May 28, 2011 at 04:39:13AM -0400, Jan Kiszka wrote: > >> J�rg, how to deal with -enable-nesting in qemu-kvm to align behavior >> with upstream? > > My personal preference is to just remove it. In upstream-qemu it is > enabled/disabled by +/-svm. -enable-nesting is just a historic thing > which can be wiped out. >>> >>> "-enable-nesting" could remain as a synonym for enabling either VMX or SVM >>> in the guest, depending on what was available in the host (because KVM now >>> supports both nested SVM and nested VMX, but not SVM-on-VMX or vice versa). >> >> Why? Once nesting is stable (I think SVM already is), there is no reason >> for an explicit enable. And you can always mask it out via -cpu. >> >> BTW, what are the defaults for SVM right now in qemu-kvm and upstream? >> Enable if the modeled CPU supports it? > > qemu-kvm still needs -enable-nesting, otherwise it is disabled. Upstream > qemu should enable it unconditionally (can be disabled with -cpu ,-svm). Then let's start with aligning qemu-kvm defaults to upstream? I guess that's what the diff I was citing yesterday is responsible for. In the same run, -enable-nesting could dump a warning on the console that this switch is obsolete and will be removed from future versions. I think it's safe to drop -enable-nesting immediately. Dan, does libvirt make use of it? For VMX, I would suggest to keep it off by default until it matured, asking the user to issue -cpu ...,+vmx. We should do that for svm as well (except for -cpu host or -cpu something-with-svm). vmx will be kept disabled by the module option, until it is deemed fit for general consumption. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] drop -enable-nesting
On 2011-05-30 17:19, Avi Kivity wrote: > On 05/30/2011 06:15 PM, Jan Kiszka wrote: >> On 2011-05-30 17:10, Roedel, Joerg wrote: >>> On Mon, May 30, 2011 at 11:04:02AM -0400, Jan Kiszka wrote: On 2011-05-30 16:38, Nadav Har'El wrote: > On Mon, May 30, 2011, Jan Kiszka wrote about "drop -enable-nesting (was: > [PATCH 3/7] cpu model bug fixes and definition corrections...)": >> On 2011-05-30 10:18, Roedel, Joerg wrote: >>> On Sat, May 28, 2011 at 04:39:13AM -0400, Jan Kiszka wrote: >>> J�rg, how to deal with -enable-nesting in qemu-kvm to align behavior with upstream? >>> >>> My personal preference is to just remove it. In upstream-qemu it is >>> enabled/disabled by +/-svm. -enable-nesting is just a historic thing >>> which can be wiped out. > > "-enable-nesting" could remain as a synonym for enabling either VMX or > SVM > in the guest, depending on what was available in the host (because KVM > now > supports both nested SVM and nested VMX, but not SVM-on-VMX or vice > versa). Why? Once nesting is stable (I think SVM already is), there is no reason for an explicit enable. And you can always mask it out via -cpu. BTW, what are the defaults for SVM right now in qemu-kvm and upstream? Enable if the modeled CPU supports it? >>> >>> qemu-kvm still needs -enable-nesting, otherwise it is disabled. Upstream >>> qemu should enable it unconditionally (can be disabled with -cpu ,-svm). >> >> Then let's start with aligning qemu-kvm defaults to upstream? I guess >> that's what the diff I was citing yesterday is responsible for. >> >> In the same run, -enable-nesting could dump a warning on the console >> that this switch is obsolete and will be removed from future versions. > > I think it's safe to drop -enable-nesting immediately. Dan, does > libvirt make use of it? I'm currently checking with some customer who played with Proxmox and nesting if that stack was aware of the switch or accepted it only via a side channel. > >> For VMX, I would suggest to keep it off by default until it matured, >> asking the user to issue -cpu ...,+vmx. > > We should do that for svm as well (except for -cpu host or -cpu > something-with-svm). I assume that's what upstream is doing. Maybe it has it was part of the artificial default qemu64 model which is AMD based. > vmx will be kept disabled by the module option, > until it is deemed fit for general consumption. > Yes, even better - no need for duplicate controls. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] drop -enable-nesting
On 2011-05-30 17:27, Jan Kiszka wrote: > On 2011-05-30 17:19, Avi Kivity wrote: >> I think it's safe to drop -enable-nesting immediately. Dan, does >> libvirt make use of it? > > I'm currently checking with some customer who played with Proxmox and > nesting if that stack was aware of the switch or accepted it only via a > side channel. It was a side channel for tweaking the command line options. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] drop -enable-nesting
On 2011-05-30 17:16, Nadav Har'El wrote: > On Mon, May 30, 2011, Jan Kiszka wrote about "Re: drop -enable-nesting": >>> "-enable-nesting" could remain as a synonym for enabling either VMX or SVM >>> in the guest, depending on what was available in the host (because KVM now >>> supports both nested SVM and nested VMX, but not SVM-on-VMX or vice versa). >> >> Why? Once nesting is stable (I think SVM already is), there is no reason >> for an explicit enable. And you can always mask it out via -cpu. > > As far as I understand (and this was previously discussed on the QEMU mailing > list), the default emulated CPU does not include the "vmx" capability, and you > need to enable it with something like "-cpu qemu64,+vmx" (or "-cpu host"). qemu64 is an artificial AMD model. Adding VMX to it may have interesting effects on the guests. Better use host or a recent Intel model. > > I am not sure if it does enable the "svm" capability. If it does, it isn't > useful when KVM is enabled and the underlying host has VMX, not SVM. That's what KVM is supposed to filter based on the host's capabilities. I bet it does already. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] Webcams under KVM and Linux
Sounds great Natalia. Two things I'd like to let you all know. (1) I am using a VM guest because I need the slightly older pwc driver in Fedora 11 which works with long exposure mods - so that is why I was trying it in a VM. If you use a generic or use the hosts pwc driver, it will break certain things. That's why it's important the guest driver is used for me anyway. (2) I tried this with VMware Player, and you will be happen to know, even though the guest OS detected the pwc webcam and loaded the driver and the video device /dev/video0 and lsusb shows the Philips cam there, all video software tested reports it cannot find the video camera. Opposite of this is KVM/Qemu which does all the same as described, but at least video software reports it finds the webcam, but no video at this time - since you all are working on that. So KVM might be doing better in this regard. Peter --- On Mon, 5/30/11, Natalia Portillo wrote: From: Natalia Portillo Subject: Re: [Qemu-devel] Webcams under KVM and Linux To: "Peter Baitz" Cc: "Andreas Färber" , "QEMU Developers" , "Hoffmann Gerd" Date: Monday, May 30, 2011, 12:50 PM Exactly what my webcam does is: Takes a frame from ANY available V4L2 device (/dev/video0), caches it, and sends it completely to the guest before requesting any other frame. With this way you need your host driver loaded, but you will get never a blackout. What it happens is a thing commonly known in game emulators (like for example ePSX) as framedrop, that is, you get a slower framerate but not blackouts. The guest sees a common USB Video Class Device webcam with no controls (this can be enhanced easily), so basically you cannot change any parameter.However all the webcams I tested automatically managed that in the firmware with no intervention from any of the drivers (host or guest), changing white balance and brightness to the adequate values. You can see it working without KVM in:http://www.youtube.com/watch?v=_Yo9TWPDXCohttp://www.youtube.com/watch?v=fzGYvjZzx6E The webcam emulation works with TCG (without KVM), albeit slower, enough to do videoconference because of the following: Using direct connection method (USB passthrough) even when the ISO xfers and ECHI 2.0 are completely emulated will always find the following: the host is faster than the guest, so the real webcam will always be streaming faster than the guest can process it.Frames are sent in pieces, and if the frame does not arrive completely from start to end on all pieces the guest will blackout, and continue black until it receives a complete frame. With fast webcams, like 60 fps ones, this will happen so commonly that there will be no image at all. You can easily see this in VMWare, Parallels or VirtualBox, all of them emulate ISO xfers and EHCI 2.0 and when using a webcam it's not really practical. Framedrop prevents that. From the 60 frames sent in a second by the host, if the guest can process only 10, it will receive 10 complete frames, and see the webcam as a 10fps one.That's atomic. Also my patch supports, as I already said, any V4L2 device including webcams, DV cameras, TV tuners from any kind of interface be it Firewire, USB, PCI, Serial, AGP, so on. El 29/05/2011, a las 15:03, Peter Baitz escribió: Hello Natalia and Andreas, Thank you for the replies and suggestions. I will lookup V4L. Natalia, So your patch creates a generic webcam under KVM/Qemu to allow many webcams to work? My only concern is the following: I use specific Philips webcams, and one in particular has a long exposure modification that the PWC driver (Fedora 11 guest on Fedora 15 host) coupled with Qastrocam-G2 (v4.9) allows the "shutter" to remain open through USB control of the LED. If the guest restorts to using a generic webcam driver, I think this would preclude functionality that the native driver supports ? Also, can you tell me - when KVM is running my guest, should the PWC webcam driver be loaded and/or the /dev/video0 on the HOST (F15), versus the guest (F11) ? I am confused as to which components are supposed to be enabled or disabled while running the guest webcam. What I see is when I enable the webcam USB device in KVM, it appears to disable the /dev/video0 on the host an brings it up in the guest. And the pwc driver loads and remains on both host and guest. Peter --- On Sun, 5/29/11, Natalia Portillo wrote: From: Natalia Portillo Subject: Re: [Qemu-devel] Webcams under KVM and Linux To: "Andreas Färber" Cc: "Peter Baitz" , "QEMU Developers" Date: Sunday, May 29, 2011, 1:53 PM -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 More concretely search for patches sent by me. Even when EHCI is finished still is the problem of isochronous transfer not working well because of timing issues on QEMU. My patches overcome the need for ISO transfer and EHCI controllers completely, as well as providing an universal device to the guest that works with every
[Qemu-devel] Questions about simulating a new platform
Hi all, For a research project, I want to simulate a new platform with QEMU. The new platform combines a x86 CPU with AMBA-based peripherals, such as interrupt controller, UARTs, PS/2 controller, PCI host bridge, USB controller, etc. I know QEMU has already emulated several ARM systems and x86 systems, but how could I extract x86 CPU model and connect it to AMBA devices? Where should I start? Does anyone out there try this before? Comments are highly appreciated! Thanks! Regards, -david
Re: [Qemu-devel] Webcams under KVM and Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 El 30/05/2011, a las 15:56, Gerd Hoffmann escribió: > On 05/30/11 14:50, Natalia Portillo wrote: >> Exactly what my webcam does is: >> >> Takes a frame from ANY available V4L2 device (/dev/video0), caches it, >> and sends it completely to the guest before requesting any other frame. > > I think you can double-buffer (i.e. let the host driver fill one buffer while > sending the other one to the guest). Probably gives a slightly higher frame > rate, but maybe at cost of added latencies. Indeed you can infinite-buffer it, but there is really no gain, the added latency makes an effective lower frame rate (total number of real frames seen by the guest in percentage) >> The guest sees a common USB Video Class Device webcam with no controls >> (this can be enhanced easily), so basically you cannot change any parameter. >> However all the webcams I tested automatically managed that in the >> firmware with no intervention from any of the drivers (host or guest), >> changing white balance and brightness to the adequate values. > > Nice. Patches are waiting for EHCI being merged I guess? Patches are on RFC on June 2010 ML messages. There are some updates I did to the emulation (internal conversion from YUV2 to MJPEG, gives twice the framerate when the host webcam is YUV2 only) that I have not sent to RFC yet. There are also some things that can be enhanced (conversion of more strange RAWs like OV511's, show the guest the controls of the real webcam) easily but I won't do that until a legal problem about the usage of my emulation code along with all the rest of QEMU by a commercial vendor in violation of GPL is solved. It works really well with USB 1.1 (up to 24fps with KVM, up to 10fps with TCG), but your when EHCI is merged it will allow bigger resolutions easily The most curious and interesting thing is that, while the specification says there can be webcams using bulk transfers (that's what mine is doing) I've seen NONE in wild. All do ISO. Peter about your exact problem you may have more luck requesting that feature to the corresponding linux's driver maintainer. > cheers, > Gerd -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAk3j38QACgkQv/wfOsykIRQfjAEAgrl7eaK6qD4urzZCyGWEYoL2 yaEJbHEDybANWSOAVDkBALyMIVjvVCHzSq3wVH/8fh2Hc6Yp235PrMHduUzdC7Xj =pXPT -END PGP SIGNATURE-
[Qemu-devel] Hello Would You Like To Earn
Hello qemu-devel Would you like to earn an extra $200 everyday?, for just 45 minutes work? You could quit your job and make double the money at home working for yourself. visit->http:tinyurl.com/3brnlpx Regards, Sharon Burns Survey Human Resources Dept.
[Qemu-devel] KVM call agenda for May 31st
Please send in any agenda items you are interested in covering. Thanks, Juan.
[Qemu-devel] [PATCH] slirp: Put forked exec into separate process group
From: Jan Kiszka
Recent smb daemons tend to terminate themselves via a process group
SIGTERM. If the daemon is still in qemu's group by that time, qemu will
die as well. Avoid this by always pushing fork_exec processes into a
group of their own, not just (unused) type 2 execs.
Signed-off-by: Jan Kiszka
---
slirp/misc.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/slirp/misc.c b/slirp/misc.c
index 08eba6a..34179e2 100644
--- a/slirp/misc.c
+++ b/slirp/misc.c
@@ -153,11 +153,12 @@ fork_exec(struct socket *so, const char *ex, int do_pty)
return 0;
case 0:
+setsid();
+
/* Set the DISPLAY */
if (do_pty == 2) {
(void) close(master);
#ifdef TIOCSCTTY /* X */
- (void) setsid();
ioctl(s, TIOCSCTTY, (char *)NULL);
#endif
} else {
--
1.7.1
Re: [Qemu-devel] Webcams under KVM and Linux
On Mon, 30 May 2011 08:38:35 pm Gerd Hoffmann wrote: > I think people are also working on camera emulation, i.e. pass any (even > non-usb) v4l devices as usb webcam to the guest. No idea what the > status here is. I have it in early development. Its far from complete - just enough for the software (e.g. cheese or uvcview on the guest) to believe that there really is a UVC device there and try to open it. I wasn't planning on being able to connect any V4L(2) device to the emulation. I was thinking more along the lines of a gstreamer output, or a fixed image, or a test pattern. Natalia: if possible, could you provide an overview of your work in this area? Brad
Re: [Qemu-devel] [PATCH 2/3] Use the correct header in the TCG MIPS code to find cacheflush() on OpenBSD.
On 25/05/11 11:06 PM, Brad wrote:
Use the correct header in the TCG MIPS code to find cacheflush() on OpenBSD
to fix compilation of the MIPS host support for OpenBSD/mips64 based
architecures.
ping.
Signed-off-by: Brad Smith
---
tcg/mips/tcg-target.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/tcg/mips/tcg-target.h b/tcg/mips/tcg-target.h
index 0028bfa..8cb7d88 100644
--- a/tcg/mips/tcg-target.h
+++ b/tcg/mips/tcg-target.h
@@ -102,7 +102,11 @@ enum {
/* guest base is supported */
#define TCG_TARGET_HAS_GUEST_BASE
+#ifdef __OpenBSD__
+#include
+#else
#include
+#endif
static inline void flush_icache_range(unsigned long start, unsigned long stop)
{
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: [Qemu-devel] [PATCH 2/3] Use the correct header in the TCG MIPS code to find cacheflush() on OpenBSD.
Am 30.05.2011 um 23:01 schrieb Brad:
On 25/05/11 11:06 PM, Brad wrote:
Use the correct header in the TCG MIPS code to find cacheflush() on
OpenBSD
to fix compilation of the MIPS host support for OpenBSD/mips64
based architecures.
ping.
Signed-off-by: Brad Smith
---
tcg/mips/tcg-target.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/tcg/mips/tcg-target.h b/tcg/mips/tcg-target.h
index 0028bfa..8cb7d88 100644
--- a/tcg/mips/tcg-target.h
+++ b/tcg/mips/tcg-target.h
@@ -102,7 +102,11 @@ enum {
/* guest base is supported */
#define TCG_TARGET_HAS_GUEST_BASE
+#ifdef __OpenBSD__
+#include
Usually we have a space in there. Bad example below. ;)
+#else
#include
+#endif
static inline void flush_icache_range(unsigned long start,
unsigned long stop)
{
Re: [Qemu-devel] [PATCH, RFC 00/18] Use stack frame for TCG temporaries
On 05/28/2011 03:06 AM, Blue Swirl wrote: > This patch series is still RFC. Updated versions of x86_64 and i386 > seems to work, Sparc64 is not changed since previous version. This whole patch series is line wrapped. r~
Re: [Qemu-devel] [PATCH 2/3] Use the correct header in the TCG MIPS code to find cacheflush() on OpenBSD.
On 30/05/11 5:16 PM, Andreas Färber wrote:
Am 30.05.2011 um 23:01 schrieb Brad:
On 25/05/11 11:06 PM, Brad wrote:
Use the correct header in the TCG MIPS code to find cacheflush() on
OpenBSD
to fix compilation of the MIPS host support for OpenBSD/mips64 based
architecures.
ping.
Signed-off-by: Brad Smith
---
tcg/mips/tcg-target.h | 4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/tcg/mips/tcg-target.h b/tcg/mips/tcg-target.h
index 0028bfa..8cb7d88 100644
--- a/tcg/mips/tcg-target.h
+++ b/tcg/mips/tcg-target.h
@@ -102,7 +102,11 @@ enum {
/* guest base is supported */
#define TCG_TARGET_HAS_GUEST_BASE
+#ifdef __OpenBSD__
+#include
Usually we have a space in there. Bad example below. ;)
In the original diff as it came across the mailing list even there
is a space.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: [Qemu-devel] [PATCH 2/3] Use the correct header in the TCG MIPS code to find cacheflush() on OpenBSD.
On 30/05/11 5:22 PM, Brad wrote:
On 30/05/11 5:16 PM, Andreas Färber wrote:
Am 30.05.2011 um 23:01 schrieb Brad:
On 25/05/11 11:06 PM, Brad wrote:
Use the correct header in the TCG MIPS code to find cacheflush() on
OpenBSD
to fix compilation of the MIPS host support for OpenBSD/mips64 based
architecures.
ping.
Signed-off-by: Brad Smith
---
tcg/mips/tcg-target.h | 4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/tcg/mips/tcg-target.h b/tcg/mips/tcg-target.h
index 0028bfa..8cb7d88 100644
--- a/tcg/mips/tcg-target.h
+++ b/tcg/mips/tcg-target.h
@@ -102,7 +102,11 @@ enum {
/* guest base is supported */
#define TCG_TARGET_HAS_GUEST_BASE
+#ifdef __OpenBSD__
+#include
Usually we have a space in there. Bad example below. ;)
In the original diff as it came across the mailing list even there
is a space.
Looks like a case of stupid ThunderBird mangling the e-mail content upon
replying. I didn't send the diff with ThunderBird.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: [Qemu-devel] [PATCH 2/3] Use the correct header in the TCG MIPS code to find cacheflush() on OpenBSD.
Am 30.05.2011 um 23:22 schrieb Brad:
On 30/05/11 5:16 PM, Andreas Färber wrote:
Am 30.05.2011 um 23:01 schrieb Brad:
On 25/05/11 11:06 PM, Brad wrote:
Use the correct header in the TCG MIPS code to find cacheflush() on
OpenBSD
to fix compilation of the MIPS host support for OpenBSD/mips64
based
architecures.
ping.
Signed-off-by: Brad Smith
---
tcg/mips/tcg-target.h | 4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/tcg/mips/tcg-target.h b/tcg/mips/tcg-target.h
index 0028bfa..8cb7d88 100644
--- a/tcg/mips/tcg-target.h
+++ b/tcg/mips/tcg-target.h
@@ -102,7 +102,11 @@ enum {
/* guest base is supported */
#define TCG_TARGET_HAS_GUEST_BASE
+#ifdef __OpenBSD__
+#include
Usually we have a space in there. Bad example below. ;)
In the original diff as it came across the mailing list even there
is a space.
Confirmed, looks better on Patchwork: http://patchwork.ozlabs.org/patch/97488/
Andreas
[Qemu-devel] Hello Would You Like To Earn
Hello qemu-devel Would you like to earn an extra $200 everyday?, for just 45 minutes work? You could quit your job and make double the money at home working for yourself. visit->http:tinyurl.com/3brnlpx Regards, Sharon Burns Survey Human Resources Dept.
Re: [Qemu-devel] Webcams under KVM and Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 El 30/05/2011, a las 21:47, Brad Hards escribió: > On Mon, 30 May 2011 08:38:35 pm Gerd Hoffmann wrote: >> I think people are also working on camera emulation, i.e. pass any (even >> non-usb) v4l devices as usb webcam to the guest. No idea what the >> status here is. > I have it in early development. Its far from complete - just enough for the > software (e.g. cheese or uvcview on the guest) to believe that there really > is > a UVC device there and try to open it. > > I wasn't planning on being able to connect any V4L(2) device to the > emulation. > I was thinking more along the lines of a gstreamer output, or a fixed image, > or > a test pattern. > > Natalia: if possible, could you provide an overview of your work in this area? The best should be for you to check for the patches I sent (june 2010 on the ML) and enhance what is left to be done. Reinventing the wheel is non-sense. > Brad -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAk3kKpcACgkQv/wfOsykIRQ+OQEAurhvZGDv4j+ut50vT75PLF3R KGsAEBsBkgnP1c+De68A/R3RWheXXnBFSh2BCaTZYtykdYc8jVxCS76uFLWUDqRL =Fs+h -END PGP SIGNATURE-
[Qemu-devel] Hello Would You Like To Earn
Hello qemu-devel Would you like to earn an extra $200 everyday?, for just 45 minutes work? You could quit your job and make double the money at home working for yourself. visit->http:tinyurl.com/3brnlpx Regards, Sharon Burns Survey Human Resources Dept.
[Qemu-devel] Invitation to the Global Network "Active in diabetes prevention"
Dear colleagues worldwide interested in diabetes prevention, Type 2 diabetes is becoming a major public health concern worldwide. However it has been demonstrated that prevention programs can significantly reduce the risk of developing diabetes. We know it is not an easy task and this challenge depends of a multidisciplinary collaboration. I want to invite you to join our new diabetes prevention initiative the Global Network - Who Are Active in Diabetes Prevention, www.activeindiabetesprevention.com. Our aim is to bring people worldwide together exchanging ideas and expertise in the field of diabetes prevention, but also due to the discussion, create new ideas and hypotheses, how to improve the implementation of diabetes prevention programs. If you are interested in the field please register at www.activeindiabetesprevention.com. We have started this initiative some month ago and more than 3800 people from more than 145 countries registered already worldwide. This is a great success. Our initiative is a non-profit initiative lead by researchers and health educators at the University of Dresden. We are looking to develop the network as a tool available to all people interested in diabetes prevention. Regularly (every 7 to 10 days) we like to exchange ideas and newsletters about practical experience and science in diabetes prevention and introduce different prevention in practice projects worldwide. Diabetes mellitus is one of the most common chronic diseases. The United Nations adapted by the general assembly resolution 61/225 to Unite for diabetes and to address the challenge of the chronic disease diabetes mellitus worldwide. Prevention of chronic diseases is the key and with the Global Network - Who Are Active in Diabetes Prevention, we would like to bring people together addressing this issue. As more people are registered the more powerful and useful the network can be. I hope you can join and I would appreciate to find you as a member of this global community. Sincerely yours, Peter Schwarz Professor for Prevention and Care of Diabetes Department of Medicine III University of Dresden Fetscherstr. 74 01307 Dresden Telephone: +49 351 458 2715 Fax: +49 351 458 7319 For any question feel free to contact me directly at i...@activeindiabetesprevention.com If you don't want to receive further e-mails from us please click here or type this web address in your web browser: http://nebel.tumainiserver.de/dp/index.php?com=mkunsubscribe&email=qemu-devel@nongnu.org
Re: [Qemu-devel] Webcams under KVM and Linux
On Tue, 31 May 2011 09:39:02 AM Natalia Portillo wrote: > > Natalia: if possible, could you provide an overview of your work in this > > area? > > The best should be for you to check for the patches I sent (june 2010 on > the ML) and enhance what is left to be done. Sorry I wasn't clear. I'll try to ask more direct questions: 1. Are you still working in this area? 2. Do you have changes on top of the June 2010 set? 3. Would you like to review incremental patches relative to your changes, or should I just work independently? That is, do I send the changes to you or to Gerd? > Reinventing the wheel is non-sense. Thanks for the support :-( Brad
Re: [Qemu-devel] [PATCH uq/master V2] kvm: Add CPUID support for VIA CPU
Hi, Jan > patch which has > > been checked. It can be compiled without any error and work > normally. > > The patch v3 is here now. > > The above text can't be used as a commit log, so this needs to be > fixed. > Moreover, your patch still contains at least on style issues > scripts/checkpatch.pl should have caught. Are you sure you ran it? > I am sure I have checked it with the scripts/checkpatch.pl, and it shows no error or warning. Maybe I should check whether my windows editor and mail client can work well before sending it to you. I 'm sorry. OK, I will use the previous commit log, and send it to you in the new thread.
[Qemu-devel] [PATCH uq/master V3] kvm: Add CPUID support for VIA CPU
From: brill...@viatech.com.cn
When KVM is running on VIA CPU with host cpu's model, the
feautures of VIA CPU will be passed into kvm guest by calling
the CPUID instruction for Centaur.
Signed-off-by: BrillyWu
Signed-off-by: KaryJin
---
target-i386/cpu.h |7 +++
target-i386/cpuid.c | 52 ++--
target-i386/kvm.c | 15 +++
3 files changed, 72 insertions(+), 2 deletions(-)
--- a/target-i386/cpu.h 2011-05-30 16:20:57.261342707 +0800
+++ b/target-i386/cpu.h 2011-05-30 10:41:45.704533001 +0800
@@ -441,6 +441,10 @@
#define CPUID_VENDOR_AMD_2 0x69746e65 /* "enti" */
#define CPUID_VENDOR_AMD_3 0x444d4163 /* "cAMD" */
+#define CPUID_VENDOR_VIA_1 0x746e6543 /* "Cent" */
+#define CPUID_VENDOR_VIA_2 0x48727561 /* "aurH" */
+#define CPUID_VENDOR_VIA_3 0x736c7561 /* "auls" */
+
#define CPUID_MWAIT_IBE (1 << 1) /* Interrupts can exit capability */
#define CPUID_MWAIT_EMX (1 << 0) /* enumeration supported */
@@ -730,6 +734,9 @@ typedef struct CPUX86State {
uint32_t cpuid_ext3_features;
uint32_t cpuid_apic_id;
int cpuid_vendor_override;
+/* Store the results of Centaur's CPUID instructions */
+uint32_t cpuid_xlevel2;
+uint32_t cpuid_ext4_features;
/* MTRRs */
uint64_t mtrr_fixed[11];
--- a/target-i386/cpuid.c 2011-05-30 16:20:57.261342707 +0800
+++ b/target-i386/cpuid.c 2011-05-30 15:07:18.794532910 +0800
@@ -230,6 +230,9 @@ typedef struct x86_def_t {
char model_id[48];
int vendor_override;
uint32_t flags;
+/* Store the results of Centaur's CPUID instructions */
+uint32_t ext4_features;
+uint32_t xlevel2;
} x86_def_t;
#define I486_FEATURES (CPUID_FP87 | CPUID_VME | CPUID_PSE)
@@ -522,6 +525,18 @@ static int cpu_x86_fill_host(x86_def_t *
cpu_x86_fill_model_id(x86_cpu_def->model_id);
x86_cpu_def->vendor_override = 0;
+/* Call Centaur's CPUID instruction. */
+if (x86_cpu_def->vendor1 == CPUID_VENDOR_VIA_1 &&
+x86_cpu_def->vendor2 == CPUID_VENDOR_VIA_2 &&
+x86_cpu_def->vendor3 == CPUID_VENDOR_VIA_3) {
+host_cpuid(0xC000, 0, &eax, &ebx, &ecx, &edx);
+if (eax >= 0xC001) {
+/* Support VIA max extended level */
+x86_cpu_def->xlevel2 = eax;
+host_cpuid(0xC001, 0, &eax, &ebx, &ecx, &edx);
+x86_cpu_def->ext4_features = edx;
+}
+}
/*
* Every SVM feature requires emulation support in KVM - so we can't just
@@ -855,6 +870,8 @@ int cpu_x86_register (CPUX86State *env,
env->cpuid_xlevel = def->xlevel;
env->cpuid_kvm_features = def->kvm_features;
env->cpuid_svm_features = def->svm_features;
+env->cpuid_ext4_features = def->ext4_features;
+env->cpuid_xlevel2 = def->xlevel2;
if (!kvm_enabled()) {
env->cpuid_features &= TCG_FEATURES;
env->cpuid_ext_features &= TCG_EXT_FEATURES;
@@ -1035,8 +1052,17 @@ void cpu_x86_cpuid(CPUX86State *env, uin
{
/* test if maximum index reached */
if (index & 0x8000) {
-if (index > env->cpuid_xlevel)
-index = env->cpuid_level;
+if (index > env->cpuid_xlevel) {
+if (env->cpuid_xlevel2 > 0) {
+/* Handle the Centaur's CPUID instruction. */
+if (index > env->cpuid_xlevel2) {
+index = env->cpuid_xlevel2;
+} else if (index < 0xC000) {
+index = env->cpuid_xlevel;
+}
+} else
+index = env->cpuid_xlevel;
+}
} else {
if (index > env->cpuid_level)
index = env->cpuid_level;
@@ -1231,6 +1257,28 @@ void cpu_x86_cpuid(CPUX86State *env, uin
*edx = 0;
}
break;
+case 0xC000:
+*eax = env->cpuid_xlevel2;
+*ebx = 0;
+*ecx = 0;
+*edx = 0;
+break;
+case 0xC001:
+/* Support for VIA CPU's CPUID instruction */
+*eax = env->cpuid_version;
+*ebx = 0;
+*ecx = 0;
+*edx = env->cpuid_ext4_features;
+break;
+case 0xC002:
+case 0xC003:
+case 0xC004:
+/* Reserved for the future, and now filled with zero */
+*eax = 0;
+*ebx = 0;
+*ecx = 0;
+*edx = 0;
+break;
default:
/* reserved values: zero */
*eax = 0;
--- a/target-i386/kvm.c 2011-05-30 16:21:05.431342033 +0800
+++ b/target-i386/kvm.c 2011-05-30 10:16:03.284532914 +0800
@@ -482,6 +482,21 @@ int kvm_arch_init_vcpu(CPUState *env)
cpu_x86_cpuid(env, i, 0, &c->eax, &c->ebx, &c->ecx, &c->edx);
}
+/* Call Centaur's CPUID instructions they are supported. */
+if (env->cpuid_xlevel2 > 0) {
+env->cpuid_ext4_features &=
+kvm_arch_get_supported_cpuid(env, 0xC001, 0, R_EDX);
+cpu_x86_cpuid(env, 0xC000, 0, &limit, &unused, &unused, &unused);
+
+
Re: [Qemu-devel] [PATCH 0/2] Fix unused-but-set-variable warnings
On (Mon) 30 May 2011 [15:56:28], Christophe Fergeau wrote: > On Mon, May 30, 2011 at 04:23:43PM +0530, Amit Shah wrote: > > You should keep From: as the same person, keep his Signed-off-by, add > > your Signed-off-by and mention what you have changed in the series. > > Hans's patches didn't have a S-o-b. I can resend the same patches again > with my S-o-b (I'm fine with doing this without Hans's since I came up with > exactly the same patches independently from Hans) and detailing the changes > from the initial patch. Does that sound good? Yes, that's fine. Amit
Re: [Qemu-devel] [PATCH uq/master V2] kvm: Add CPUID support for VIA CPU
On 2011-05-31 03:25, BrillyWu wrote:
> Hi, Jan
>
>> patch which has
>>> been checked. It can be compiled without any error and work
>> normally.
>>> The patch v3 is here now.
>>
>> The above text can't be used as a commit log, so this needs to be
>> fixed.
>> Moreover, your patch still contains at least on style issues
>> scripts/checkpatch.pl should have caught. Are you sure you ran it?
>>
>
> I am sure I have checked it with the scripts/checkpatch.pl, and it
> shows no error or warning. Maybe I should check whether my windows
> editor and mail client can work well before sending it to you. I 'm
> sorry.
Sorry, you are right. Your patch revealed a bug in the checkpatch script.
Blue, this does not trigger the missing braces warning:
@@ -1035,8 +1052,17 @@ void cpu_x86_cpuid(CPUX86State *env, uin
{
/* test if maximum index reached */
if (index & 0x8000) {
-if (index > env->cpuid_xlevel)
-index = env->cpuid_level;
+if (index > env->cpuid_xlevel) {
+if (env->cpuid_xlevel2 > 0) {
+/* Handle the Centaur's CPUID instruction. */
+if (index > env->cpuid_xlevel2) {
+index = env->cpuid_xlevel2;
+} else if (index < 0xC000) {
+index = env->cpuid_xlevel;
+}
+} else
+index = env->cpuid_xlevel;
+}
} else {
if (index > env->cpuid_level)
index = env->cpuid_level;
> OK, I will use the previous commit log, and send it to you in the new thread.
Thanks. I think it would be fair to fix up the braces on commit now.
Jan
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] [PATCH v5] [resend 2] revamp acpitable parsing and allow to specify complete (headerful) table
Since I've got no comments/replies whatsoever, -- neither
positive nor negative, I assume no one received this email
(sent on Thu, 12 May 2011, and one more time on Fri, 20
May 2011), so I'am resending it yet again. The patch
still applies to qemu/master.
This patch almost rewrites acpi_table_add() function
(but still leaves it using old get_param_value() interface).
The result is that it's now possible to specify whole table
(together with a header) in an external file, instead of just
data portion, with a new file= parameter, but at the same time
it's still possible to specify header fields as before.
Now with the checkpatch.pl formatting fixes, thanks to
Stefan Hajnoczi for suggestions, with changes from
Isaku Yamahata, and with my further refinements.
v5: rediffed against current qemu/master.
Signed-off-by: Michael Tokarev
---
hw/acpi.c | 292 ---
qemu-options.hx |7 +-
2 files changed, 175 insertions(+), 124 deletions(-)
diff --git a/hw/acpi.c b/hw/acpi.c
index ad40fb4..4316189 100644
--- a/hw/acpi.c
+++ b/hw/acpi.c
@@ -22,17 +22,29 @@
struct acpi_table_header
{
-char signature [4];/* ACPI signature (4 ASCII characters) */
+uint16_t _length; /* our length, not actual part of the hdr */
+ /* XXX why we have 2 length fields here? */
+char sig[4]; /* ACPI signature (4 ASCII characters) */
uint32_t length; /* Length of table, in bytes, including header */
uint8_t revision; /* ACPI Specification minor version # */
uint8_t checksum; /* To make sum of entire table == 0 */
-char oem_id [6]; /* OEM identification */
-char oem_table_id [8]; /* OEM table identification */
+char oem_id[6]; /* OEM identification */
+char oem_table_id[8]; /* OEM table identification */
uint32_t oem_revision;/* OEM revision number */
-char asl_compiler_id [4]; /* ASL compiler vendor ID */
+char asl_compiler_id[4]; /* ASL compiler vendor ID */
uint32_t asl_compiler_revision; /* ASL compiler revision number */
} __attribute__((packed));
+#define ACPI_TABLE_HDR_SIZE sizeof(struct acpi_table_header)
+#define ACPI_TABLE_PFX_SIZE sizeof(uint16_t) /* size of the extra prefix */
+
+static const char dfl_hdr[ACPI_TABLE_HDR_SIZE] =
+"\0\0" /* fake _length (2) */
+"QEMU\0\0\0\0\1\0" /* sig (4), len(4), revno (1), csum (1) */
+"QEMUQEQEMUQEMU\1\0\0\0" /* OEM id (6), table (8), revno (4) */
+"QEMU\1\0\0\0" /* ASL compiler ID (4), version (4) */
+;
+
char *acpi_tables;
size_t acpi_tables_len;
@@ -45,158 +57,192 @@ static int acpi_checksum(const uint8_t *data, int len)
return (-sum) & 0xff;
}
+/* like strncpy() but zero-fills the tail of destination */
+static void strzcpy(char *dst, const char *src, size_t size)
+{
+size_t len = strlen(src);
+if (len >= size) {
+len = size;
+} else {
+ memset(dst + len, 0, size - len);
+}
+memcpy(dst, src, len);
+}
+
+/* XXX fixme: this function uses obsolete argument parsing interface */
int acpi_table_add(const char *t)
{
-static const char *dfl_id = "QEMUQEMU";
char buf[1024], *p, *f;
-struct acpi_table_header acpi_hdr;
unsigned long val;
-uint32_t length;
-struct acpi_table_header *acpi_hdr_p;
-size_t off;
+size_t len, start, allen;
+bool has_header;
+int changed;
+int r;
+struct acpi_table_header hdr;
+
+r = 0;
+r |= get_param_value(buf, sizeof(buf), "data", t) ? 1 : 0;
+r |= get_param_value(buf, sizeof(buf), "file", t) ? 2 : 0;
+switch (r) {
+case 0:
+buf[0] = '\0';
+case 1:
+has_header = false;
+break;
+case 2:
+has_header = true;
+break;
+default:
+fprintf(stderr, "acpitable: both data and file are specified\n");
+return -1;
+}
+
+if (!acpi_tables) {
+allen = sizeof(uint16_t);
+acpi_tables = qemu_mallocz(allen);
+}
+else {
+allen = acpi_tables_len;
+}
+
+start = allen;
+acpi_tables = qemu_realloc(acpi_tables, start + ACPI_TABLE_HDR_SIZE);
+allen += has_header ? ACPI_TABLE_PFX_SIZE : ACPI_TABLE_HDR_SIZE;
+
+/* now read in the data files, reallocating buffer as needed */
+
+for (f = strtok(buf, ":"); f; f = strtok(NULL, ":")) {
+int fd = open(f, O_RDONLY);
+
+if (fd < 0) {
+fprintf(stderr, "can't open file %s: %s\n", f, strerror(errno));
+return -1;
+}
+
+for (;;) {
+char data[8192];
+r = read(fd, data, sizeof(data));
+if (r == 0) {
+break;
+} else if (r > 0) {
+acpi_tables = qemu_realloc(acpi_tables, allen + r);
+memcpy(acpi_tables + allen, data, r);
+allen += r;
+} else if (errno != EINTR) {
[Qemu-devel] [PATCH] Command line support for altering the log file location
Hi,
The included patch adds command line support for logging to a location
other than /tmp/qemu.log. The diff is relative to commit
2eb9f241824d000fcd90bd7f4b49e40b88e62975. Please let me know if
anything needs to be cleaned up or changed. Anthony, I'm not sure who
should be responsible for reviewing/accepting this, but I've CCed you
as it touches vl.c.
Thanks,
Matthew
Signed-off-by: Matthew Fernandez
diff --git a/bsd-user/main.c b/bsd-user/main.c
index 0c3fca1..0af8a7e 100644
--- a/bsd-user/main.c
+++ b/bsd-user/main.c
@@ -690,7 +690,8 @@ static void usage(void)
"-bsd type select emulated BSD type
FreeBSD/NetBSD/OpenBSD (default)\n"
"\n"
"Debug options:\n"
- "-d options activate log (logfile=%s)\n"
+ "-d options activate log (default logfile=%s)\n"
+ "-D logfile override default logfile location\n"
"-p pagesize set the host page size to 'pagesize'\n"
"-singlestep always run in singlestep mode\n"
"-strace log system calls\n"
@@ -731,6 +732,8 @@ int main(int argc, char **argv)
{
const char *filename;
const char *cpu_model;
+const char *log_file = DEBUG_LOGFILE;
+const char *log_mask = NULL;
struct target_pt_regs regs1, *regs = ®s1;
struct image_info info1, *info = &info1;
TaskState ts1, *ts = &ts1;
@@ -745,9 +748,6 @@ int main(int argc, char **argv)
if (argc <= 1)
usage();
-/* init debug */
-cpu_set_log_filename(DEBUG_LOGFILE);
-
if ((envlist = envlist_create()) == NULL) {
(void) fprintf(stderr, "Unable to allocate envlist\n");
exit(1);
@@ -775,22 +775,15 @@ int main(int argc, char **argv)
if (!strcmp(r, "-")) {
break;
} else if (!strcmp(r, "d")) {
-int mask;
-const CPULogItem *item;
-
-if (optind >= argc)
+if (optind >= argc) {
break;
-
-r = argv[optind++];
-mask = cpu_str_to_log_mask(r);
-if (!mask) {
-printf("Log items (comma separated):\n");
-for(item = cpu_log_items; item->mask != 0; item++) {
-printf("%-10s %s\n", item->name, item->help);
-}
-exit(1);
}
-cpu_set_log(mask);
+log_mask = argv[optind++];
+} else if (!strcmp(r, "D")) {
+if (optind >= argc) {
+break;
+}
+log_file = argv[optind++];
} else if (!strcmp(r, "E")) {
r = argv[optind++];
if (envlist_setenv(envlist, r) != 0)
@@ -867,6 +860,23 @@ int main(int argc, char **argv)
usage();
filename = argv[optind];
+/* init debug */
+cpu_set_log_filename(log_file);
+if (log_mask) {
+int mask;
+const CPULogItem *item;
+
+mask = cpu_str_to_log_mask(r);
+if (!mask) {
+printf("Log items (comma separated):\n");
+for (item = cpu_log_items; item->mask != 0; item++) {
+printf("%-10s %s\n", item->name, item->help);
+}
+exit(1);
+}
+cpu_set_log(mask);
+}
+
/* Zero out regs */
memset(regs, 0, sizeof(struct target_pt_regs));
diff --git a/cpus.c b/cpus.c
index 1fc34b7..17e96b5 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1142,6 +1142,11 @@ void set_cpu_log(const char *optarg)
cpu_set_log(mask);
}
+void set_cpu_log_filename(const char *optarg)
+{
+cpu_set_log_filename(optarg);
+}
+
/* Return the virtual CPU time, based on the instruction counter. */
int64_t cpu_get_icount(void)
{
diff --git a/cpus.h b/cpus.h
index 6fdeb0d..f42b54e 100644
--- a/cpus.h
+++ b/cpus.h
@@ -19,6 +19,7 @@ void vm_state_notify(int running, int reason);
bool cpu_exec_all(void);
void set_numa_modes(void);
void set_cpu_log(const char *optarg);
+void set_cpu_log_filename(const char *optarg);
void list_cpus(FILE *f, fprintf_function cpu_fprintf, const char *optarg);
#endif
diff --git a/darwin-user/main.c b/darwin-user/main.c
index 175e12f..a6dc859 100644
--- a/darwin-user/main.c
+++ b/darwin-user/main.c
@@ -738,6 +738,8 @@ TaskState *first_task_state;
int main(int argc, char **argv)
{
const char *filename;
+const char *log_file = DEBUG_LOGFILE;
+const char *log_mask = NULL;
struct target_pt_regs regs1, *regs = ®s1;
TaskState ts1, *ts = &ts1;
CPUState *env;
@@ -749,9 +751,6 @@ int main(int argc, char **argv)
if (argc <= 1)
usage();
-/* init debug */
-cpu_set_log_filename(DEBUG_LOGFILE);
-
optind = 1;
for(;;) {
if (optind >= argc)
@@ -764,22 +763,15 @@ int main(int argc, char **argv)
if (!strcmp(r, "-")) {
break;
} else if (!strcmp(r, "d")) {
-int mask;
-CPULogItem *item;
-
-if (optind >= argc)
-break;
-
-r = argv[optind++];
-
