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 m...@tls.msk.ru
---
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 matthew.fernan...@gmail.com
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 = regs1;
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 = regs1;
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++];
-mask =
Re: [Qemu-devel] Webcams under KVM and Linux
Hi, 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) Just two buffers, so capture and sending to the guest can be parallelized. More buffers don't really help and just increase latency. 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. Can you repost the latest version for review so we can get the bits merged? 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. Thats fine, we can always add it later once the legal issues are sorted. 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 Great. 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. Using bulk certainly makes sense for a virtual device. cheers, Gerd
Re: [Qemu-devel] [PATCH 2/3] QMP: Add BLOCK_MEDIA_EJECT event documentation
On (Mon) 30 May 2011 [16:54:22], Markus Armbruster wrote: Luiz Capitulino lcapitul...@redhat.com writes: ... 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. Agreed. We should be able to report these events to clients as well as guests. Amit
Re: [Qemu-devel] [PATCH uq/master V2] kvm: Add CPUID support for VIA CPU
Hi, Jan
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:
Do you mean the bug is that it can not trigger missing braces warining?
It seems that there is no missing braces in my patch, but some
unnecessary braces.
@@ -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.
It looks that there are some unnecessary braces, but if I remove them,
the script/checkpatch.pl will report warnings. Could I ignore it?
BTW, I have submited a patch v3 a few minutes before withou fixing up
the braces, and I have tested it with my mail client this time, so it
could be OK now.
Re: [Qemu-devel] [PATCH uq/master V2] kvm: Add CPUID support for VIA CPU
On 2011-05-31 09:39, BrillyWu wrote:
Hi, Jan
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:
Do you mean the bug is that it can not trigger missing braces warining?
The script fails to detect missing braces as marked below.
It seems that there is no missing braces in my patch, but some
unnecessary braces.
There are no unnecessary braces according to QEMU coding style.
@@ -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;
This should be:
} else {
index = ...
}
+}
} 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.
It looks that there are some unnecessary braces, but if I remove them,
the script/checkpatch.pl will report warnings. Could I ignore it?
Nope, see above.
BTW, I have submited a patch v3 a few minutes before withou fixing up
the braces, and I have tested it with my mail client this time, so it
could be OK now.
Yes, your mail client works fine as far as I can see.
Jan
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] [PATCH-v3 2/2] kvm: Fix unused-but-set-variable warning
Based on a patch from Hans de Goede hdego...@redhat.com
This warning is new in gcc 4.6.
Acked-by: Amit Shah amit.s...@redhat.com
Signed-off-by: Christophe Fergeau cferg...@redhat.com
---
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
[Qemu-devel] [PATCH-v3 1/2] tcg: Fix unused-but-set-variable warning
Based on a patch from Hans de Goede hdego...@redhat.com
This warning is new in gcc 4.6.
Acked-by: Amit Shah amit.s...@redhat.com
Signed-off-by: Christophe Fergeau cferg...@redhat.com
---
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-v3 0/2] Fix unused-but-set-variable warnings
Here is another version of these patches. Christophe Changes: v3 - added S-o-b v2 - split patches - removed whitespace at end of lines in tcm. - changed #if defined XXX to #if defined(XXX) - removed commented out line from kvm.c in the 1st patch v1 - initial version from Hans 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
Re: [Qemu-devel] [PATCH 2/3] QMP: Add BLOCK_MEDIA_EJECT event documentation
Am 30.05.2011 16:21, schrieb Luiz Capitulino:
On Mon, 30 May 2011 10:46:07 +0200
Kevin Wolf kw...@redhat.com wrote:
Am 27.05.2011 21:31, schrieb Luiz Capitulino:
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
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.
Of course they know about it. After all, it was them who created the
BlockDriverState using -drive or drive_add (or eventually blockdev_add).
Anyway, I'm not saying that there's a good use case for BLOCKDEV_CLOSE,
it might be completely useless. I'm just saying that we must not mix it
with the tray status event.
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.
Hm, it would surely change the behaviour which means that we have to be
careful with it. But the change makes some sense to me. If we do this
change, I think we should also add a command for closing the tray, so
that you get access to the image again.
Kevin
Re: [Qemu-devel] [PATCH 3/3] QMP: Introduce the BLOCK_MEDIA_EJECT event
Am 30.05.2011 16:49, schrieb Markus Armbruster:
Luiz Capitulino lcapitul...@redhat.com writes:
On Sat, 28 May 2011 09:58:24 +0200
Markus Armbruster arm...@redhat.com wrote:
Luiz Capitulino lcapitul...@redhat.com writes:
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
@@ -661,6 +661,11 @@ static int eject_device(Monitor *mon,
BlockDriverState *bs, int force)
return -1;
}
}
+
+if (bdrv_is_removable(bs) bdrv_is_inserted(bs)) {
+bdrv_eject_mon_event(bs);
+}
+
bdrv_close(bs);
return 0;
}
This covers monitor-initiated eject (commands eject and change).
The event is not suppressed when the tray is already open (previous
guest-initiated eject), is it?. Contradicts spec.
That's a bug.
The event is suppressed when the tray is empty.
eject -f on a non-removable drive does not trigger an event. Why
treat it specially? I'm not saying you shouldn't, just wondering.
Ejecting a non-removable drive is a qemu bug.
It's clearly intentional, so it's a (mis-)feature, not a bug.
Is there really a use case for it? The closest thing to a specification
that we have is the help text and it says:
.help = eject a removable medium (use -f to force it),
QMP describes it like this:
Eject a removable medium.
So I start tending to agree that this whole trouble around the 'eject'
monitor command is in fact a long standing bug rather than overloaded
semantics. Nowhere is stated that it disconnects a BlockDriverState from
the image, and I can't imagine a use case for this semantics either.
Do we break anything if we make eject really eject the medium (we have a
virtual tray status now) instead of just closing the image? I think the
most visible change is that we'll eject the host medium when using
pass-through. I consider this an additional bugfix.
Kevin
Re: [Qemu-devel] [PATCH uq/master V2] kvm: Add CPUID support for VIA CPU
Blue, this does not trigger the missing braces warning:
Do you mean the bug is that it can not trigger missing
braces warining?
The script fails to detect missing braces as marked below.
It seems that there is no missing braces in my patch, but some
unnecessary braces.
There are no unnecessary braces according to QEMU coding style.
Oh, I see. Thank you!
+index = env-cpuid_xlevel;
+}
+} else
+index = env-cpuid_xlevel;
This should be:
} else {
index = ...
}
+}
Nope, see above.
It looks that I should add the missing braces.
BTW, I have submited a patch v3 a few minutes before withou
fixing up
the braces, and I have tested it with my mail client this
time, so it
could be OK now.
Yes, your mail client works fine as far as I can see.
Yes, you are right. It seems to be the problem of my editor.
I'll check whether other places need any brace, and then send it to
the patch v3 thread.
Re: [Qemu-devel] drop -enable-nesting
On Mon, May 30, 2011 at 06:19:14PM +0300, 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? Yes, but it should be safe to drop it. Currently, if the user specifies a CPU with the 'svm' flag present in libvirt guest XML, then we will pass args '-cpu +svm -enable-nesting'. So if we drop --enable-nesting, then libvirt will simply omit it and everything should still work because we have still got +svm set. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] drop -enable-nesting
On 05/31/2011 11:44 AM, Daniel P. Berrange wrote: I think it's safe to drop -enable-nesting immediately. Dan, does libvirt make use of it? Yes, but it should be safe to drop it. Currently, if the user specifies a CPU with the 'svm' flag present in libvirt guest XML, then we will pass args '-cpu +svm -enable-nesting'. So if we drop --enable-nesting, then libvirt will simply omit it and everything should still work because we have still got +svm set. But qemu will complain about an option it can't parse. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] drop -enable-nesting
On Tue, May 31, 2011 at 04:58:16AM -0400, Avi Kivity wrote: On 05/31/2011 11:44 AM, Daniel P. Berrange wrote: I think it's safe to drop -enable-nesting immediately. Dan, does libvirt make use of it? Yes, but it should be safe to drop it. Currently, if the user specifies a CPU with the 'svm' flag present in libvirt guest XML, then we will pass args '-cpu +svm -enable-nesting'. So if we drop --enable-nesting, then libvirt will simply omit it and everything should still work because we have still got +svm set. But qemu will complain about an option it can't parse. The best choice is probably to keep the option and make it a nop for the lifetime of qemu-kvm. Optionally qemu-kvm can print a warning about the deprecated option. 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
[Qemu-devel] how to add a new guest cpu to qemu?
Dear alpha, I'm a college student and a fan of linux. I am learning the source of qemu, and find your name in the maintainers. I really want to add a new guest cpu which is used by the course I'm taking. Would you please give me the documents or at least some hints that will help me add the new guest cpu. Thank you very much! Yours sincedrely, you can call me Jake.
Re: [Qemu-devel] drop -enable-nesting
On 05/31/2011 10:58 AM, Avi Kivity wrote: But qemu will complain about an option it can't parse. The presence of -enable-nesting is inferred from the help text. Paolo
Re: [Qemu-devel] drop -enable-nesting
On 05/31/2011 12:15 PM, Paolo Bonzini wrote: On 05/31/2011 10:58 AM, Avi Kivity wrote: But qemu will complain about an option it can't parse. The presence of -enable-nesting is inferred from the help text. Okay, so it can be safely dropped. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 0/4] introduce cpu_physical_memory_map_fast
On 05/12/2011 04:51 PM, Paolo Bonzini wrote: On 05/03/2011 06:49 PM, Paolo Bonzini wrote: Paravirtualized devices (and also some real devices) can assume they are going to access RAM. For this reason, provide a fast-path function with the following properties: 1) it will never allocate a bounce buffer 2) it can be used for read-modify-write operations 3) unlike qemu_get_ram_ptr, it is safe because it recognizes short blocks Patches 3 and 4 use this function for virtio devices and the milkymist GPU. The latter is only compile-tested. Another function checks if it is possible to split a contiguous physical address range into multiple subranges, all of which use the fast path. I will introduce later a use for this function. Paolo Bonzini (4): exec: extract cpu_physical_memory_map_internal exec: introduce cpu_physical_memory_map_fast and cpu_physical_memory_map_check virtio: use cpu_physical_memory_map_fast milkymist: use cpu_physical_memory_map_fast cpu-common.h | 4 ++ exec.c | 108 +- hw/milkymist-tmu2.c | 39 ++ hw/vhost.c | 10 ++-- hw/virtio.c | 2 +- 5 files changed, 111 insertions(+), 52 deletions(-) Ping? Ping^2? Paolo
Re: [Qemu-devel] [OpenBIOS] solaris 8 on sparc, webstart launcher crashing
On 28/05/11 07:40, Blue Swirl wrote: (lots cut) I was able to get the exact same error stack trace as the sig11 one from (2) above. Addresses were the same, only diferences were the PID, LWP, and sp (330, 9, 0xee752c78) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Starting Web Start Launcher in Command Line Mode. Fri May 27 15:29:19 2011 fatal: mounting of /vol failed signal fault in critical section signal number: 11, signal code: 1, fault address: 0xee780de8, pc: 0xef40d4a8, sp: 0xeb1b2c78 libthread panic: fault in libthread critical section : dumping core (PID: 330 LWP 12) stacktrace: ef40d49c ef40f134 ef408c48 0 Abort - core dumped (blahdy blah) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- For reference, I'm using a 3g qcow2 image. I originally formatted it as a SUN2.9G in the format utility, but I let it autoconfigure the partitions. partition '0' is root (1.18G), '1' is swap (149m), '2' is backup (2.71g), and '7' is home (1.39g). There's overlap in the cylinder ranges specified and the total size between those partitions is larger than 3g ... but, I have no idea whether that's just a Sun-ism, or whether I need to partition manually. I don't think it's my partitions, though. The 'vol' directory doesn't exist in my root before I try to get the webstart stuff to run, so I think it's creating that directory and trying to mount an image to it. Additionally, I'm starting qemu with: ./qemu_system_sparc -nographic -bios /imgpath/openbios-sparc32_artyom.bin -hda /imgpath/solaris2.8-img3.qcow2 -m 256 -net nic -net user -cdrom /imgpath/solaris2.8/software_1of2.iso prom-env 'auto-boot?=false' -snapshot If anyone has a good idea, I'm all ears ... (or is it eyes?) I suppose this is a problem with QEMU since the OS has started up successfully. The way to verify this would be to check if this happens also with OBP. If the problem is on the QEMU side, getting relevant QEMU debug logs (-d in_asm,int which needs #define DEBUG_PCALL enabled in target-sparc/op_helper.c) would be needed. Those will be quite large and the relevant info is only near the end. Yeah - at this point the kernel should have taken over completely and so I expect that you're hitting an emulation bug (probably the Solaris compiler emits certain instruction sequences not used by gcc which is why this has only just come to light). In order for someone to fix this, you'll need to supply the information requested by Blue above. Also which version of QEMU are you running? ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
[Qemu-devel] [PATCH 00/14] usb: various usb fixes
Here is a patch series with a bunch of usb fixes, mostly (linux) usb redirection related. Regards, Hans
[Qemu-devel] [PATCH 02/14] usb-linux: Get speed from sysfs rather then from the connectinfo ioctl
The connectinfo ioctl only differentiates between lo speed devices, and
all other speeds, where as we would like to know the real speed. The real
speed is available in sysfs so use that when available.
---
usb-linux.c | 37 +
1 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index ea3ab5f..db28762 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -1053,10 +1053,9 @@ static int usb_linux_update_endp_table(USBHostDevice *s)
}
static int usb_host_open(USBHostDevice *dev, int bus_num,
- int addr, char *port, const char *prod_name)
+int addr, char *port, const char *prod_name, int speed)
{
int fd = -1, ret;
-struct usbdevfs_connectinfo ci;
char buf[1024];
if (dev-fd != -1) {
@@ -,24 +1110,29 @@ static int usb_host_open(USBHostDevice *dev, int
bus_num,
goto fail;
}
-ret = ioctl(fd, USBDEVFS_CONNECTINFO, ci);
-if (ret 0) {
-perror(usb_host_device_open: USBDEVFS_CONNECTINFO);
-goto fail;
-}
-
-printf(husb: grabbed usb device %d.%d\n, bus_num, addr);
-
ret = usb_linux_update_endp_table(dev);
if (ret) {
goto fail;
}
-if (ci.slow) {
-dev-dev.speed = USB_SPEED_LOW;
-} else {
-dev-dev.speed = USB_SPEED_HIGH;
+if (speed == -1) {
+struct usbdevfs_connectinfo ci;
+
+ret = ioctl(fd, USBDEVFS_CONNECTINFO, ci);
+if (ret 0) {
+perror(usb_host_device_open: USBDEVFS_CONNECTINFO);
+goto fail;
+}
+
+if (ci.slow) {
+speed = USB_SPEED_LOW;
+} else {
+speed = USB_SPEED_HIGH;
+}
}
+dev-dev.speed = speed;
+
+printf(husb: grabbed usb device %d.%d\n, bus_num, addr);
if (!prod_name || prod_name[0] == '\0') {
snprintf(dev-dev.product_desc, sizeof(dev-dev.product_desc),
@@ -1342,7 +1346,8 @@ static int usb_host_scan_dev(void *opaque, USBScanFunc
*func)
}
device_count = 0;
-bus_num = addr = speed = class_id = product_id = vendor_id = 0;
+bus_num = addr = class_id = product_id = vendor_id = 0;
+speed = -1; /* Can't get the speed from /[proc|dev]/bus/usb/devices */
for(;;) {
if (fgets(line, sizeof(line), f) == NULL) {
break;
@@ -1652,7 +1657,7 @@ static int usb_host_auto_scan(void *opaque, int bus_num,
int addr, char *port,
}
DPRINTF(husb: auto open: bus_num %d addr %d\n, bus_num, addr);
-usb_host_open(s, bus_num, addr, port, product_name);
+usb_host_open(s, bus_num, addr, port, product_name, speed);
}
return 0;
--
1.7.5.1
[Qemu-devel] [PATCH 04/14] usb-linux: Don't do perror when errno is not set
Note that op also is not set, so before this change these error paths
would feed NULL to perror.
---
usb-linux.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index 672a589..e6c6138 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -373,7 +373,8 @@ static int usb_host_claim_interfaces(USBHostDevice *dev,
int configuration)
i = 0;
dev_descr_len = dev-descr[0];
if (dev_descr_len dev-descr_len) {
-goto fail;
+fprintf(stderr, husb: update iface failed. descr too short\n);
+return 0;
}
i += dev_descr_len;
@@ -401,7 +402,7 @@ static int usb_host_claim_interfaces(USBHostDevice *dev,
int configuration)
if (i = dev-descr_len) {
fprintf(stderr,
husb: update iface failed. no matching configuration\n);
-goto fail;
+return 0;
}
nb_interfaces = dev-descr[i + 4];
--
1.7.5.1
[Qemu-devel] [PATCH 05/14] usb-linux: Don't call usb_host_close when usb_host_open fails
---
usb-linux.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index e6c6138..544aea3 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -363,13 +363,16 @@ static int usb_host_claim_interfaces(USBHostDevice *dev,
int configuration)
const char *op = NULL;
int dev_descr_len, config_descr_len;
int interface, nb_interfaces;
-int ret, i;
+int ret, i, close_on_nodev;
if (configuration == 0) /* address state - ignore */
return 1;
DPRINTF(husb: claiming interfaces. config %d\n, configuration);
+/* Don't close on nodev when called from usb_host_open (which passes -1) */
+close_on_nodev = (configuration == -1) ? 0 : 1;
+
i = 0;
dev_descr_len = dev-descr[0];
if (dev_descr_len dev-descr_len) {
@@ -445,7 +448,7 @@ static int usb_host_claim_interfaces(USBHostDevice *dev,
int configuration)
return 1;
fail:
-if (errno == ENODEV) {
+if (errno == ENODEV close_on_nodev) {
do_disconnect(dev);
}
perror(op);
--
1.7.5.1
[Qemu-devel] [PATCH 01/14] usb-linux: Set usb_auto_timer to NULL after deleting it
We might check for it being NULL later, if the device gets unplugged.
---
usb-linux.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index 4d7a31a..ea3ab5f 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -1675,6 +1675,7 @@ static void usb_host_auto_check(void *unused)
/* nothing to watch */
if (usb_auto_timer) {
qemu_del_timer(usb_auto_timer);
+usb_auto_timer = NULL;
}
return;
}
--
1.7.5.1
[Qemu-devel] [PATCH 08/14] usb-linux: Don't try to open the same device twice
If a user wants to redirect 2 identical usb sticks, in theory this is possible by doing: usb_add host:1234:5678 usb_add host:1234:5678 But this will lead to us trying to open the first stick twice, since we don't break the loop after having found a match in our filter list, so the next' filter list entry will result in us trying to open the same device again. Fix this by adding the missing break. --- usb-linux.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/usb-linux.c b/usb-linux.c index 334012e..eb9805b 100644 --- a/usb-linux.c +++ b/usb-linux.c @@ -1689,6 +1689,7 @@ static int usb_host_auto_scan(void *opaque, int bus_num, int addr, char *port, a qdev from its initfn is not allowed. */ s-open_failed = ret; } +break; } return 0; -- 1.7.5.1
[Qemu-devel] [PATCH 06/14] usb-linux: Ensure devep != 0
So that we don't index endp_table with a negative index.
---
usb-linux.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index 544aea3..e2f45d3 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -1029,6 +1029,11 @@ static int usb_linux_update_endp_table(USBHostDevice *s)
}
devep = descriptors[i + 2];
+if ((devep 0x0f) == 0) {
+fprintf(stderr, usb-linux: invalid ep descriptor, ep == 0\n);
+return 1;
+}
+
switch (descriptors[i + 3] 0x3) {
case 0x00:
type = USBDEVFS_URB_TYPE_CONTROL;
--
1.7.5.1
[Qemu-devel] [PATCH 03/14] usb-linux: Teach about super speed
---
usb-linux.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index db28762..672a589 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -1375,7 +1375,9 @@ static int usb_host_scan_dev(void *opaque, USBScanFunc
*func)
if (get_tag_value(buf, sizeof(buf), line, Spd=, ) 0) {
goto fail;
}
-if (!strcmp(buf, 480)) {
+if (!strcmp(buf, 5000)) {
+speed = USB_SPEED_SUPER;
+} else if (!strcmp(buf, 480)) {
speed = USB_SPEED_HIGH;
} else if (!strcmp(buf, 1.5)) {
speed = USB_SPEED_LOW;
@@ -1519,7 +1521,9 @@ static int usb_host_scan_sys(void *opaque, USBScanFunc
*func)
if (!usb_host_read_file(line, sizeof(line), speed, de-d_name)) {
goto the_end;
}
-if (!strcmp(line, 480\n)) {
+if (!strcmp(line, 5000\n)) {
+speed = USB_SPEED_SUPER;
+} else if (!strcmp(line, 480\n)) {
speed = USB_SPEED_HIGH;
} else if (!strcmp(line, 1.5\n)) {
speed = USB_SPEED_LOW;
@@ -1797,6 +1801,9 @@ static void usb_info_device(Monitor *mon, int bus_num,
int addr, char *port,
case USB_SPEED_HIGH:
speed_str = 480;
break;
+case USB_SPEED_SUPER:
+speed_str = 5000;
+break;
default:
speed_str = ?;
break;
--
1.7.5.1
[Qemu-devel] [PATCH 14/14] usb: Proper error propagation for usb_device_attach errors
---
hw/usb-bus.c | 23 ---
hw/usb-msd.c |5 +++--
usb-linux.c |6 +-
3 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index 0a49921..2ae2678 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
@@ -75,7 +75,7 @@ static int usb_qdev_init(DeviceState *qdev, DeviceInfo *base)
QLIST_INIT(dev-strings);
rc = dev-info-init(dev);
if (rc == 0 dev-auto_attach)
-usb_device_attach(dev);
+rc = usb_device_attach(dev);
return rc;
}
@@ -171,20 +171,20 @@ void usb_unregister_port(USBBus *bus, USBPort *port)
bus-nfree--;
}
-static void do_attach(USBDevice *dev)
+static int do_attach(USBDevice *dev)
{
USBBus *bus = usb_bus_from_device(dev);
USBPort *port;
if (dev-attached) {
-fprintf(stderr, Warning: tried to attach usb device %s twice\n,
+fprintf(stderr, Error: tried to attach usb device %s twice\n,
dev-product_desc);
-return;
+return -1;
}
if (bus-nfree == 0) {
-fprintf(stderr, Warning: tried to attach usb device %s to a bus with
no free ports\n,
+fprintf(stderr, Error: tried to attach usb device %s to a bus with no
free ports\n,
dev-product_desc);
-return;
+return -1;
}
if (dev-port_path) {
QTAILQ_FOREACH(port, bus-free, next) {
@@ -193,9 +193,9 @@ static void do_attach(USBDevice *dev)
}
}
if (port == NULL) {
-fprintf(stderr, Warning: usb port %s (bus %s) not found\n,
+fprintf(stderr, Error: usb port %s (bus %s) not found\n,
dev-port_path, bus-qbus.name);
-return;
+return -1;
}
} else {
port = QTAILQ_FIRST(bus-free);
@@ -209,6 +209,8 @@ static void do_attach(USBDevice *dev)
QTAILQ_INSERT_TAIL(bus-used, port, next);
bus-nused++;
+
+return 0;
}
int usb_device_attach(USBDevice *dev)
@@ -220,8 +222,7 @@ int usb_device_attach(USBDevice *dev)
(unless a physical port location is specified). */
usb_create_simple(bus, usb-hub);
}
-do_attach(dev);
-return 0;
+return do_attach(dev);
}
int usb_device_detach(USBDevice *dev)
@@ -230,7 +231,7 @@ int usb_device_detach(USBDevice *dev)
USBPort *port;
if (!dev-attached) {
-fprintf(stderr, Warning: tried to detach unattached usb device %s\n,
+fprintf(stderr, Error: tried to detach unattached usb device %s\n,
dev-product_desc);
return -1;
}
diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index c8b7d41..68b46fa 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -481,8 +481,9 @@ static void usb_msd_password_cb(void *opaque, int err)
MSDState *s = opaque;
if (!err)
-usb_device_attach(s-dev);
-else
+err = usb_device_attach(s-dev);
+
+if (err)
qdev_unplug(s-dev.qdev);
}
diff --git a/usb-linux.c b/usb-linux.c
index 490c49f..fe21da1 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -1152,10 +1152,14 @@ static int usb_host_open(USBHostDevice *dev, int
bus_num,
prod_name);
}
+ret = usb_device_attach(dev-dev);
+if (ret) {
+goto fail;
+}
+
/* USB devio uses 'write' flag to check for async completions */
qemu_set_fd_handler(dev-fd, NULL, async_complete, dev);
-usb_device_attach(dev-dev);
return 0;
fail:
--
1.7.5.1
[Qemu-devel] [PATCH 07/14] usb-linux: If opening a device fails remove it from our filter list
So that we don't retry to open it every 2 seconds flooding stderr with
error messages.
---
usb-linux.c | 31 ---
1 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index e2f45d3..334012e 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -122,6 +122,7 @@ typedef struct USBHostDevice {
int configuration;
int ninterfaces;
int closing;
+int open_failed;
Notifier exit;
struct endp_data endp_table[MAX_ENDPOINTS];
@@ -1208,6 +1209,10 @@ static int usb_host_initfn(USBDevice *dev)
s-exit.notify = usb_host_exit_notifier;
qemu_add_exit_notifier(s-exit);
usb_host_auto_check(NULL);
+if (s-open_failed) {
+usb_host_handle_destroy(dev);
+return s-open_failed;
+}
return 0;
}
@@ -1272,7 +1277,11 @@ USBDevice *usb_host_device_open(const char *devname)
qdev_prop_set_uint32(dev-qdev, hostaddr, filter.addr);
qdev_prop_set_uint32(dev-qdev, vendorid, filter.vendor_id);
qdev_prop_set_uint32(dev-qdev, productid, filter.product_id);
-qdev_init_nofail(dev-qdev);
+
+if (qdev_init(dev-qdev) != 0) {
+return NULL;
+}
+
return dev;
fail:
@@ -1637,6 +1646,7 @@ static int usb_host_auto_scan(void *opaque, int bus_num,
int addr, char *port,
{
struct USBAutoFilter *f;
struct USBHostDevice *s;
+int ret;
/* Ignore hubs */
if (class_id == 9)
@@ -1670,7 +1680,15 @@ static int usb_host_auto_scan(void *opaque, int bus_num,
int addr, char *port,
}
DPRINTF(husb: auto open: bus_num %d addr %d\n, bus_num, addr);
-usb_host_open(s, bus_num, addr, port, product_name, speed);
+ret = usb_host_open(s, bus_num, addr, port, product_name, speed);
+if (ret) {
+/* If we've found a match but failed to open the device we should
+ remove it from our auto-filter list, so we don't keep trying to
+ open it every 2 seconds. However we cannot destroy / free it
+ here, since we get called from usb_host_initfn, and destroying
+ a qdev from its initfn is not allowed. */
+s-open_failed = ret;
+}
}
return 0;
@@ -1678,9 +1696,16 @@ static int usb_host_auto_scan(void *opaque, int bus_num,
int addr, char *port,
static void usb_host_auto_check(void *unused)
{
-struct USBHostDevice *s;
+struct USBHostDevice *s, *n;
int unconnected = 0;
+/* Cleanup devices wich failed to open last time, see usb_host_auto_scan
+ for why we don't do this after usb_host_auto_scan */
+QTAILQ_FOREACH_SAFE(s, hostdevs, next, n) {
+if (s-open_failed)
+qdev_free(s-dev.qdev);
+}
+
usb_host_scan(NULL, usb_host_auto_scan);
QTAILQ_FOREACH(s, hostdevs, next) {
--
1.7.5.1
[Qemu-devel] [PATCH 10/14] usb-linux: Enlarge buffer for descriptors to 8192 bytes
1024 bytes is way to small, one hd UVC webcam I have over here has so
many resolutions its descriptors take op close to 4k. Hopefully 8k will
be enough for all devices.
---
usb-linux.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index 3508cda..490c49f 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -117,7 +117,7 @@ typedef struct USBHostDevice {
USBDevice dev;
int fd;
-uint8_t descr[1024];
+uint8_t descr[8192];
int descr_len;
int configuration;
int ninterfaces;
--
1.7.5.1
[Qemu-devel] [PATCH 09/14] usb-linux: Don't declare a usbdevice_name
Declaring a usbdevice_name while we still have an explicit call to
usb_host_device_open in vl.c causes usb_host_device_open to get called
twice if the initial call fails.
---
usb-linux.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index eb9805b..3508cda 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -1227,8 +1227,12 @@ static struct USBDeviceInfo usb_host_dev_info = {
.handle_control = usb_host_handle_control,
.handle_reset = usb_host_handle_reset,
.handle_destroy = usb_host_handle_destroy,
+#if 0 /* HDG: having this enabled while still having an explicit call to
+ usb_host_device_open in vl.c causes usb_host_device_open to get called
+ twice if the initial call fails */
.usbdevice_name = host,
.usbdevice_init = usb_host_device_open,
+#endif
.qdev.props = (Property[]) {
DEFINE_PROP_UINT32(hostbus, USBHostDevice, match.bus_num,0),
DEFINE_PROP_UINT32(hostaddr, USBHostDevice, match.addr, 0),
--
1.7.5.1
[Qemu-devel] [PATCH 11/14] usb-bus: Add knowledge of USB_SPEED_SUPER to usb_speed helper
--- hw/usb-bus.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/usb-bus.c b/hw/usb-bus.c index 874c253..91f2083 100644 --- a/hw/usb-bus.c +++ b/hw/usb-bus.c @@ -273,6 +273,7 @@ static const char *usb_speed(unsigned int speed) [ USB_SPEED_LOW ] = 1.5, [ USB_SPEED_FULL ] = 12, [ USB_SPEED_HIGH ] = 480, +[ USB_SPEED_SUPER ] = 5000, }; if (speed = ARRAY_SIZE(txt)) return ?; -- 1.7.5.1
[Qemu-devel] [PATCH 13/14] usb-bus: Don't detach non attached devices on device exit
This causes an Error: tried to detach unattached usb device to be printed,
this can happen when deleting ie a usb host qdev, which did not
get attached (because a device matching the filter never got plugged in).
---
hw/usb-bus.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index bb040d2..0a49921 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
@@ -84,7 +84,9 @@ static int usb_qdev_exit(DeviceState *qdev)
USBDevice *dev = DO_UPCAST(USBDevice, qdev, qdev);
USBBus *bus = usb_bus_from_device(dev);
-usb_device_detach(dev);
+if (dev-attached) {
+usb_device_detach(dev);
+}
bus-ops-device_destroy(bus, dev);
if (dev-info-handle_destroy) {
dev-info-handle_destroy(dev);
--
1.7.5.1
[Qemu-devel] [PATCH 12/14] usb-bus: Don't allow attaching a device to a bus with no free ports
---
hw/usb-bus.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index 91f2083..bb040d2 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
@@ -179,6 +179,11 @@ static void do_attach(USBDevice *dev)
dev-product_desc);
return;
}
+if (bus-nfree == 0) {
+fprintf(stderr, Warning: tried to attach usb device %s to a bus with
no free ports\n,
+dev-product_desc);
+return;
+}
if (dev-port_path) {
QTAILQ_FOREACH(port, bus-free, next) {
if (strcmp(port-path, dev-port_path) == 0) {
--
1.7.5.1
[Qemu-devel] [PATCH 1/4] usb: Add a speedmask to devices
This is used to indicate at which speed[s] the device can operate,
so that this can be checked to match the ports capabilities when it gets
attached to a bus.
Note that currently all usb1 emulated device claim to be fullspeed, this
seems to not cause any problems, but still seems wrong, because with real
hardware keyboards, mice and tablets usually are lo-speed, so reporting these
as fullspeed devices seems wrong.
---
hw/usb-ccid.c |1 +
hw/usb-desc.c | 10 ++
hw/usb.h |3 +++
usb-bsd.c |2 ++
usb-linux.c |1 +
5 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/hw/usb-ccid.c b/hw/usb-ccid.c
index 5b6878b..9e7d6d2 100644
--- a/hw/usb-ccid.c
+++ b/hw/usb-ccid.c
@@ -1283,6 +1283,7 @@ static int ccid_initfn(USBDevice *dev)
s-migration_target_ip = 0;
s-migration_target_port = 0;
s-dev.speed = USB_SPEED_FULL;
+s-dev.speedmask = USB_SPEED_MASK_FULL;
s-notify_slot_change = false;
s-powered = true;
s-pending_answers_num = 0;
diff --git a/hw/usb-desc.c b/hw/usb-desc.c
index 57e8d6b..4f58ae8 100644
--- a/hw/usb-desc.c
+++ b/hw/usb-desc.c
@@ -242,7 +242,17 @@ static void usb_desc_setdefaults(USBDevice *dev)
void usb_desc_init(USBDevice *dev)
{
+const USBDesc *desc = dev-info-usb_desc;
+
+assert(desc != NULL);
dev-speed = USB_SPEED_FULL;
+dev-speedmask = 0;
+if (desc-full) {
+dev-speedmask |= USB_SPEED_MASK_FULL;
+}
+if (desc-high) {
+dev-speedmask |= USB_SPEED_MASK_HIGH;
+}
usb_desc_setdefaults(dev);
}
diff --git a/hw/usb.h b/hw/usb.h
index 097d789..5623f34 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -169,7 +169,10 @@ struct USBDevice {
char *port_path;
void *opaque;
+/* Actual connected speed */
int speed;
+/* Supported speeds, not in info because it may be variable (hostdevs) */
+int speedmask;
uint8_t addr;
char product_desc[32];
int auto_attach;
diff --git a/usb-bsd.c b/usb-bsd.c
index 9bab6e3..11829a2 100644
--- a/usb-bsd.c
+++ b/usb-bsd.c
@@ -368,8 +368,10 @@ USBDevice *usb_host_device_open(const char *devname)
if (dev_info.udi_speed == 1) {
dev-dev.speed = USB_SPEED_LOW - 1;
+dev-dev.speedmask = USB_SPEED_MASK_LOW;
} else {
dev-dev.speed = USB_SPEED_FULL - 1;
+dev-dev.speedmask = USB_SPEED_MASK_FULL;
}
if (strncmp(dev_info.udi_product, product, 7) != 0) {
diff --git a/usb-linux.c b/usb-linux.c
index fe21da1..71e5f4d 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -1141,6 +1141,7 @@ static int usb_host_open(USBHostDevice *dev, int bus_num,
}
}
dev-dev.speed = speed;
+dev-dev.speedmask = (1 speed);
printf(husb: grabbed usb device %d.%d\n, bus_num, addr);
--
1.7.5.1
[Qemu-devel] [PATCH 4/4] usb-linux: allow compatible high speed devices to connect at fullspeed
Some usb2 highspeed devices, like usb-msd devices, work fine when redirected
to a usb1 virtual controller. Allow this to avoid the new speedhecks causing
regressions for users who do not enable the new experimental ehci code.
---
usb-linux.c | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index 71e5f4d..187e6ae 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -1062,6 +1062,42 @@ static int usb_linux_update_endp_table(USBHostDevice *s)
return 0;
}
+/*
+ * Check if we can safely redirect a usb2 device to a usb1 virtual controller,
+ * this function assumes this is safe, if:
+ * 1) There are no isoc endpoints
+ * 2) There are no interrupt endpoints with a max_packet_size 64
+ * Note bulk endpoints with a max_packet_size 64 in theory also are not
+ * usb1 compatible, but in practice this seems to work fine.
+ */
+static int usb_linux_full_speed_compat(USBHostDevice *dev)
+{
+int i, packet_size;
+
+/*
+ * usb_linux_update_endp_table only registers info about ep in the current
+ * interface altsettings, so we need to parse the descriptors again.
+ */
+for (i = 0; (i + 5) dev-descr_len; i += dev-descr[i]) {
+if (dev-descr[i + 1] == USB_DT_ENDPOINT) {
+switch (dev-descr[i + 3] 0x3) {
+case 0x00: /* CONTROL */
+break;
+case 0x01: /* ISO */
+return 0;
+case 0x02: /* BULK */
+break;
+case 0x03: /* INTERRUPT */
+packet_size = dev-descr[i + 4] + (dev-descr[i + 5] 8);
+if (packet_size 64)
+return 0;
+break;
+}
+}
+}
+return 1;
+}
+
static int usb_host_open(USBHostDevice *dev, int bus_num,
int addr, char *port, const char *prod_name, int speed)
{
@@ -1142,6 +1178,9 @@ static int usb_host_open(USBHostDevice *dev, int bus_num,
}
dev-dev.speed = speed;
dev-dev.speedmask = (1 speed);
+if (dev-dev.speed == USB_SPEED_HIGH usb_linux_full_speed_compat(dev)) {
+dev-dev.speedmask |= USB_SPEED_MASK_FULL;
+}
printf(husb: grabbed usb device %d.%d\n, bus_num, addr);
--
1.7.5.1
[Qemu-devel] USB: automatically choose bus to connect to based on speed
This patch series makes the usb subsystem automatically attach a usb device to the right bus, based on the device's and the bus' speed, unless a bus is explicitly specified by the user. This makes the uhci controller more or less act as a companion controller to the ehci controller (if enabled), and makes it easier for end users to redirect usb devices (as they don't need to think about which bus they need to redirect to). Regards, Hans
[Qemu-devel] [PATCH 2/4] usb-bus: Don't allow speed mismatch while attaching devices
---
hw/usb-bus.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index 2ae2678..1817d5c 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
@@ -200,6 +200,11 @@ static int do_attach(USBDevice *dev)
} else {
port = QTAILQ_FIRST(bus-free);
}
+if (!(port-speedmask dev-speedmask)) {
+fprintf(stderr, Warning: speed mismatch trying to attach usb device
%s to bus %s\n,
+dev-product_desc, bus-qbus.name);
+return -1;
+}
dev-attached++;
QTAILQ_REMOVE(bus-free, port, next);
--
1.7.5.1
[Qemu-devel] [PATCH 3/4] usb-bus: Automatically select right usb bus based on device and bus speed
If the bus was not explictly specified by the user, automatically select the
right usb bus based on device and bus speed.
---
hw/qdev.c|2 +-
hw/usb-bus.c | 53 -
hw/usb.h |1 +
3 files changed, 54 insertions(+), 2 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index 9519f5d..f032412 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -260,11 +260,11 @@ DeviceState *qdev_device_add(QemuOpts *opts)
qdev_free(qdev);
return NULL;
}
+qdev-opts = opts;
if (qdev_init(qdev) 0) {
qerror_report(QERR_DEVICE_INIT_FAILED, driver);
return NULL;
}
-qdev-opts = opts;
return qdev;
}
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index 1817d5c..00b2df8 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
@@ -72,6 +72,9 @@ static int usb_qdev_init(DeviceState *qdev, DeviceInfo *base)
pstrcpy(dev-product_desc, sizeof(dev-product_desc), info-product_desc);
dev-info = info;
dev-auto_attach = 1;
+if (qdev-opts qemu_opt_get(qdev-opts, bus)) {
+dev-bus_specified = 1;
+}
QLIST_INIT(dev-strings);
rc = dev-info-init(dev);
if (rc == 0 dev-auto_attach)
@@ -114,6 +117,8 @@ void usb_qdev_register_many(USBDeviceInfo *info)
USBDevice *usb_create(USBBus *bus, const char *name)
{
DeviceState *dev;
+USBDevice *usbdev;
+int bus_specified = 1;
#if 1
/* temporary stopgap until all usb is properly qdev-ified */
@@ -123,11 +128,15 @@ USBDevice *usb_create(USBBus *bus, const char *name)
return NULL;
fprintf(stderr, %s: no bus specified, using \%s\ for \%s\\n,
__FUNCTION__, bus-qbus.name, name);
+bus_specified = 0;
}
#endif
dev = qdev_create(bus-qbus, name);
-return DO_UPCAST(USBDevice, qdev, dev);
+usbdev = DO_UPCAST(USBDevice, qdev, dev);
+usbdev-bus_specified = bus_specified;
+
+return usbdev;
}
USBDevice *usb_create_simple(USBBus *bus, const char *name)
@@ -171,6 +180,35 @@ void usb_unregister_port(USBBus *bus, USBPort *port)
bus-nfree--;
}
+static USBBus *find_bus_by_speed(int speedmask)
+{
+USBBus *bus;
+USBPort *port;
+
+QTAILQ_FOREACH(bus, busses, next) {
+port = QTAILQ_FIRST(bus-free);
+if (port (port-speedmask speedmask)) {
+return bus;
+}
+}
+return NULL;
+}
+
+static USBBus *find_best_bus_by_speed(USBDevice *dev)
+{
+USBBus *bus;
+
+/* If the device supports high speed, first try to find a highspeed port */
+if (dev-speedmask USB_SPEED_MASK_HIGH) {
+bus = find_bus_by_speed(USB_SPEED_MASK_HIGH);
+if (bus) {
+return bus;
+}
+}
+
+return find_bus_by_speed(dev-speedmask);
+}
+
static int do_attach(USBDevice *dev)
{
USBBus *bus = usb_bus_from_device(dev);
@@ -181,6 +219,19 @@ static int do_attach(USBDevice *dev)
dev-product_desc);
return -1;
}
+
+/* If the bus was not explicitly specified, select one by speed */
+if (!dev-bus_specified) {
+USBBus *newbus = find_best_bus_by_speed(dev);
+if (newbus newbus != bus) {
+/* A bit tricky, but safe since we're not attached */
+QLIST_REMOVE(dev-qdev, sibling);
+dev-qdev.parent_bus = newbus-qbus;
+QLIST_INSERT_HEAD(newbus-qbus.children, dev-qdev, sibling);
+bus = newbus;
+}
+}
+
if (bus-nfree == 0) {
fprintf(stderr, Error: tried to attach usb device %s to a bus with no
free ports\n,
dev-product_desc);
diff --git a/hw/usb.h b/hw/usb.h
index 5623f34..807f9e3 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -177,6 +177,7 @@ struct USBDevice {
char product_desc[32];
int auto_attach;
int attached;
+int bus_specified;
int32_t state;
uint8_t setup_buf[8];
--
1.7.5.1
Re: [Qemu-devel] [PATCH 14/14] usb: Proper error propagation for usb_device_attach errors
31.05.2011 13:35, Hans de Goede wrote:
---
hw/usb-bus.c | 23 ---
hw/usb-msd.c |5 +++--
usb-linux.c |6 +-
3 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index 0a49921..2ae2678 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
if (dev-attached) {
-fprintf(stderr, Warning: tried to attach usb device %s twice\n,
+fprintf(stderr, Error: tried to attach usb device %s twice\n,
dev-product_desc);
qemu_error() maybe, while we're at it?
Here and in a few other places.
Thanks!
/mjt
Re: [Qemu-devel] [PATCH 14/14] usb: Proper error propagation for usb_device_attach errors
Hi,
On 05/31/2011 11:42 AM, Michael Tokarev wrote:
31.05.2011 13:35, Hans de Goede wrote:
---
hw/usb-bus.c | 23 ---
hw/usb-msd.c |5 +++--
usb-linux.c |6 +-
3 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index 0a49921..2ae2678 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
if (dev-attached) {
-fprintf(stderr, Warning: tried to attach usb device %s twice\n,
+fprintf(stderr, Error: tried to attach usb device %s twice\n,
dev-product_desc);
qemu_error() maybe, while we're at it?
Here and in a few other places.
That does not seem to exist, do you perhaps mean error_printf() ?
Regards,
Hans
Re: [Qemu-devel] USB: automatically choose bus to connect to based on speed
On 05/31/2011 11:39 AM, Hans de Goede wrote: This patch series makes the usb subsystem automatically attach a usb device to the right bus, based on the device's and the bus' speed, unless a bus is explicitly specified by the user. This makes the uhci controller more or less act as a companion controller to the ehci controller (if enabled), and makes it easier for end users to redirect usb devices (as they don't need to think about which bus they need to redirect to). Shouldn't the correct order for the patches be 1, 4, 2, 3? Paolo
Re: [Qemu-devel] [PATCH 14/14] usb: Proper error propagation for usb_device_attach errors
Am 31.05.2011 11:51, schrieb Hans de Goede:
Hi,
On 05/31/2011 11:42 AM, Michael Tokarev wrote:
31.05.2011 13:35, Hans de Goede wrote:
---
hw/usb-bus.c | 23 ---
hw/usb-msd.c |5 +++--
usb-linux.c |6 +-
3 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index 0a49921..2ae2678 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
if (dev-attached) {
-fprintf(stderr, Warning: tried to attach usb device %s twice\n,
+fprintf(stderr, Error: tried to attach usb device %s twice\n,
dev-product_desc);
qemu_error() maybe, while we're at it?
Here and in a few other places.
That does not seem to exist, do you perhaps mean error_printf() ?
error_report() is what you should use, so that messages go to the
monitor if the function is called from a monitor command. error_printf()
is used by it internally, but usually isn't used directly.
Kevin
Re: [Qemu-devel] [PATCH 14/14] usb: Proper error propagation for usb_device_attach errors
Hi,
On 05/31/2011 11:56 AM, Kevin Wolf wrote:
Am 31.05.2011 11:51, schrieb Hans de Goede:
Hi,
On 05/31/2011 11:42 AM, Michael Tokarev wrote:
31.05.2011 13:35, Hans de Goede wrote:
---
hw/usb-bus.c | 23 ---
hw/usb-msd.c |5 +++--
usb-linux.c |6 +-
3 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index 0a49921..2ae2678 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
if (dev-attached) {
-fprintf(stderr, Warning: tried to attach usb device %s twice\n,
+fprintf(stderr, Error: tried to attach usb device %s twice\n,
dev-product_desc);
qemu_error() maybe, while we're at it?
Here and in a few other places.
That does not seem to exist, do you perhaps mean error_printf() ?
error_report() is what you should use, so that messages go to the
monitor if the function is called from a monitor command. error_printf()
is used by it internally, but usually isn't used directly.
I've looked at error_report, but IMHO it is made of crazy, I'm not going
to construct a json dict every time I need to log some simple error message
(and the existing ones are not suitable for many error messages).
Regards,
Hans
[Qemu-devel] [RFC][PATCH] ide: Break migration by splitting error status from status register
When adding the werror=stop mode, some flags were added to s-status
which are used to determine what kind of operation should be restarted
when the VM is continued.
Unfortunately, it turns out that s-status is in fact a device register
and as such is visible to the guest (some of the abused bits are even
writable for the guest).
Splitting the internal status and the status register into two different
variables is easy enough, but this will break migration: We must have a
way to detect what s-status really means. Is it only the status register
(as used by new versions) or do we have to extract internal error status
flags?
Here we seem to be lacking some kind of optional subsection that would
be simply ignored by older versions, but can contain information for new
versions. Is there any precedence on how to solve this?
---
hw/ide/core.c | 22 +-
hw/ide/internal.h |5 +
hw/ide/pci.c | 19 +--
3 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 95beb17..dc9b94b 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -446,7 +446,7 @@ static int ide_handle_rw_error(IDEState *s, int error, int
op)
if ((error == ENOSPC action == BLOCK_ERR_STOP_ENOSPC)
|| action == BLOCK_ERR_STOP_ANY) {
s-bus-dma-ops-set_unit(s-bus-dma, s-unit);
-s-bus-dma-ops-add_status(s-bus-dma, op);
+s-error_status = op;
bdrv_mon_event(s-bs, BDRV_ACTION_STOP, is_read);
vm_stop(VMSTOP_DISKFULL);
} else {
@@ -1847,6 +1847,13 @@ static bool ide_atapi_gesn_needed(void *opaque)
return s-events.new_media || s-events.eject_request;
}
+static bool ide_error_needed(void *opaque)
+{
+IDEState *s = opaque;
+
+return (s-error_status != 0);
+}
+
/* Fields for GET_EVENT_STATUS_NOTIFICATION ATAPI command */
const VMStateDescription vmstate_ide_atapi_gesn_state = {
.name =ide_drive/atapi/gesn_state,
@@ -1879,6 +1886,16 @@ const VMStateDescription vmstate_ide_drive_pio_state = {
}
};
+const VMStateDescription vmstate_ide_error_status = {
+.name =ide_drive/error,
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields = (VMStateField []) {
+VMSTATE_INT32(error_status, IDEState),
+}
+};
+
const VMStateDescription vmstate_ide_drive = {
.name = ide_drive,
.version_id = 3,
@@ -1916,6 +1933,9 @@ const VMStateDescription vmstate_ide_drive = {
.vmsd = vmstate_ide_atapi_gesn_state,
.needed = ide_atapi_gesn_needed,
}, {
+.vmsd = vmstate_ide_error_status,
+.needed = ide_error_needed,
+}, {
/* empty */
}
}
diff --git a/hw/ide/internal.h b/hw/ide/internal.h
index c2b35ec..9ba4b34 100644
--- a/hw/ide/internal.h
+++ b/hw/ide/internal.h
@@ -440,6 +440,9 @@ struct IDEState {
uint8_t end_transfer_fn_idx;
QEMUTimer *sector_write_timer; /* only used for win2k install hack */
uint32_t irq_count; /* counts IRQs when using win2k install hack */
+
+int error_status;
+
/* CF-ATA extended error */
uint8_t ext_error;
/* CF-ATA metadata storage */
@@ -505,6 +508,8 @@ struct IDEDeviceInfo {
#define BM_STATUS_DMAING 0x01
#define BM_STATUS_ERROR 0x02
#define BM_STATUS_INT0x04
+
+/* FIXME These are not status register bits */
#define BM_STATUS_DMA_RETRY 0x08
#define BM_STATUS_PIO_RETRY 0x10
#define BM_STATUS_RETRY_READ 0x20
diff --git a/hw/ide/pci.c b/hw/ide/pci.c
index a4726ad..531ad97 100644
--- a/hw/ide/pci.c
+++ b/hw/ide/pci.c
@@ -183,27 +183,34 @@ static void bmdma_restart_dma(BMDMAState *bm, int is_read)
bmdma_start_dma(bm-dma, s, bm-dma_cb);
}
+/* TODO This should be common IDE code */
static void bmdma_restart_bh(void *opaque)
{
BMDMAState *bm = opaque;
+IDEState *s;
int is_read;
qemu_bh_delete(bm-bh);
bm-bh = NULL;
-is_read = !!(bm-status BM_STATUS_RETRY_READ);
+if (bm-unit == (uint8_t) -1) {
+return;
+}
+
+s = bmdma_active_if(bm);
+is_read = !!(s-error_status BM_STATUS_RETRY_READ);
-if (bm-status BM_STATUS_DMA_RETRY) {
-bm-status = ~(BM_STATUS_DMA_RETRY | BM_STATUS_RETRY_READ);
+if (s-error_status BM_STATUS_DMA_RETRY) {
+s-error_status = ~(BM_STATUS_DMA_RETRY | BM_STATUS_RETRY_READ);
bmdma_restart_dma(bm, is_read);
-} else if (bm-status BM_STATUS_PIO_RETRY) {
-bm-status = ~(BM_STATUS_PIO_RETRY | BM_STATUS_RETRY_READ);
+} else if (s-error_status BM_STATUS_PIO_RETRY) {
+s-error_status = ~(BM_STATUS_PIO_RETRY | BM_STATUS_RETRY_READ);
if (is_read) {
ide_sector_read(bmdma_active_if(bm));
} else {
ide_sector_write(bmdma_active_if(bm));
}
-} else if (bm-status BM_STATUS_RETRY_FLUSH) {
+} else if (s-error_status BM_STATUS_RETRY_FLUSH) {
ide_flush_cache(bmdma_active_if(bm));
}
}
Re: [Qemu-devel] [PATCH 14/14] usb: Proper error propagation for usb_device_attach errors
Am 31.05.2011 12:05, schrieb Hans de Goede:
Hi,
On 05/31/2011 11:56 AM, Kevin Wolf wrote:
Am 31.05.2011 11:51, schrieb Hans de Goede:
Hi,
On 05/31/2011 11:42 AM, Michael Tokarev wrote:
31.05.2011 13:35, Hans de Goede wrote:
---
hw/usb-bus.c | 23 ---
hw/usb-msd.c |5 +++--
usb-linux.c |6 +-
3 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index 0a49921..2ae2678 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
if (dev-attached) {
-fprintf(stderr, Warning: tried to attach usb device %s twice\n,
+fprintf(stderr, Error: tried to attach usb device %s twice\n,
dev-product_desc);
qemu_error() maybe, while we're at it?
Here and in a few other places.
That does not seem to exist, do you perhaps mean error_printf() ?
error_report() is what you should use, so that messages go to the
monitor if the function is called from a monitor command. error_printf()
is used by it internally, but usually isn't used directly.
I've looked at error_report, but IMHO it is made of crazy, I'm not going
to construct a json dict every time I need to log some simple error message
(and the existing ones are not suitable for many error messages).
error_report() works with plain strings. Maybe you confuse it with the
QMP error reporting function?
Kevin
Re: [Qemu-devel] USB: automatically choose bus to connect to based on speed
Hi, On 05/31/2011 11:52 AM, Paolo Bonzini wrote: On 05/31/2011 11:39 AM, Hans de Goede wrote: This patch series makes the usb subsystem automatically attach a usb device to the right bus, based on the device's and the bus' speed, unless a bus is explicitly specified by the user. This makes the uhci controller more or less act as a companion controller to the ehci controller (if enabled), and makes it easier for end users to redirect usb devices (as they don't need to think about which bus they need to redirect to). Shouldn't the correct order for the patches be 1, 4, 2, 3? That is not the order in which they were written :) But I see your point. Regards, Hans
Re: [Qemu-devel] [PATCH 14/14] usb: Proper error propagation for usb_device_attach errors
Hi,
On 05/31/2011 12:12 PM, Kevin Wolf wrote:
Am 31.05.2011 12:05, schrieb Hans de Goede:
Hi,
On 05/31/2011 11:56 AM, Kevin Wolf wrote:
Am 31.05.2011 11:51, schrieb Hans de Goede:
Hi,
On 05/31/2011 11:42 AM, Michael Tokarev wrote:
31.05.2011 13:35, Hans de Goede wrote:
---
hw/usb-bus.c | 23 ---
hw/usb-msd.c |5 +++--
usb-linux.c |6 +-
3 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index 0a49921..2ae2678 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
if (dev-attached) {
-fprintf(stderr, Warning: tried to attach usb device %s twice\n,
+fprintf(stderr, Error: tried to attach usb device %s twice\n,
dev-product_desc);
qemu_error() maybe, while we're at it?
Here and in a few other places.
That does not seem to exist, do you perhaps mean error_printf() ?
error_report() is what you should use, so that messages go to the
monitor if the function is called from a monitor command. error_printf()
is used by it internally, but usually isn't used directly.
I've looked at error_report, but IMHO it is made of crazy, I'm not going
to construct a json dict every time I need to log some simple error message
(and the existing ones are not suitable for many error messages).
error_report() works with plain strings. Maybe you confuse it with the
QMP error reporting function?
Ah yes I was looking at qerror_report (who ever named that, having just
one letter difference in the function names is a bad idea). error_report
looks fine.
I'll wait a bit for more feedback and then change
[PATCH 14/14] usb: Proper error propagation for usb_device_attach errors
To turn the fprintf(stderr, ... calls into error_report calls.
Thanks Regards,
Hans
Kevin
Re: [Qemu-devel] [PATCH] xen: fix interrupt routing
On Sat, 28 May 2011, Alexander Graf wrote:
On 26.05.2011, at 17:48, Stefano Stabellini wrote:
xen: fix interrupt routing
- remove i440FX-xen and i440fx_write_config_xen
we don't need to intercept pci config writes to i440FX anymore;
Why not? In which version? Did anything below change? What about compat code?
Older hypervisor versions?
Nothing changed, I think it was a genuine mistake in the original patch
series: the intention was to catch the pci config writes to 0x60-0x63 to
reprogram the xen pci link routes accordingly (see
xen_piix_pci_write_config_client). If I am not mistaken a similar thing
is done by non-Xen Qemu in piix3_update_irq_levels.
- introduce PIIX3-xen and piix3_write_config_xen
we do need to intercept pci config write to the PCI-ISA bridge to update
the PCI link routing;
- set the number of PIIX3-xen interrupts lines to 128;
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
diff --git a/hw/pc.h b/hw/pc.h
index 0dcbee7..6d5730b 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -176,7 +176,6 @@ struct PCII440FXState;
typedef struct PCII440FXState PCII440FXState;
PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int *piix_devfn,
qemu_irq *pic, ram_addr_t ram_size);
-PCIBus *i440fx_xen_init(PCII440FXState **pi440fx_state, int *piix3_devfn,
qemu_irq *pic, ram_addr_t ram_size);
void i440fx_init_memory_mappings(PCII440FXState *d);
/* piix4.c */
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 9a22a8a..ba198de 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -124,11 +124,7 @@ static void pc_init1(ram_addr_t ram_size,
isa_irq = qemu_allocate_irqs(isa_irq_handler, isa_irq_state, 24);
if (pci_enabled) {
-if (!xen_enabled()) {
-pci_bus = i440fx_init(i440fx_state, piix3_devfn, isa_irq,
ram_size);
-} else {
-pci_bus = i440fx_xen_init(i440fx_state, piix3_devfn,
isa_irq, ram_size);
-}
+pci_bus = i440fx_init(i440fx_state, piix3_devfn, isa_irq,
ram_size);
} else {
pci_bus = NULL;
i440fx_state = NULL;
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 7f1c4cc..3d73a42 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -40,6 +40,7 @@ typedef PCIHostState I440FXState;
#define PIIX_NUM_PIC_IRQS 16 /* i8259 * 2 */
#define PIIX_NUM_PIRQS 4ULL/* PIRQ[A-D] */
+#define XEN_PIIX_NUM_PIRQS 128ULL
#define PIIX_PIRQC 0x60
typedef struct PIIX3State {
@@ -78,6 +79,8 @@ struct PCII440FXState {
#define I440FX_SMRAM0x72
static void piix3_set_irq(void *opaque, int pirq, int level);
+static void piix3_write_config_xen(PCIDevice *dev,
+ uint32_t address, uint32_t val, int len);
/* return the global irq number corresponding to a given device irq
pin. We could also use the bus number to have a more precise
@@ -173,13 +176,6 @@ static void i440fx_write_config(PCIDevice *dev,
}
}
-static void i440fx_write_config_xen(PCIDevice *dev,
-uint32_t address, uint32_t val, int
len)
-{
-xen_piix_pci_write_config_client(address, val, len);
-i440fx_write_config(dev, address, val, len);
-}
-
static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
{
PCII440FXState *d = opaque;
@@ -267,8 +263,17 @@ static PCIBus *i440fx_common_init(const char
*device_name,
d = pci_create_simple(b, 0, device_name);
*pi440fx_state = DO_UPCAST(PCII440FXState, dev, d);
-piix3 = DO_UPCAST(PIIX3State, dev,
- pci_create_simple_multifunction(b, -1, true,
PIIX3));
+if (xen_enabled()) {
+piix3 = DO_UPCAST(PIIX3State, dev,
+pci_create_simple_multifunction(b, -1, true, PIIX3-xen));
+pci_bus_irqs(b, xen_piix3_set_irq, xen_pci_slot_get_pirq,
+piix3, XEN_PIIX_NUM_PIRQS);
But with XEN_PIIX_NUM_PIRQS it's not a piix3 anymore, no? What's the reason
behind this change?
It is still a piix3, but also provides non-legacy interrupt links to the
IO-APIC.
The four pins of each PCI device on the bus not only are routed to the
normal four pirqs (programmed writing to 0x60-0x63, see above) but also
they are connected to the IO-APIC directly.
These additional routes can only be discovered through ACPI, so you need
matching ACPI tables. We used to build the old ACPI tables like this:
/* PRTA: APIC routing table (via non-legacy IOAPIC GSIs). */
printf(Name(PRTA, Package() {\n);
for ( dev = 1; dev 32; dev++ )
for ( intx = 0; intx 4; intx++ ) /* INTA-D */
printf(Package(){0x%04x, %u, 0, %u},\n,
dev, intx, ((dev*4+dev/8+intx)31)+16);
printf(})\n);
Re: [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: BrillyWubrill...@viatech.com.cn
Signed-off-by: KaryJinkary...@viatech.com.cn
---
target-i386/cpu.h |7 +++
target-i386/cpuid.c | 53
+++--
target-i386/kvm.c | 15 +++
3 files changed, 73 insertions(+), 2 deletions(-)
--- a/target-i386/cpu.h 2011-05-30 16:20:57.261342707 +0800
+++ b/target-i386/cpu.h 2011-05-31 16:49:43.617252109 +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-31 16:47:55.077252267 +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,18 @@ 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 +1258,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);
+
+for
Re: [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: BrillyWubrill...@viatech.com.cn
Signed-off-by: KaryJinkary...@viatech.com.cn
---
target-i386/cpu.h |7 +++
target-i386/cpuid.c | 53
+++--
target-i386/kvm.c | 15 +++
3 files changed, 73 insertions(+), 2 deletions(-)
--- a/target-i386/cpu.h 2011-05-30 16:20:57.261342707 +0800
+++ b/target-i386/cpu.h 2011-05-31 16:49:43.617252109 +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-31 16:47:55.077252267 +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,18 @@ 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 +1258,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);
+
+for
Re: [Qemu-devel] [SeaBIOS] seabios: acpi: add _RMV control method for PCI devices
On Sat, Dec 11, 2010 at 09:39:30AM +0200, Avi Kivity wrote: On 12/08/2010 07:08 PM, Marcelo Tosatti wrote: Use _RMV method to indicate whether device can be removed. Data is retrieved from QEMU via I/O port 0xae0c. Where did this port come from? Its the next available address after PCI EJ base, used for QEMU-ACPI hotplug communication. What's the protocol? ACPI reads the 32-bit field indicating the return value of the _RMV method (which is used by Windows to decide removability). 1-bit per slot. More ports have to be registered if more buses are added. Maybe we should do this via fw_cfg. I don't see a need for it? (yes, it might be possible, but i'm not familiar enough with AML).
[Qemu-devel] Liga de Futbol 7. Inicia Junio 6
Sendero Soccer Liga de Futbol 7 Torneo de verano, fecha de inicio: 6 de Junio 2011 Inscripciones Abiertas Liga de Lunes a Viernes $6,000 Incluye 9 partidos + finales Liga de Fin de Semana $5,500 Incluye 9 partidos + finales Servicios Adicionales que ofrecemos: Renta de canchas $500 por hora $650 con arbitro incluido Organización de torneos a dependencias públicas, empresas e instituciones. En horarios matutino, vespertino y nocturno Gestión deportiva. Para mayores informes Llamar al Tel: (81) 8351-2020 Ubicación: Av. José López Portillo Km 9.94 (Carretera Monterrey a Laredo) 700 metros al norte de Sendero Divisorio Norte de sur a norte pasando Sendero, inmediatamente tomar carril lateral. Entrada por Gas Ideal. www.senderosoccer.com E-Mail: i...@senderosoccer.com La campaña FUTBOLTON te obsequia el HIMNO FUTBOLTON para que lo disfrutes. Un éxito más de Jauregui Descárgalo gratis en www.futbolton.org FUTBOLTON es una campaña más de: Unidos en la Prevención de Adicciones A.C. www.adicciones.org.mx
[Qemu-devel] [PATCH] qemu-img create: Fix displayed default cluster size
When not specifying a cluster size on the command line, qemu-img printed
a cluster size of 0:
Formatting '/tmp/test.qcow2', fmt=qcow2 size=67108864
encryption=off cluster_size=0
This patch adds the default cluster size to the QEMUOptionParameter list, so
that it displays the default value that is used.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/qcow2.c |5 +++--
block/qcow2.h |2 ++
block/qed.c |3 ++-
block/vdi.c |6 --
4 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
index 6ad829b..30b6692 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -1069,7 +1069,7 @@ static int qcow2_create(const char *filename,
QEMUOptionParameter *options)
const char *backing_fmt = NULL;
uint64_t sectors = 0;
int flags = 0;
-size_t cluster_size = 65536;
+size_t cluster_size = DEFAULT_CLUSTER_SIZE;
int prealloc = 0;
/* Read out options */
@@ -1378,7 +1378,8 @@ static QEMUOptionParameter qcow2_create_options[] = {
{
.name = BLOCK_OPT_CLUSTER_SIZE,
.type = OPT_SIZE,
-.help = qcow2 cluster size
+.help = qcow2 cluster size,
+.value = { .n = DEFAULT_CLUSTER_SIZE },
},
{
.name = BLOCK_OPT_PREALLOC,
diff --git a/block/qcow2.h b/block/qcow2.h
index a019831..e1ae3e8 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -54,6 +54,8 @@
/* Must be at least 4 to cover all cases of refcount table growth */
#define REFCOUNT_CACHE_SIZE 4
+#define DEFAULT_CLUSTER_SIZE 65536
+
typedef struct QCowHeader {
uint32_t magic;
uint32_t version;
diff --git a/block/qed.c b/block/qed.c
index da0bf31..3970379 100644
--- a/block/qed.c
+++ b/block/qed.c
@@ -1464,7 +1464,8 @@ static QEMUOptionParameter qed_create_options[] = {
}, {
.name = BLOCK_OPT_CLUSTER_SIZE,
.type = OPT_SIZE,
-.help = Cluster size (in bytes)
+.help = Cluster size (in bytes),
+.value = { .n = QED_DEFAULT_CLUSTER_SIZE },
}, {
.name = BLOCK_OPT_TABLE_SIZE,
.type = OPT_SIZE,
diff --git a/block/vdi.c b/block/vdi.c
index 701745b..4c9e201 100644
--- a/block/vdi.c
+++ b/block/vdi.c
@@ -87,6 +87,7 @@ void uuid_unparse(const uuid_t uu, char *out);
#define MiB (KiB * KiB)
#define SECTOR_SIZE 512
+#define DEFAULT_CLUSTER_SIZE (1 * MiB)
#if defined(CONFIG_VDI_DEBUG)
#define logout(fmt, ...) \
@@ -803,7 +804,7 @@ static int vdi_create(const char *filename,
QEMUOptionParameter *options)
int result = 0;
uint64_t bytes = 0;
uint32_t blocks;
-size_t block_size = 1 * MiB;
+size_t block_size = DEFAULT_CLUSTER_SIZE;
uint32_t image_type = VDI_TYPE_DYNAMIC;
VdiHeader header;
size_t i;
@@ -921,7 +922,8 @@ static QEMUOptionParameter vdi_create_options[] = {
{
.name = BLOCK_OPT_CLUSTER_SIZE,
.type = OPT_SIZE,
-.help = VDI cluster (block) size
+.help = VDI cluster (block) size,
+.value = { .n = DEFAULT_CLUSTER_SIZE },
},
#endif
#if defined(CONFIG_VDI_STATIC_IMAGE)
--
1.7.5.2
Re: [Qemu-devel] KVM call agenda for May 31st
Juan Quintela quint...@redhat.com wrote: Please send in any agenda items you are interested in covering. Thanks, Juan. As there is no agenda, call got cancelled. See you next week, Juan.
[Qemu-devel] test images for qemu omap1 machines (cheetah, sx1, sx1-v1)
Hi; I'm currently looking at pulling the omap3 support patches into shape for submitting to upstream qemu. As part of this I'd like to test that I don't accidentally break the existing omap1/omap2 support. I have a test image for omap2 (n800/n810), but haven't been able to find any for the omap1 machines (cheetah, sx1, sx1-v1) we support. Does anybody have any test images for these omap1 machines? Thanks in advance -- PMM
[Qemu-devel] [PATCH] s390x: fix cksm instruction
The cksm instruction was implemented incorrectly, rendering UDP and TCP
checksum calculation wrong, making an emulated s390x Linux guest break
in most networking operations.
This patch fixes odd end checksum calculation, takes the input register
as input for the checksum and optimizes the overflow pieces by a bit.
Signed-off-by: Alexander Graf ag...@suse.de
---
target-s390x/op_helper.c | 28
1 files changed, 8 insertions(+), 20 deletions(-)
diff --git a/target-s390x/op_helper.c b/target-s390x/op_helper.c
index 49760a4..db03a79 100644
--- a/target-s390x/op_helper.c
+++ b/target-s390x/op_helper.c
@@ -1731,25 +1731,15 @@ void HELPER(sqdbr)(uint32_t f1, uint32_t f2)
env-fregs[f1].d = float64_sqrt(env-fregs[f2].d, env-fpu_status);
}
-static inline uint64_t cksm_overflow(uint64_t cksm)
-{
-if (cksm 0xULL) {
-cksm = 0xULL;
-cksm++;
-}
-return cksm;
-}
-
/* checksum */
void HELPER(cksm)(uint32_t r1, uint32_t r2)
{
uint64_t src = get_address_31fix(r2);
uint64_t src_len = env-regs[(r2 + 1) 15];
-uint64_t cksm = 0;
+uint64_t cksm = (uint32_t)env-regs[r1];
while (src_len = 4) {
cksm += ldl(src);
-cksm = cksm_overflow(cksm);
/* move to next word */
src_len -= 4;
@@ -1760,26 +1750,24 @@ void HELPER(cksm)(uint32_t r1, uint32_t r2)
case 0:
break;
case 1:
-cksm += ldub(src);
-cksm = cksm_overflow(cksm);
+cksm += ldub(src) 24;
break;
case 2:
-cksm += lduw(src);
-cksm = cksm_overflow(cksm);
+cksm += lduw(src) 16;
break;
case 3:
-/* XXX check if this really is correct */
-cksm += lduw(src) 8;
-cksm += ldub(src + 2);
-cksm = cksm_overflow(cksm);
+cksm += lduw(src) 16;
+cksm += ldub(src + 2) 8;
break;
}
/* indicate we've processed everything */
+env-regs[r2] = src + src_len;
env-regs[(r2 + 1) 15] = 0;
/* store result */
-env-regs[r1] = (env-regs[r1] 0xULL) | (uint32_t)cksm;
+env-regs[r1] = (env-regs[r1] 0xULL) |
+((uint32_t)cksm + (cksm 32));
}
static inline uint32_t cc_calc_ltgt_32(CPUState *env, int32_t src,
--
1.6.0.2
Re: [Qemu-devel] [PATCH 3/3] QMP: Introduce the BLOCK_MEDIA_EJECT event
On Tue, 31 May 2011 10:12:17 +0200
Kevin Wolf kw...@redhat.com wrote:
Am 30.05.2011 16:49, schrieb Markus Armbruster:
Luiz Capitulino lcapitul...@redhat.com writes:
On Sat, 28 May 2011 09:58:24 +0200
Markus Armbruster arm...@redhat.com wrote:
Luiz Capitulino lcapitul...@redhat.com writes:
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
@@ -661,6 +661,11 @@ static int eject_device(Monitor *mon,
BlockDriverState *bs, int force)
return -1;
}
}
+
+if (bdrv_is_removable(bs) bdrv_is_inserted(bs)) {
+bdrv_eject_mon_event(bs);
+}
+
bdrv_close(bs);
return 0;
}
This covers monitor-initiated eject (commands eject and change).
The event is not suppressed when the tray is already open (previous
guest-initiated eject), is it?. Contradicts spec.
That's a bug.
The event is suppressed when the tray is empty.
eject -f on a non-removable drive does not trigger an event. Why
treat it specially? I'm not saying you shouldn't, just wondering.
Ejecting a non-removable drive is a qemu bug.
It's clearly intentional, so it's a (mis-)feature, not a bug.
Calling it eject is a bug, as it's not exactly what the command does.
Is there really a use case for it? The closest thing to a specification
that we have is the help text and it says:
.help = eject a removable medium (use -f to force it),
QMP describes it like this:
Eject a removable medium.
So I start tending to agree that this whole trouble around the 'eject'
monitor command is in fact a long standing bug rather than overloaded
semantics. Nowhere is stated that it disconnects a BlockDriverState from
the image, and I can't imagine a use case for this semantics either.
That's my thinking too.
Do we break anything if we make eject really eject the medium (we have a
virtual tray status now) instead of just closing the image?
I don't think so. I guess users/clients really have the expectation that
the only result is to get the media ejected.
Now, -f can be used with non-removable media. There's some risk of
breakage here if clients are using this to unplug devices. But I think
this a case where we'll have to pay the price for the breakage (if any).
most visible change is that we'll eject the host medium when using
pass-through. I consider this an additional bugfix.
Yes.
Re: [Qemu-devel] [PULL] usb patch queue: initial usb 2.0 support.
On 05/26/2011 05:13 AM, Gerd Hoffmann wrote: On 05/23/11 11:43, Gerd Hoffmann wrote: Hi, Here is the usb patch queue, with EHCI support being the outstanding new feature. Most patches are unmodified. Patch #5 got a better commit message. The EHCI patch now lists all contributes in the commit message too (they where listed in the source code only before), I hope everybody is happy with that now. are available in the git repository at: git://git.kraxel.org/qemu usb.13.pull Pushed a slightly updated usb.14.pull branch. Rebased to latest master. Fixed the FSF address as noted by blueswirl. No other changes, so I don't spam the list again with the whole series. The issue with async packets on unplug noticed by Hans (which isn't new) will be fixed with the next batch of usb patches. Pulled. Thanks. Regards, Anthony Liguori please pull, Gerd
Re: [Qemu-devel] [PULL v5 00/25] SCSI subsystem improvements
On 05/26/2011 05:56 AM, Paolo Bonzini wrote: The following changes since commit aa29141d84d58171c2d219f0a4b599bd76fb2e37: Merge remote-tracking branch 'kraxel/CVE-2011-1751' into staging (2011-05-25 07:04:13 -0500) are available in the git repository at: git://github.com/bonzini/qemu.git scsi.2 This series includes the following improvements to the SCSI subsystem: Pulled. Thanks. Regards, Anthony Liguori 1) introduction of SCSIBusOps that generalize the existing command_complete callback; 2) widespread use of the SCSIRequest abstraction, with simpler memory management (refcounting) and with various common idioms converted into simple C functions instead of duplicating them all over the place; 3) support for autosense. Some patches are from Hannes Reinecke's megasas patchset posted last November, forward ported and applied to the new vSCSI controller as well. Most have been acked by Christoph; I fixed all issues he pointed out in the others. I already planned the following two series too: 1) adding support for zerocopy. Previous attempts were rejected because they were applied to real devices (thus making for example an IOMMU hard to impossible). However, for PV devices zerocopy should be uncontroversial---and it is a must to get competitive performance WRT virtio-blk. I'll use vmw-pvscsi for the first implementation and for benchmarking. 2) adding support for multiple LUNs; see recently posted RFC for this. After this I'll work on the virtio-scsi device model. Testing: - RHEL6.1 install complete to scsi-disk with lsi, from scsi-generic CD - iozone run with lsi on scsi-disk target - RHEL6.1 install to usb-msd from IDE CD is too slow, but it manages to format /boot in ~10 minutes with or without the patches - RHEL6.1 install with vscsi with scsi-disk CD and installation disk hung at the same place with or without the series, perhaps it was just me being impatient. esp is only compile tested. Please review and merge. v4-v5: SCSIBusOps now const-ified. Added braces here and there. Added patch 5. v3-v4: renamed scsi_req_kick to scsi_req_continue. Changed SCSIBusOps to pointer. Removed scsi_req_free, merged it into scsi_req_unref. Added head comments for some functions. Renamed arguments to HBA callbacks. Added patches 23 and 24 v2-v3: included fixes for Jonathan Nieder's recently reported bug v1-v2: rebased, added patch 21 Hannes Reinecke (4): scsi: Use 'SCSIRequest' directly scsi: Update sense code handling scsi: Implement 'get_sense' callback scsi-disk: add data direction checking Paolo Bonzini (21): scsi: add tracing of scsi requests scsi-generic: Remove bogus double complete scsi: introduce scsi_req_data scsi: introduce SCSIBusOps scsi-generic: do not use a stale aiocb scsi: reference-count requests lsi: extract lsi_find_by_tag scsi: commonize purging requests scsi: introduce scsi_req_abort scsi: introduce scsi_req_cancel scsi: use scsi_req_complete scsi: do not call send_command directly scsi: introduce scsi_req_new scsi: introduce scsi_req_continue scsi: introduce scsi_req_get_buf scsi: make write_data return void scsi-generic: Handle queue full esp: rename sense to status scsi: split command_complete callback in two scsi: rename arguments to the new callbacks scsi: ignore LUN field in the CDB hw/esp.c | 119 ++-- hw/lsi53c895a.c | 200 --- hw/scsi-bus.c | 220 +++ hw/scsi-disk.c| 271 ++--- hw/scsi-generic.c | 223 +--- hw/scsi.h | 91 ++ hw/spapr_vscsi.c | 187 hw/usb-msd.c | 120 ++-- trace-events |8 ++ 9 files changed, 866 insertions(+), 573 deletions(-)
Re: [Qemu-devel] [PULL] virtio-serial updates
On 05/27/2011 05:20 AM, Amit Shah wrote: Hello, Please pull to get virtio-serial cleanups from Markus and a move to bh for flushing out throttled data from Alon. (git mirror might take some time to sync). The following changes since commit aa29141d84d58171c2d219f0a4b599bd76fb2e37: Merge remote-tracking branch 'kraxel/CVE-2011-1751' into staging (2011-05-25 07:04:13 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/virt/qemu/amit/virtio-serial.git for-anthony Pulled. Thanks. Regards, Anthony Liguori Alon Levy (1): virtio-serial-bus: use bh for unthrottling Markus Armbruster (5): virtio-serial: Plug memory leak on qdev exit() virtio-serial: Clean up virtconsole detection virtio-serial: Drop useless property is_console virtio-serial: Drop redundant VirtIOSerialPort member info virtio-console: Simplify init callbacks hw/virtio-console.c| 47 +-- hw/virtio-serial-bus.c | 83 ++- hw/virtio-serial.h | 11 +-- 3 files changed, 70 insertions(+), 71 deletions(-) Amit
Re: [Qemu-devel] [PULL] Trivial patches for May 22 to May 29 2011
On 05/29/2011 06:36 AM, Stefan Hajnoczi wrote: The following changes since commit 2eb9f241824d000fcd90bd7f4b49e40b88e62975: bitbang_i2c: Fix spurious slave read after NACK (2011-05-28 16:20:43 +0200) are available in the git repository at: ssh://repo.or.cz/srv/git/qemu/stefanha.git trivial-patches Stefan Weil (2): pflash_cfi02: Fix a typo in debug code (TARGET_FMT_pld - TARGET_FMT_plx) Fix spelling in comment (additon - addition) hw/pflash_cfi02.c |2 +- tcg/tcg.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Pulled. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 3/3] QMP: Introduce the BLOCK_MEDIA_EJECT event
On 05/31/2011 08:35 AM, Luiz Capitulino wrote: On Tue, 31 May 2011 10:12:17 +0200 Do we break anything if we make eject really eject the medium (we have a virtual tray status now) instead of just closing the image? I don't think so. I guess users/clients really have the expectation that the only result is to get the media ejected. Now, -f can be used with non-removable media. There's some risk of breakage here if clients are using this to unplug devices. But I think this a case where we'll have to pay the price for the breakage (if any). Only badness can ensue from doing that today so I see no reason to preserve this functionality. Regards, Anthony Liguori most visible change is that we'll eject the host medium when using pass-through. I consider this an additional bugfix. Yes.
Re: [Qemu-devel] [Bug 788697] Re: [PowerPC] [patch] mtmsr does not preserve high bits of MSR
On 05/26/11 18:47, agraf wrote: On 27.05.2011, at 01:33, Nathan Whitehorn wrote: On 05/26/11 11:45, agraf wrote: On 26.05.2011, at 18:09, Nathan Whitehorn wrote: ** Patch added: mtmstr.diff https://bugs.launchpad.net/bugs/788697/+attachment/2143748/+files/mtmstr.diff -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/788697 Title: [PowerPC] [patch] mtmsr does not preserve high bits of MSR Status in QEMU: New Bug description: The mtmsr instruction on 64-bit PPC does not preserve the high-order 32-bits of the MSR the way it is supposed to, instead setting them to 0, which takes 64-bit code out of 64-bit mode. There is some code that does the right thing, but it brokenly only preserves these bits when the thread is not in 64-bit mode (i.e. when it doesn't matter). The attached patch unconditionally enables this code when TARGET_PPC64 is set, per the ISA spec, which fixes early boot failures trying to start FreeBSD/powerpc64 under qemu. Please send the patch as proper patch to the ML and CC me. What isn't proper about the patch? I'm happy to re-email it, but don't want things to be in the wrong format. -Nathan The patch needs a patch description in its header and a subject line (all of which are present in the bug, so it's a simple matter of copypaste). Basically at the end of the day, I should be able to save the mail and git am on it and simply have it in my tree :). Also, does this get FreeBSD booting up to anything useful, so I can verify it helps? OK, I'll send this one out to today. The other issue I'm having (aside from our own bugs), is that SPR_PIR is not implemented for the POWER7 target. The architecture manual claims it is implemented on all Book-3S compliant CPUs, but it seems to be implemented sort of ad-hoc in target-ppc.c (e.g. the 604, 620, and 7400 have it, but not the 750, 970, or POWER7). -Nathan -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/788697 Title: [PowerPC] [patch] mtmsr does not preserve high bits of MSR Status in QEMU: New Bug description: The mtmsr instruction on 64-bit PPC does not preserve the high-order 32-bits of the MSR the way it is supposed to, instead setting them to 0, which takes 64-bit code out of 64-bit mode. There is some code that does the right thing, but it brokenly only preserves these bits when the thread is not in 64-bit mode (i.e. when it doesn't matter). The attached patch unconditionally enables this code when TARGET_PPC64 is set, per the ISA spec, which fixes early boot failures trying to start FreeBSD/powerpc64 under qemu.
Re: [Qemu-devel] [PATCH] #include cleanliness
On 05/30/2011 04:06 AM, Avi Kivity wrote: 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 Kivitya...@redhat.com --- 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 + +#includestdbool.h 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... Fortunately, guards will prevent infinite recursion here :-) I think osdep.h matches the help with portability label better, no? I don't disagree, but that's not the purpose of osdep.h today. qemu-common.h is a header file that's more or less supposed to be included by everything. It should prevent explicit #include's for system headers. Regards, Anthony Liguori
Re: [Qemu-devel] [RFC]QEMU disk I/O limits
On Mon, May 30, 2011 at 01:09:23PM +0800, Zhi Yong Wu wrote: Hello, all, I have prepared to work on a feature called Disk I/O limits for qemu-kvm projeect. This feature will enable the user to cap disk I/O amount performed by a VM.It is important for some storage resources to be shared among multi-VMs. As you've known, if some of VMs are doing excessive disk I/O, they will hurt the performance of other VMs. Hi Zhiyong, Why not use kernel blkio controller for this and why reinvent the wheel and implement the feature again in qemu? Thanks Vivek More detail is available here: http://wiki.qemu.org/Features/DiskIOLimits 1.) Why we need per-drive disk I/O limits As you've known, for linux, cgroup blkio-controller has supported I/O throttling on block devices. More importantly, there is no single mechanism for disk I/O throttling across all underlying storage types (image file, LVM, NFS, Ceph) and for some types there is no way to throttle at all. Disk I/O limits feature introduces QEMU block layer I/O limits together with command-line and QMP interfaces for configuring limits. This allows I/O limits to be imposed across all underlying storage types using a single interface. 2.) How disk I/O limits will be implemented QEMU block layer will introduce a per-drive disk I/O request queue for those disks whose disk I/O limits feature is enabled. It can control disk I/O limits individually for each disk when multiple disks are attached to a VM, and enable use cases like unlimited local disk access but shared storage access with limits. In mutliple I/O threads scenario, when an application in a VM issues a block I/O request, this request will be intercepted by QEMU block layer, then it will calculate disk runtime I/O rate and determine if it has go beyond its limits. If yes, this I/O request will enqueue to that introduced queue; otherwise it will be serviced. 3.) How the users enable and play with it QEMU -drive option will be extended so that disk I/O limits can be specified on its command line, such as -drive [iops=xxx,][throughput=xxx] or -drive [iops_rd=xxx,][iops_wr=xxx,][throughput=xxx] etc. When this argument is specified, it means that disk I/O limits feature is enabled for this drive disk. The feature will also provide users with the ability to change per-drive disk I/O limits at runtime using QMP commands. Regards, Zhiyong Wu
Re: [Qemu-devel] [Bug 788697] Re: [PowerPC] [patch] mtmsr does not preserve high bits of MSR
On 31.05.2011, at 15:35, Nathan Whitehorn wrote: On 05/26/11 18:47, agraf wrote: On 27.05.2011, at 01:33, Nathan Whitehorn wrote: On 05/26/11 11:45, agraf wrote: On 26.05.2011, at 18:09, Nathan Whitehorn wrote: ** Patch added: mtmstr.diff https://bugs.launchpad.net/bugs/788697/+attachment/2143748/+files/mtmstr.diff -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/788697 Title: [PowerPC] [patch] mtmsr does not preserve high bits of MSR Status in QEMU: New Bug description: The mtmsr instruction on 64-bit PPC does not preserve the high-order 32-bits of the MSR the way it is supposed to, instead setting them to 0, which takes 64-bit code out of 64-bit mode. There is some code that does the right thing, but it brokenly only preserves these bits when the thread is not in 64-bit mode (i.e. when it doesn't matter). The attached patch unconditionally enables this code when TARGET_PPC64 is set, per the ISA spec, which fixes early boot failures trying to start FreeBSD/powerpc64 under qemu. Please send the patch as proper patch to the ML and CC me. What isn't proper about the patch? I'm happy to re-email it, but don't want things to be in the wrong format. -Nathan The patch needs a patch description in its header and a subject line (all of which are present in the bug, so it's a simple matter of copypaste). Basically at the end of the day, I should be able to save the mail and git am on it and simply have it in my tree :). Also, does this get FreeBSD booting up to anything useful, so I can verify it helps? OK, I'll send this one out to today. The other issue I'm having (aside from our own bugs), is that SPR_PIR is not implemented for the POWER7 target. The architecture manual claims it is implemented on all Book-3S compliant CPUs, but it seems to be implemented sort of ad-hoc in target-ppc.c (e.g. the 604, 620, and 7400 have it, but not the 750, 970, or POWER7). So the reason POWER7 doesn't have it is probably because it simply does the same as 970. Why 970 doesn't register PIR, I don't know, but to me it sounds like a plain bug :). Just send a patch, CC me and David Gibson. Alex
Re: [Qemu-devel] [RFC]QEMU disk I/O limits
On 05/31/2011 08:45 AM, Vivek Goyal wrote: On Mon, May 30, 2011 at 01:09:23PM +0800, Zhi Yong Wu wrote: Hello, all, I have prepared to work on a feature called Disk I/O limits for qemu-kvm projeect. This feature will enable the user to cap disk I/O amount performed by a VM.It is important for some storage resources to be shared among multi-VMs. As you've known, if some of VMs are doing excessive disk I/O, they will hurt the performance of other VMs. Hi Zhiyong, Why not use kernel blkio controller for this and why reinvent the wheel and implement the feature again in qemu? blkio controller only works for block devices. It doesn't work when using files. Regards, Anthony Liguori
Re: [Qemu-devel] [RFC]QEMU disk I/O limits
On Tue, May 31, 2011 at 09:45:37AM -0400, Vivek Goyal wrote: On Mon, May 30, 2011 at 01:09:23PM +0800, Zhi Yong Wu wrote: Hello, all, I have prepared to work on a feature called Disk I/O limits for qemu-kvm projeect. This feature will enable the user to cap disk I/O amount performed by a VM.It is important for some storage resources to be shared among multi-VMs. As you've known, if some of VMs are doing excessive disk I/O, they will hurt the performance of other VMs. Hi Zhiyong, Why not use kernel blkio controller for this and why reinvent the wheel and implement the feature again in qemu? The finest level of granularity offered by cgroups apply limits per QEMU process. So the blkio controller can't be used to apply controls directly to individual disks used by QEMU, only the VM as a whole. We networking we can use 'net_cls' cgroups controller for the process as a whole, or attach 'tc' to individual TAP devices for per-NIC throttling, both of which ultimately use the same kernel functionality. I don't see an equivalent option for throttling individual disks that would reuse functionality from the blkio controller. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [RFC]QEMU disk I/O limits
On Tue, May 31, 2011 at 08:50:40AM -0500, Anthony Liguori wrote: On 05/31/2011 08:45 AM, Vivek Goyal wrote: On Mon, May 30, 2011 at 01:09:23PM +0800, Zhi Yong Wu wrote: Hello, all, I have prepared to work on a feature called Disk I/O limits for qemu-kvm projeect. This feature will enable the user to cap disk I/O amount performed by a VM.It is important for some storage resources to be shared among multi-VMs. As you've known, if some of VMs are doing excessive disk I/O, they will hurt the performance of other VMs. Hi Zhiyong, Why not use kernel blkio controller for this and why reinvent the wheel and implement the feature again in qemu? blkio controller only works for block devices. It doesn't work when using files. So can't we comeup with something to easily determine which device backs up this file? Though that will still not work for NFS backed storage though. Thanks Vivek
Re: [Qemu-devel] [PATCH] Use SIGIO with caution
On 2011-05-31 15:47, Anthony Liguori wrote: On 05/29/2011 04:50 PM, Andreas Färber wrote: BeOS and Haiku don't define SIGIO. When undefined, it won't arrive and doesn't need to be blocked. Signed-off-by: Andreas Färberandreas.faer...@web.de Anything to do with signal masks is never a trivial patch BTW... But I actually think explicit handling of SIGIO is unneeded. I think this is a hold over from the pre-I/O thread days where we selectively set SIGIO on certain file descriptors to make sure that when an IO fd became readable, we received a signal to break out of the KVM emulation loop. Can the folks on CC confirm/deny? I can't see any use of SIGIO in the current source tree. At least qemu-timer.c uses SIGIO in HPET mode. That only applies to Linux hosts, though. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [RFC]QEMU disk I/O limits
On Tue, May 31, 2011 at 02:56:46PM +0100, Daniel P. Berrange wrote: On Tue, May 31, 2011 at 09:45:37AM -0400, Vivek Goyal wrote: On Mon, May 30, 2011 at 01:09:23PM +0800, Zhi Yong Wu wrote: Hello, all, I have prepared to work on a feature called Disk I/O limits for qemu-kvm projeect. This feature will enable the user to cap disk I/O amount performed by a VM.It is important for some storage resources to be shared among multi-VMs. As you've known, if some of VMs are doing excessive disk I/O, they will hurt the performance of other VMs. Hi Zhiyong, Why not use kernel blkio controller for this and why reinvent the wheel and implement the feature again in qemu? The finest level of granularity offered by cgroups apply limits per QEMU process. So the blkio controller can't be used to apply controls directly to individual disks used by QEMU, only the VM as a whole. So are multiple VMs using same disk. Then put multiple VMs in same cgroup and apply the limit on that disk. Or if you want to put a system wide limit on a disk, then put all VMs in root cgroup and put limit on root cgroups. I fail to understand what's the exact requirement here. I thought the biggest use case was isolation one VM from other which might be sharing same device. Hence we were interested in putting per VM limit on disk and not a system wide limit on disk (independent of VM). Thanks Vivek
Re: [Qemu-devel] [PATCH] Use SIGIO with caution
On 05/31/2011 04:47 PM, Anthony Liguori wrote: On 05/29/2011 04:50 PM, Andreas Färber wrote: BeOS and Haiku don't define SIGIO. When undefined, it won't arrive and doesn't need to be blocked. Signed-off-by: Andreas Färberandreas.faer...@web.de Anything to do with signal masks is never a trivial patch BTW... But I actually think explicit handling of SIGIO is unneeded. I think this is a hold over from the pre-I/O thread days where we selectively set SIGIO on certain file descriptors to make sure that when an IO fd became readable, we received a signal to break out of the KVM emulation loop. Can the folks on CC confirm/deny? I can't see any use of SIGIO in the current source tree. We have O_ASYNC in enable_sigio_timer(). That's only used with HPET host timers, which should be very rare. To be on the safe side I think we should take in the patch, and drop SIGIO support completely only if we decide the hpet host timer is not worth supporting. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH 2/2] Add support for Zipit Z2 machine
Zipit Z2 is small PXA270 based handheld.
Signed-off-by: Vasily Khoruzhick anars...@gmail.com
---
Makefile.target |1 +
hw/z2.c | 302 +++
2 files changed, 303 insertions(+), 0 deletions(-)
create mode 100644 hw/z2.c
diff --git a/Makefile.target b/Makefile.target
index 602d50d..5750499 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -358,6 +358,7 @@ obj-arm-y += omap2.o omap_dss.o soc_dma.o omap_gptimer.o
omap_synctimer.o \
obj-arm-y += omap_sx1.o palm.o tsc210x.o
obj-arm-y += nseries.o blizzard.o onenand.o vga.o cbus.o tusb6010.o usb-musb.o
obj-arm-y += mst_fpga.o mainstone.o
+obj-arm-y += z2.o
obj-arm-y += musicpal.o bitbang_i2c.o marvell_88w8618_audio.o
obj-arm-y += framebuffer.o
obj-arm-y += syborg.o syborg_fb.o syborg_interrupt.o syborg_keyboard.o
diff --git a/hw/z2.c b/hw/z2.c
new file mode 100644
index 000..fc22d4a
--- /dev/null
+++ b/hw/z2.c
@@ -0,0 +1,302 @@
+/*
+ * PXA270-based Zipit Z2 device
+ *
+ * Copyright (c) 2011 by Vasily Khoruzhick anars...@gmail.com
+ *
+ * Code is based on mainstone platform.
+ *
+ * This code is licensed under the GNU GPL v2.
+ */
+
+#include hw.h
+#include pxa.h
+#include arm-misc.h
+#include devices.h
+#include i2c.h
+#include ssi.h
+#include boards.h
+#include sysemu.h
+#include flash.h
+#include blockdev.h
+#include console.h
+#include audio/audio.h
+
+static struct keymap map[0x100] = {
+[0 ... 0xff] = { -1, -1 },
+[0x3b] = {0,0}, /* Option = F1 */
+[0xc8] = {0,1}, /* Up */
+[0xd0] = {0,2}, /* Down */
+[0xcb] = {0,3}, /* Left */
+[0xcd] = {0,4}, /* Right */
+[0xcf] = {0,5}, /* End */
+[0x0d] = {0,6}, /* KPPLUS */
+[0xc7] = {1,0}, /* Home */
+[0x10] = {1,1}, /* Q */
+[0x17] = {1,2}, /* I */
+[0x22] = {1,3}, /* G */
+[0x2d] = {1,4}, /* X */
+[0x1c] = {1,5}, /* Enter */
+[0x0c] = {1,6}, /* KPMINUS */
+[0xc9] = {2,0}, /* PageUp */
+[0x11] = {2,1}, /* W */
+[0x18] = {2,2}, /* O */
+[0x23] = {2,3}, /* H */
+[0x2e] = {2,4}, /* C */
+[0x38] = {2,5}, /* LeftAlt */
+[0xd1] = {3,0}, /* PageDown */
+[0x12] = {3,1}, /* E */
+[0x19] = {3,2}, /* P */
+[0x24] = {3,3}, /* J */
+[0x2f] = {3,4}, /* V */
+[0x2a] = {3,5}, /* LeftShift */
+[0x01] = {4,0}, /* Esc */
+[0x13] = {4,1}, /* R */
+[0x1e] = {4,2}, /* A */
+[0x25] = {4,3}, /* K */
+[0x30] = {4,4}, /* B */
+[0x1d] = {4,5}, /* LeftCtrl */
+[0x0f] = {5,0}, /* Tab */
+[0x14] = {5,1}, /* T */
+[0x1f] = {5,2}, /* S */
+[0x26] = {5,3}, /* L */
+[0x31] = {5,4}, /* N */
+[0x39] = {5,5}, /* Space */
+[0x3c] = {6,0}, /* Stop = F2 */
+[0x15] = {6,1}, /* Y */
+[0x20] = {6,2}, /* D */
+[0x0e] = {6,3}, /* Backspace */
+[0x32] = {6,4}, /* M */
+[0x33] = {6,5}, /* Comma */
+[0x3d] = {7,0}, /* Play = F3 */
+[0x16] = {7,1}, /* U */
+[0x21] = {7,2}, /* F */
+[0x2c] = {7,3}, /* Z */
+[0x27] = {7,4}, /* Semicolon */
+[0x34] = {7,5}, /* Dot */
+};
+
+#define Z2_RAM_SIZE 0x0200
+#define Z2_FLASH_BASE 0x
+#define Z2_FLASH_SIZE 0x0080
+
+static struct arm_boot_info z2_binfo = {
+.loader_start = PXA2XX_SDRAM_BASE,
+.ram_size = Z2_RAM_SIZE,
+};
+
+#define Z2_GPIO_SD_DETECT 96
+#define Z2_GPIO_AC_IN 0
+#define Z2_GPIO_KEY_ON 1
+#define Z2_GPIO_LCD_CS 88
+
+typedef struct {
+SSISlave ssidev;
+int enabled;
+uint8_t buf[3];
+int pos;
+} ZipitLCD;
+
+static uint32_t zipit_lcd_transfer(SSISlave *dev, uint32_t value)
+{
+ZipitLCD *z = FROM_SSI_SLAVE(ZipitLCD, dev);
+if (z-enabled) {
+z-buf[z-pos] = value 0xff;
+z-pos++;
+}
+if (z-pos == 3) {
+switch (z-buf[0]) {
+case 0x74:
+printf(%s: reg: 0x%.2x\n, __func__, z-buf[2]);
+break;
+case 0x76:
+printf(%s: value: 0x%.4x\n, __func__, z-buf[1] 8 |
z-buf[2]);
+break;
+default:
+printf(%s: unknown command!\n, __func__);
+break;
+}
+z-pos = 0;
+}
+return 0;
+}
+
+static void z2_lcd_cs(void *opaque, int line, int level)
+{
+ZipitLCD *z2_lcd = opaque;
+z2_lcd-enabled = !level;
+}
+
+static int zipit_lcd_init(SSISlave *dev)
+{
+ZipitLCD *z = FROM_SSI_SLAVE(ZipitLCD, dev);
+z-enabled = 0;
+z-pos = 0;
+
+return 0;
+}
+
+static SSISlaveInfo zipit_lcd_info = {
+.qdev.name = zipit-lcd,
+.qdev.size = sizeof(ZipitLCD),
+.init = zipit_lcd_init,
+.transfer = zipit_lcd_transfer
+};
+
+typedef struct {
+i2c_slave i2c;
+int len;
+char buf[3];
+} AER915State;
+
+static int aer915_send(i2c_slave *i2c, uint8_t data)
+{
+AER915State *s = FROM_I2C_SLAVE(AER915State, i2c);
+s-buf[s-len] = data;
+if (s-len ++ 2) {
+printf(%s: message too long (%i bytes)\n, __FUNCTION__, s-len);
+return 1;
+}
+
+if
[Qemu-devel] [PATCH 1/2] pxa2xx_lcd: add proper rotation support
Until now, pxa2xx_lcd only supported 90deg rotation, but
some machines (for example Zipit Z2) needs 270deg rotation.
Signed-off-by: Vasily Khoruzhick anars...@gmail.com
---
hw/framebuffer.c |2 +
hw/pxa2xx_lcd.c | 80 -
input.c | 34 +--
qemu-options.hx |9 ++
vl.c | 10 ++-
5 files changed, 117 insertions(+), 18 deletions(-)
diff --git a/hw/framebuffer.c b/hw/framebuffer.c
index 24cdf25..486f7e4 100644
--- a/hw/framebuffer.c
+++ b/hw/framebuffer.c
@@ -78,6 +78,8 @@ void framebuffer_update_display(
dest = ds_get_data(ds);
if (dest_col_pitch 0)
dest -= dest_col_pitch * (cols - 1);
+if (dest_row_pitch 0)
+ dest -= dest_row_pitch * (rows - 1);
first = -1;
addr = pd;
diff --git a/hw/pxa2xx_lcd.c b/hw/pxa2xx_lcd.c
index e524802..a076778 100644
--- a/hw/pxa2xx_lcd.c
+++ b/hw/pxa2xx_lcd.c
@@ -665,7 +665,7 @@ static void pxa2xx_palette_parse(PXA2xxLCDState *s, int ch,
int bpp)
}
}
-static void pxa2xx_lcdc_dma0_redraw_horiz(PXA2xxLCDState *s,
+static void pxa2xx_lcdc_dma0_redraw_rot0(PXA2xxLCDState *s,
target_phys_addr_t addr, int *miny, int *maxy)
{
int src_width, dest_width;
@@ -692,7 +692,7 @@ static void pxa2xx_lcdc_dma0_redraw_horiz(PXA2xxLCDState *s,
fn, s-dma_ch[0].palette, miny, maxy);
}
-static void pxa2xx_lcdc_dma0_redraw_vert(PXA2xxLCDState *s,
+static void pxa2xx_lcdc_dma0_redraw_rot90(PXA2xxLCDState *s,
target_phys_addr_t addr, int *miny, int *maxy)
{
int src_width, dest_width;
@@ -720,6 +720,61 @@ static void pxa2xx_lcdc_dma0_redraw_vert(PXA2xxLCDState *s,
miny, maxy);
}
+static void pxa2xx_lcdc_dma0_redraw_rot180(PXA2xxLCDState *s,
+target_phys_addr_t addr, int *miny, int *maxy)
+{
+int src_width, dest_width;
+drawfn fn = NULL;
+if (s-dest_width)
+fn = s-line_fn[s-transp][s-bpp];
+if (!fn)
+return;
+
+src_width = (s-xres + 3) ~3; /* Pad to a 4 pixels multiple */
+if (s-bpp == pxa_lcdc_19pbpp || s-bpp == pxa_lcdc_18pbpp)
+src_width *= 3;
+else if (s-bpp pxa_lcdc_16bpp)
+src_width *= 4;
+else if (s-bpp pxa_lcdc_8bpp)
+src_width *= 2;
+
+dest_width = s-xres * s-dest_width;
+*miny = 0;
+framebuffer_update_display(s-ds,
+ addr, s-xres, s-yres,
+ src_width, -dest_width, -s-dest_width,
+ s-invalidated,
+ fn, s-dma_ch[0].palette, miny, maxy);
+}
+
+static void pxa2xx_lcdc_dma0_redraw_rot270(PXA2xxLCDState *s,
+ target_phys_addr_t addr, int *miny, int *maxy)
+{
+int src_width, dest_width;
+drawfn fn = NULL;
+if (s-dest_width)
+fn = s-line_fn[s-transp][s-bpp];
+if (!fn)
+return;
+
+src_width = (s-xres + 3) ~3; /* Pad to a 4 pixels multiple */
+if (s-bpp == pxa_lcdc_19pbpp || s-bpp == pxa_lcdc_18pbpp)
+src_width *= 3;
+else if (s-bpp pxa_lcdc_16bpp)
+src_width *= 4;
+else if (s-bpp pxa_lcdc_8bpp)
+src_width *= 2;
+
+dest_width = s-yres * s-dest_width;
+*miny = 0;
+framebuffer_update_display(s-ds,
+ addr, s-xres, s-yres,
+ src_width, -s-dest_width, dest_width,
+ s-invalidated,
+ fn, s-dma_ch[0].palette,
+ miny, maxy);
+}
+
static void pxa2xx_lcdc_resize(PXA2xxLCDState *s)
{
int width, height;
@@ -730,7 +785,7 @@ static void pxa2xx_lcdc_resize(PXA2xxLCDState *s)
height = LCCR2_LPP(s-control[2]) + 1;
if (width != s-xres || height != s-yres) {
-if (s-orientation)
+if (s-orientation == 90 || s-orientation == 270)
qemu_console_resize(s-ds, height, width);
else
qemu_console_resize(s-ds, width, height);
@@ -797,7 +852,7 @@ static void pxa2xx_update_display(void *opaque)
}
if (miny = 0) {
-if (s-orientation)
+if (s-orientation == 90 || s-orientation == 270)
dpy_update(s-ds, miny, 0, maxy - miny, s-xres);
else
dpy_update(s-ds, 0, miny, s-xres, maxy - miny);
@@ -822,10 +877,19 @@ static void pxa2xx_lcdc_orientation(void *opaque, int
angle)
{
PXA2xxLCDState *s = (PXA2xxLCDState *) opaque;
-if (angle) {
-s-dma_ch[0].redraw = pxa2xx_lcdc_dma0_redraw_vert;
-} else {
-s-dma_ch[0].redraw = pxa2xx_lcdc_dma0_redraw_horiz;
+switch (angle) {
+case 0:
+s-dma_ch[0].redraw = pxa2xx_lcdc_dma0_redraw_rot0;
+break;
+case 90:
+s-dma_ch[0].redraw = pxa2xx_lcdc_dma0_redraw_rot90;
+break;
+case 180:
+s-dma_ch[0].redraw =
Re: [Qemu-devel] [RFC]QEMU disk I/O limits
On Tue, May 31, 2011 at 10:10:37AM -0400, Vivek Goyal wrote: On Tue, May 31, 2011 at 02:56:46PM +0100, Daniel P. Berrange wrote: On Tue, May 31, 2011 at 09:45:37AM -0400, Vivek Goyal wrote: On Mon, May 30, 2011 at 01:09:23PM +0800, Zhi Yong Wu wrote: Hello, all, I have prepared to work on a feature called Disk I/O limits for qemu-kvm projeect. This feature will enable the user to cap disk I/O amount performed by a VM.It is important for some storage resources to be shared among multi-VMs. As you've known, if some of VMs are doing excessive disk I/O, they will hurt the performance of other VMs. Hi Zhiyong, Why not use kernel blkio controller for this and why reinvent the wheel and implement the feature again in qemu? The finest level of granularity offered by cgroups apply limits per QEMU process. So the blkio controller can't be used to apply controls directly to individual disks used by QEMU, only the VM as a whole. So are multiple VMs using same disk. Then put multiple VMs in same cgroup and apply the limit on that disk. Or if you want to put a system wide limit on a disk, then put all VMs in root cgroup and put limit on root cgroups. I fail to understand what's the exact requirement here. I thought the biggest use case was isolation one VM from other which might be sharing same device. Hence we were interested in putting per VM limit on disk and not a system wide limit on disk (independent of VM). No, it isn't about putting limits on a disk independant of a VM. It is about one VM having multiple disks, and wanting to set different policies for each of its virtual disks. eg qemu-kvm -drive file=/dev/sda1 -drive file=/dev/sdb3 and wanting to say that sda1 is limited to 10 MB/s, while sdb3 is limited to 50 MB/s. You can't do that kind of thing with cgroups, because it can only control the entire process, not individual resources within the process. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [RFC]QEMU disk I/O limits
On 05/31/2011 09:04 AM, Vivek Goyal wrote: On Tue, May 31, 2011 at 08:50:40AM -0500, Anthony Liguori wrote: On 05/31/2011 08:45 AM, Vivek Goyal wrote: On Mon, May 30, 2011 at 01:09:23PM +0800, Zhi Yong Wu wrote: Hello, all, I have prepared to work on a feature called Disk I/O limits for qemu-kvm projeect. This feature will enable the user to cap disk I/O amount performed by a VM.It is important for some storage resources to be shared among multi-VMs. As you've known, if some of VMs are doing excessive disk I/O, they will hurt the performance of other VMs. Hi Zhiyong, Why not use kernel blkio controller for this and why reinvent the wheel and implement the feature again in qemu? blkio controller only works for block devices. It doesn't work when using files. So can't we comeup with something to easily determine which device backs up this file? Though that will still not work for NFS backed storage though. Right. Additionally, in QEMU, we can rate limit based on concepts that make sense to a guest. We can limit the actual I/O ops visible to the guest which means that we'll get consistent performance regardless of whether the backing file is qcow2, raw, LVM, or raw over NFS. The kernel just doesn't have enough information to do a good job here. Regards, Anthony Liguori Thanks Vivek
Re: [Qemu-devel] [PATCH] Use SIGIO with caution
On 05/31/2011 09:06 AM, Jan Kiszka wrote: On 2011-05-31 15:47, Anthony Liguori wrote: On 05/29/2011 04:50 PM, Andreas Färber wrote: BeOS and Haiku don't define SIGIO. When undefined, it won't arrive and doesn't need to be blocked. Signed-off-by: Andreas Färberandreas.faer...@web.de Anything to do with signal masks is never a trivial patch BTW... But I actually think explicit handling of SIGIO is unneeded. I think this is a hold over from the pre-I/O thread days where we selectively set SIGIO on certain file descriptors to make sure that when an IO fd became readable, we received a signal to break out of the KVM emulation loop. Can the folks on CC confirm/deny? I can't see any use of SIGIO in the current source tree. At least qemu-timer.c uses SIGIO in HPET mode. That only applies to Linux hosts, though. Is there any reason we still carry multiple timer implementations these days? HPET shouldn't be any better than dynticks. Regards, Anthony Liguori Jan
Re: [Qemu-devel] [RFC]QEMU disk I/O limits
On Tue, May 31, 2011 at 03:19:56PM +0100, Daniel P. Berrange wrote: On Tue, May 31, 2011 at 10:10:37AM -0400, Vivek Goyal wrote: On Tue, May 31, 2011 at 02:56:46PM +0100, Daniel P. Berrange wrote: On Tue, May 31, 2011 at 09:45:37AM -0400, Vivek Goyal wrote: On Mon, May 30, 2011 at 01:09:23PM +0800, Zhi Yong Wu wrote: Hello, all, I have prepared to work on a feature called Disk I/O limits for qemu-kvm projeect. This feature will enable the user to cap disk I/O amount performed by a VM.It is important for some storage resources to be shared among multi-VMs. As you've known, if some of VMs are doing excessive disk I/O, they will hurt the performance of other VMs. Hi Zhiyong, Why not use kernel blkio controller for this and why reinvent the wheel and implement the feature again in qemu? The finest level of granularity offered by cgroups apply limits per QEMU process. So the blkio controller can't be used to apply controls directly to individual disks used by QEMU, only the VM as a whole. So are multiple VMs using same disk. Then put multiple VMs in same cgroup and apply the limit on that disk. Or if you want to put a system wide limit on a disk, then put all VMs in root cgroup and put limit on root cgroups. I fail to understand what's the exact requirement here. I thought the biggest use case was isolation one VM from other which might be sharing same device. Hence we were interested in putting per VM limit on disk and not a system wide limit on disk (independent of VM). No, it isn't about putting limits on a disk independant of a VM. It is about one VM having multiple disks, and wanting to set different policies for each of its virtual disks. eg qemu-kvm -drive file=/dev/sda1 -drive file=/dev/sdb3 and wanting to say that sda1 is limited to 10 MB/s, while sdb3 is limited to 50 MB/s. You can't do that kind of thing with cgroups, because it can only control the entire process, not individual resources within the process. With IO controller you can do that. Limits are per cgroup per disk. So once you have put a VM in a cgroup, you can specify two differnt limits for two disk for that cgroup. There are 4 relevant files per cgroup. blkio.throttle.read_bps_device blkio.throttle.write_bps_device blkio.throttle.read_iops_device blkio.throttle.write_iops_device And syntax of these files is. device_major:device_minor rate_limit Ex. 8:161024000 This means from a specified cgroup, on disk with major:minor 8:16, don't allow read BW higher than 1024000 bytes per second. Thanks Vivek
Re: [Qemu-devel] [PATCH] Use SIGIO with caution
On 2011-05-31 16:26, Anthony Liguori wrote: On 05/31/2011 09:06 AM, Jan Kiszka wrote: On 2011-05-31 15:47, Anthony Liguori wrote: On 05/29/2011 04:50 PM, Andreas Färber wrote: BeOS and Haiku don't define SIGIO. When undefined, it won't arrive and doesn't need to be blocked. Signed-off-by: Andreas Färberandreas.faer...@web.de Anything to do with signal masks is never a trivial patch BTW... But I actually think explicit handling of SIGIO is unneeded. I think this is a hold over from the pre-I/O thread days where we selectively set SIGIO on certain file descriptors to make sure that when an IO fd became readable, we received a signal to break out of the KVM emulation loop. Can the folks on CC confirm/deny? I can't see any use of SIGIO in the current source tree. At least qemu-timer.c uses SIGIO in HPET mode. That only applies to Linux hosts, though. Is there any reason we still carry multiple timer implementations these days? HPET shouldn't be any better than dynticks. On any recent kernel, for sure. BTW, the same applies to the RTC timer. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
[Qemu-devel] [PATCH] s390x: implement lrvgr
The LRVGR instruction was missing. Implement it, so everyone's happy. Reported-by: Balazs Kutil bku...@novell.com Signed-off-by: Alexander Graf ag...@suse.de --- target-s390x/translate.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/target-s390x/translate.c b/target-s390x/translate.c index afeb5e6..eda4624 100644 --- a/target-s390x/translate.c +++ b/target-s390x/translate.c @@ -3473,6 +3473,9 @@ static void disas_b9(DisasContext *s, int op, int r1, int r2) tcg_temp_free_i64(tmp2); tcg_temp_free_i64(tmp3); break; +case 0x0f: /* LRVGRR1,R2 [RRE] */ +tcg_gen_bswap64_i64(regs[r1], regs[r2]); +break; case 0x1f: /* LRVR R1,R2 [RRE] */ tmp32_1 = load_reg32(r2); tcg_gen_bswap32_i32(tmp32_1, tmp32_1); -- 1.6.0.2
Re: [Qemu-devel] [RFC]QEMU disk I/O limits
* Daniel P. Berrange berra...@redhat.com [2011-05-31 09:25]: On Tue, May 31, 2011 at 10:10:37AM -0400, Vivek Goyal wrote: On Tue, May 31, 2011 at 02:56:46PM +0100, Daniel P. Berrange wrote: On Tue, May 31, 2011 at 09:45:37AM -0400, Vivek Goyal wrote: On Mon, May 30, 2011 at 01:09:23PM +0800, Zhi Yong Wu wrote: Hello, all, I have prepared to work on a feature called Disk I/O limits for qemu-kvm projeect. This feature will enable the user to cap disk I/O amount performed by a VM.It is important for some storage resources to be shared among multi-VMs. As you've known, if some of VMs are doing excessive disk I/O, they will hurt the performance of other VMs. Hi Zhiyong, Why not use kernel blkio controller for this and why reinvent the wheel and implement the feature again in qemu? The finest level of granularity offered by cgroups apply limits per QEMU process. So the blkio controller can't be used to apply controls directly to individual disks used by QEMU, only the VM as a whole. So are multiple VMs using same disk. Then put multiple VMs in same cgroup and apply the limit on that disk. Or if you want to put a system wide limit on a disk, then put all VMs in root cgroup and put limit on root cgroups. I fail to understand what's the exact requirement here. I thought the biggest use case was isolation one VM from other which might be sharing same device. Hence we were interested in putting per VM limit on disk and not a system wide limit on disk (independent of VM). No, it isn't about putting limits on a disk independant of a VM. It is about one VM having multiple disks, and wanting to set different policies for each of its virtual disks. eg qemu-kvm -drive file=/dev/sda1 -drive file=/dev/sdb3 and wanting to say that sda1 is limited to 10 MB/s, while sdb3 is limited to 50 MB/s. You can't do that kind of thing with cgroups, because it can only control the entire process, not individual resources within the process. yes, but with files: qemu-kvm -drive file=/path/to/local/vm/images -drive file=/path/to/shared/storage -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ry...@us.ibm.com
[Qemu-devel] [PULL] Few VirtFS patches.
The following changes since commit b1d7d2b93a1d6b2d2848b616cc35acdf521c923c: Anthony Liguori (1): Merge remote-tracking branch 'stefanha/trivial-patches' into staging are available in the git repository at: git://repo.or.cz/qemu/aliguori/jvrao.git for-anthony Aneesh Kumar K.V (3): virtio-9p: Don't link to 9p if virtio is not enabled virtio-9p: Move 9p device registration into virtio-9p.c virtio-9p: Move device specific code to virtio-9p-device Malahal Naineni (1): [virtio-9p] Stop renaming files with similar name! Stefan Weil (1): virtio-9p: Use relative includes for files in hw Venkateswararao Jujjuri (JV) (1): [virtio-9p] Make rpath thread safe Makefile.objs |9 +- Makefile.target|4 +- fsdev/file-op-9p.h |7 -- fsdev/qemu-fsdev-dummy.c | 20 + hw/9pfs/virtio-9p-debug.c |5 +- hw/9pfs/virtio-9p-device.c | 173 hw/9pfs/virtio-9p-local.c | 138 +++- hw/9pfs/virtio-9p-posix-acl.c | 22 -- hw/9pfs/virtio-9p-xattr-user.c | 11 ++- hw/9pfs/virtio-9p-xattr.c |7 +- hw/9pfs/virtio-9p-xattr.h |9 ++- hw/9pfs/virtio-9p.c| 147 ++ hw/9pfs/virtio-9p.h|7 ++ hw/virtio-pci.c| 57 +- hw/virtio-pci.h| 43 ++ 15 files changed, 376 insertions(+), 283 deletions(-) create mode 100644 fsdev/qemu-fsdev-dummy.c create mode 100644 hw/9pfs/virtio-9p-device.c create mode 100644 hw/virtio-pci.h
Re: [Qemu-devel] [PATCH] Use SIGIO with caution
On 31.05.2011, at 16:54, Jan Kiszka wrote: On 2011-05-31 16:26, Anthony Liguori wrote: On 05/31/2011 09:06 AM, Jan Kiszka wrote: On 2011-05-31 15:47, Anthony Liguori wrote: On 05/29/2011 04:50 PM, Andreas Färber wrote: BeOS and Haiku don't define SIGIO. When undefined, it won't arrive and doesn't need to be blocked. Signed-off-by: Andreas Färberandreas.faer...@web.de Anything to do with signal masks is never a trivial patch BTW... But I actually think explicit handling of SIGIO is unneeded. I think this is a hold over from the pre-I/O thread days where we selectively set SIGIO on certain file descriptors to make sure that when an IO fd became readable, we received a signal to break out of the KVM emulation loop. Can the folks on CC confirm/deny? I can't see any use of SIGIO in the current source tree. At least qemu-timer.c uses SIGIO in HPET mode. That only applies to Linux hosts, though. Is there any reason we still carry multiple timer implementations these days? HPET shouldn't be any better than dynticks. On any recent kernel, for sure. BTW, the same applies to the RTC timer. So the obvious change would be to introduce CONFIG_HPET, ifdef the SIGIO handling on that and also ifdef the host hpet handling code on it? That way it's documented well and can preferably even be turned off with --disable-host-hpet during configure time, which we can then slowly turn to the default. Alex
Re: [Qemu-devel] [PATCH] Use SIGIO with caution
On 05/31/2011 10:44 AM, Alexander Graf wrote: On 31.05.2011, at 16:54, Jan Kiszka wrote: On 2011-05-31 16:26, Anthony Liguori wrote: On 05/31/2011 09:06 AM, Jan Kiszka wrote: On 2011-05-31 15:47, Anthony Liguori wrote: On 05/29/2011 04:50 PM, Andreas Färber wrote: BeOS and Haiku don't define SIGIO. When undefined, it won't arrive and doesn't need to be blocked. Signed-off-by: Andreas Färberandreas.faer...@web.de Anything to do with signal masks is never a trivial patch BTW... But I actually think explicit handling of SIGIO is unneeded. I think this is a hold over from the pre-I/O thread days where we selectively set SIGIO on certain file descriptors to make sure that when an IO fd became readable, we received a signal to break out of the KVM emulation loop. Can the folks on CC confirm/deny? I can't see any use of SIGIO in the current source tree. At least qemu-timer.c uses SIGIO in HPET mode. That only applies to Linux hosts, though. Is there any reason we still carry multiple timer implementations these days? HPET shouldn't be any better than dynticks. On any recent kernel, for sure. BTW, the same applies to the RTC timer. So the obvious change would be to introduce CONFIG_HPET, ifdef the SIGIO handling on that and also ifdef the host hpet handling code on it? That way it's documented well and can preferably even be turned off with --disable-host-hpet during configure time, which we can then slowly turn to the default. Or just remove hpet and rtc. Does anyone really object to that? Regards, Anthony Liguori Alex
[Qemu-devel] [PATCH] ppc: provide PIR register on all book-S CPUs
The PIR register is architecturally specified on all PowerPC
non-embedded CPUs, but currently is only available on the 604, 620, and
G4. Add it to all 601-derived CPUs.
target-ppc/translate_init.c | 20 +---
1 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index b511afa..1286ddf 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -670,6 +670,11 @@ static void gen_spr_ne_601 (CPUPPCState *env)
SPR_NOACCESS, SPR_NOACCESS,
spr_read_generic, spr_write_sdr1,
0x);
+/* Processor identification */
+spr_register(env, SPR_PIR, PIR,
+ SPR_NOACCESS, SPR_NOACCESS,
+ spr_read_generic, spr_write_pir,
+ env-cpu_index);
}
/* BATs 0-3 */
@@ -1019,11 +1024,6 @@ static void gen_spr_thrm (CPUPPCState *env)
/* SPR specific to PowerPC 604 implementation */
static void gen_spr_604 (CPUPPCState *env)
{
-/* Processor identification */
-spr_register(env, SPR_PIR, PIR,
- SPR_NOACCESS, SPR_NOACCESS,
- spr_read_generic, spr_write_pir,
- 0x);
/* Breakpoints */
/* XXX : not implemented */
spr_register(env, SPR_IABR, IABR,
@@ -1259,11 +1259,6 @@ static void gen_spr_601 (CPUPPCState *env)
static void gen_spr_74xx (CPUPPCState *env)
{
-/* Processor identification */
-spr_register(env, SPR_PIR, PIR,
- SPR_NOACCESS, SPR_NOACCESS,
- spr_read_generic, spr_write_pir,
- 0x);
/* XXX : not implemented */
spr_register(env, SPR_MMCR2, MMCR2,
SPR_NOACCESS, SPR_NOACCESS,
@@ -2118,11 +2113,6 @@ static void gen_spr_compress (CPUPPCState *env)
/* SPR specific to PowerPC 620 */
static void gen_spr_620 (CPUPPCState *env)
{
-/* Processor identification */
-spr_register(env, SPR_PIR, PIR,
- SPR_NOACCESS, SPR_NOACCESS,
- spr_read_generic, spr_write_pir,
- 0x);
spr_register(env, SPR_ASR, ASR,
SPR_NOACCESS, SPR_NOACCESS,
spr_read_asr, spr_write_asr,
[Qemu-devel] [PATCH] timer: drop HPET and RTC
dynticks will provide equally good timer granularity on all modern Linux
systems. This is more or less dead code these days.
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
diff --git a/qemu-timer.c b/qemu-timer.c
index 4141b6e..72066c7 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -39,15 +39,6 @@
#include sys/param.h
#endif
-#ifdef __linux__
-#include sys/ioctl.h
-#include linux/rtc.h
-/* For the benefit of older linux systems which don't supply it,
- we use a local copy of hpet.h. */
-/* #include linux/hpet.h */
-#include hpet.h
-#endif
-
#ifdef _WIN32
#include windows.h
#include mmsystem.h
@@ -234,12 +225,6 @@ static int dynticks_start_timer(struct qemu_alarm_timer
*t);
static void dynticks_stop_timer(struct qemu_alarm_timer *t);
static void dynticks_rearm_timer(struct qemu_alarm_timer *t);
-static int hpet_start_timer(struct qemu_alarm_timer *t);
-static void hpet_stop_timer(struct qemu_alarm_timer *t);
-
-static int rtc_start_timer(struct qemu_alarm_timer *t);
-static void rtc_stop_timer(struct qemu_alarm_timer *t);
-
#endif /* __linux__ */
#endif /* _WIN32 */
@@ -304,10 +289,6 @@ static struct qemu_alarm_timer alarm_timers[] = {
#ifdef __linux__
{dynticks, dynticks_start_timer,
dynticks_stop_timer, dynticks_rearm_timer},
-/* HPET - if available - is preferred */
-{hpet, hpet_start_timer, hpet_stop_timer, NULL},
-/* ...otherwise try RTC */
-{rtc, rtc_start_timer, rtc_stop_timer, NULL},
#endif
{unix, unix_start_timer, unix_stop_timer, NULL},
#else
@@ -822,107 +803,6 @@ static int64_t qemu_next_alarm_deadline(void)
#if defined(__linux__)
-#define RTC_FREQ 1024
-
-static void enable_sigio_timer(int fd)
-{
-struct sigaction act;
-
-/* timer signal */
-sigfillset(act.sa_mask);
-act.sa_flags = 0;
-act.sa_handler = host_alarm_handler;
-
-sigaction(SIGIO, act, NULL);
-fcntl_setfl(fd, O_ASYNC);
-fcntl(fd, F_SETOWN, getpid());
-}
-
-static int hpet_start_timer(struct qemu_alarm_timer *t)
-{
-struct hpet_info info;
-int r, fd;
-
-fd = qemu_open(/dev/hpet, O_RDONLY);
-if (fd 0)
-return -1;
-
-/* Set frequency */
-r = ioctl(fd, HPET_IRQFREQ, RTC_FREQ);
-if (r 0) {
-fprintf(stderr, Could not configure '/dev/hpet' to have a 1024Hz
timer. This is not a fatal\n
-error, but for better emulation accuracy type:\n
-'echo 1024 /proc/sys/dev/hpet/max-user-freq' as root.\n);
-goto fail;
-}
-
-/* Check capabilities */
-r = ioctl(fd, HPET_INFO, info);
-if (r 0)
-goto fail;
-
-/* Enable periodic mode */
-r = ioctl(fd, HPET_EPI, 0);
-if (info.hi_flags (r 0))
-goto fail;
-
-/* Enable interrupt */
-r = ioctl(fd, HPET_IE_ON, 0);
-if (r 0)
-goto fail;
-
-enable_sigio_timer(fd);
-t-fd = fd;
-
-return 0;
-fail:
-close(fd);
-return -1;
-}
-
-static void hpet_stop_timer(struct qemu_alarm_timer *t)
-{
-int fd = t-fd;
-
-close(fd);
-}
-
-static int rtc_start_timer(struct qemu_alarm_timer *t)
-{
-int rtc_fd;
-unsigned long current_rtc_freq = 0;
-
-TFR(rtc_fd = qemu_open(/dev/rtc, O_RDONLY));
-if (rtc_fd 0)
-return -1;
-ioctl(rtc_fd, RTC_IRQP_READ, current_rtc_freq);
-if (current_rtc_freq != RTC_FREQ
-ioctl(rtc_fd, RTC_IRQP_SET, RTC_FREQ) 0) {
-fprintf(stderr, Could not configure '/dev/rtc' to have a 1024 Hz
timer. This is not a fatal\n
-error, but for better emulation accuracy either use a 2.6
host Linux kernel or\n
-type 'echo 1024 /proc/sys/dev/rtc/max-user-freq' as
root.\n);
-goto fail;
-}
-if (ioctl(rtc_fd, RTC_PIE_ON, 0) 0) {
-fail:
-close(rtc_fd);
-return -1;
-}
-
-enable_sigio_timer(rtc_fd);
-
-t-fd = rtc_fd;
-
-return 0;
-}
-
-static void rtc_stop_timer(struct qemu_alarm_timer *t)
-{
-int rtc_fd = t-fd;
-
-close(rtc_fd);
-}
-
static int dynticks_start_timer(struct qemu_alarm_timer *t)
{
struct sigevent ev;
--
1.7.4.1
Re: [Qemu-devel] [OpenBIOS] solaris 8 on sparc, webstart launcher crashing
Yeah - at this point the kernel should have taken over completely and so I expect that you're hitting an emulation bug (probably the Solaris compiler emits certain instruction sequences not used by gcc which is why this has only just come to light). Alright. I'll do what I can. Thanks for the response (both of you). In order for someone to fix this, you'll need to supply the information requested by Blue above. Also which version of QEMU are you running? 0.14.1 -Brian
[Qemu-devel] [PATCH] Fix build on FreeBSD
Add some includes required to build qemu on FreeBSD.
---
bsd-user/syscall.c |2 ++
iohandler.c|1 +
os-posix.c |4
3 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/bsd-user/syscall.c b/bsd-user/syscall.c
index eb1cdf2..7b49f54 100644
--- a/bsd-user/syscall.c
+++ b/bsd-user/syscall.c
@@ -212,9 +212,11 @@ static int sysctl_oldcvt(void *holdp, size_t
holdlen, uint3
2_t kind)
*(uint64_t *)holdp = tswap64(*(unsigned long *)holdp);
break;
#endif
+#ifdef CTLTYPE_QUAD
case CTLTYPE_QUAD:
*(uint64_t *)holdp = tswap64(*(uint64_t *)holdp);
break;
+#endif
case CTLTYPE_STRING:
break;
default:
diff --git a/iohandler.c b/iohandler.c
index 2b82421..7266aca 100644
--- a/iohandler.c
+++ b/iohandler.c
@@ -29,6 +29,7 @@
#ifndef _WIN32
#include sys/wait.h
+#include signal.h
#endif
typedef struct IOHandlerRecord {
diff --git a/os-posix.c b/os-posix.c
index 3204197..13b7229 100644
--- a/os-posix.c
+++ b/os-posix.c
@@ -44,6 +44,10 @@
#include sys/syscall.h
#endif
+#ifdef CONFIG_BSD
+#include sys/sysctl.h
+#endif
+
#ifdef CONFIG_EVENTFD
#include sys/eventfd.h
#endif
[Qemu-devel] QEMU for ppc440 on i386 host
Hi! My name is Tai. Sorry for bother you! I have a question about QEMU for powerpc. Can QEMU emulate the ppc440 on a i386 host? I mean it is full-system emulation. Because when I'm trying to run linux ppc440 with qemu on my i386 PC I alway get the error like that: $ qemu-system-ppc -M bamboo -kernel vmlinux qemu: fatal: Trying to execute code outside RAM or ROM at 0xc000 NIP c000 LR CTR XER MSR HID0 0300 HF idx 0 Segmentation fault $ qemu-system-ppc -M bamboo -kernel arch/powerpc/boot/uImage Trying to read privileged spr 947 3b3 at 1014 Trying to read invalid spr 62 03e at 0778 I using QEMU that configured and built with device tree support (enable libfdt). QEMU version 0.14.1 The kernel image is built for bamboo using powerpc-440 toolchain. kernel-version 2.6.38.2 Thank you very much!
[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] [PATCH] smc91c111: qdevify reset
From: Juha Riihimäki juha.riihim...@nokia.com
Register the smc91c111 reset function as a qdev reset function.
Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
---
hw/smc91c111.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/hw/smc91c111.c b/hw/smc91c111.c
index dafea5c..701baaf 100644
--- a/hw/smc91c111.c
+++ b/hw/smc91c111.c
@@ -252,8 +252,9 @@ static void smc91c111_queue_tx(smc91c111_state *s, int
packet)
smc91c111_do_tx(s);
}
-static void smc91c111_reset(smc91c111_state *s)
+static void smc91c111_reset(DeviceState *dev)
{
+smc91c111_state *s = FROM_SYSBUS(smc91c111_state, sysbus_from_qdev(dev));
s-bank = 0;
s-tx_fifo_len = 0;
s-tx_fifo_done_len = 0;
@@ -302,7 +303,7 @@ static void smc91c111_writeb(void *opaque,
target_phys_addr_t offset,
case 5:
SET_HIGH(rcr, value);
if (s-rcr RCR_SOFT_RST)
-smc91c111_reset(s);
+smc91c111_reset(s-busdev.qdev);
return;
case 10: case 11: /* RPCR */
/* Ignored */
@@ -753,9 +754,6 @@ static int smc91c111_init1(SysBusDevice *dev)
sysbus_init_mmio(dev, 16, s-mmio_index);
sysbus_init_irq(dev, s-irq);
qemu_macaddr_default_if_unset(s-conf.macaddr);
-
-smc91c111_reset(s);
-
s-nic = qemu_new_nic(net_smc91c111_info, s-conf,
dev-qdev.info-name, dev-qdev.id, s);
qemu_format_nic_info_str(s-nic-nc, s-conf.macaddr.a);
@@ -768,6 +766,7 @@ static SysBusDeviceInfo smc91c111_info = {
.qdev.name = smc91c111,
.qdev.size = sizeof(smc91c111_state),
.qdev.vmsd = vmstate_smc91c111,
+.qdev.reset = smc91c111_reset,
.qdev.props = (Property[]) {
DEFINE_NIC_PROPERTIES(smc91c111_state, conf),
DEFINE_PROP_END_OF_LIST(),
--
1.7.1
[Qemu-devel] [PATCH] audio: fix integer overflow expression
From: Juha Riihimäki juha.riihim...@nokia.com Fix an integer overflow that can happen for signed 32 bit types when using FLOAT_MIXENG. (Note that at the moment this is only true when using the MacOSX coreaudio audio driver.) Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com Reviewed-by: Peter Maydell peter.mayd...@linaro.org --- I'm trying to get random patches out of my patch-stack and upstream. This one looks obviously correct but it only kicks in for MacOSX and coreaudio, and I don't have access to that platform to test myself, so treat my reviewed-by accordingly. This has actually been posted here before, last year: http://patchwork.ozlabs.org/patch/48703/ audio/mixeng_template.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/audio/mixeng_template.h b/audio/mixeng_template.h index a2d0ef8..e01da0a 100644 --- a/audio/mixeng_template.h +++ b/audio/mixeng_template.h @@ -46,7 +46,7 @@ static mixeng_real inline glue (conv_, ET) (IN_T v) #endif #else /* !RECIPROCAL */ #ifdef SIGNED -return nv / (mixeng_real) (IN_MAX - IN_MIN); +return nv / (mixeng_real) ((mixeng_real)IN_MAX - (mixeng_real)IN_MIN); #else return (nv - HALF) / (mixeng_real) IN_MAX; #endif @@ -63,7 +63,7 @@ static IN_T inline glue (clip_, ET) (mixeng_real v) } #ifdef SIGNED -return ENDIAN_CONVERT ((IN_T) (v * (IN_MAX - IN_MIN))); +return ENDIAN_CONVERT ((IN_T) (v * ((mixeng_real)IN_MAX - (mixeng_real)IN_MIN))); #else return ENDIAN_CONVERT ((IN_T) ((v * IN_MAX) + HALF)); #endif -- 1.7.1
Re: [Qemu-devel] [RFC]QEMU disk I/O limits
On Tue, May 31, 2011 at 09:25:31AM -0500, Anthony Liguori wrote: On 05/31/2011 09:04 AM, Vivek Goyal wrote: On Tue, May 31, 2011 at 08:50:40AM -0500, Anthony Liguori wrote: On 05/31/2011 08:45 AM, Vivek Goyal wrote: On Mon, May 30, 2011 at 01:09:23PM +0800, Zhi Yong Wu wrote: Hello, all, I have prepared to work on a feature called Disk I/O limits for qemu-kvm projeect. This feature will enable the user to cap disk I/O amount performed by a VM.It is important for some storage resources to be shared among multi-VMs. As you've known, if some of VMs are doing excessive disk I/O, they will hurt the performance of other VMs. Hi Zhiyong, Why not use kernel blkio controller for this and why reinvent the wheel and implement the feature again in qemu? blkio controller only works for block devices. It doesn't work when using files. So can't we comeup with something to easily determine which device backs up this file? Though that will still not work for NFS backed storage though. Right. Additionally, in QEMU, we can rate limit based on concepts that make sense to a guest. We can limit the actual I/O ops visible to the guest which means that we'll get consistent performance regardless of whether the backing file is qcow2, raw, LVM, or raw over NFS. Are you referring to merging taking place which can change the definition of IOPS as seen by guest? We do throttling at bio level and no merging is taking place. So IOPS seen by guest and as seen by throttling logic should be same. Readahead would be one exception though where any readahead data will be charged to guest. Device throttling and interaction with file system is still an issue with IO controller (things like journalling lead to serialization) where a faster group can get blocked behind slower group. That's why at the moment, it is recommened that directly export devices/partitions to virtual machines if throttling is to be used and don't share a file system across VMs. The kernel just doesn't have enough information to do a good job here. [CCing couple of device mapper folks for thoughts on below] When I think more about it, I think this problem is very similar to other features like snapshotting. Whether we should implement snapshotting in qemu or use some kernel based solution like dm-snaphot or dm-multisnap etc. I don't have a good answer for that. Has this detabe been settled already? I see that development is happening in kernel or providing dm snapshot capabilities and Mike Snitzer also mentioned about possibility of using dm-loop for covering the case of files over NFS etc. Some thoughts in general though. - Any kernel based solution is generic and can be used in other contexts also like containers or bare metal. - In some cases, kernel can implement throttling more efficiently. For example if a block devie has multiple partitions and these partitions are exported to VMs, then kernel can maintain a single queue and single set of timer to manage all the VMs doing IO to that device. In user space solution we shall have manage as many queues and timers as there are VMs. So kernel implementation can enable more efficient implementation in certain cases. - Things like dm-loop essentially means introduce another block layer on top of file system layer. I personally think that it does not sound very clean and might slow down things. Though I don't have any data. Has there been any discussion/conclusion on this? - qemu based scheme will work well with all kind of targets. For using kenrel based scheme one shall have to switch to using kernel provided snapshotting schemes (dm-snapshot or dm multisnap etc). Otherwise a READ might come from a base image which is on other device and we did not throttle the VM. Thanks Vivek
Re: [Qemu-devel] [PATCH] ppc: provide PIR register on all book-S CPUs
On 31.05.2011, at 16:52, Nathan Whitehorn wrote:
The PIR register is architecturally specified on all PowerPC non-embedded
CPUs, but currently is only available on the 604, 620, and G4. Add it to all
601-derived CPUs.
Please add a signed-off-by line. Also, please CC me on all PPC related patches
(see MAINTAINERS file) and in this particular case, please also CC David (CC'ed
in this reply mail).
David, do you think this patch is correct? If so, could you please ack it?
Alex
target-ppc/translate_init.c | 20 +---
1 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index b511afa..1286ddf 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -670,6 +670,11 @@ static void gen_spr_ne_601 (CPUPPCState *env)
SPR_NOACCESS, SPR_NOACCESS,
spr_read_generic, spr_write_sdr1,
0x);
+/* Processor identification */
+spr_register(env, SPR_PIR, PIR,
+ SPR_NOACCESS, SPR_NOACCESS,
+ spr_read_generic, spr_write_pir,
+ env-cpu_index);
}
/* BATs 0-3 */
@@ -1019,11 +1024,6 @@ static void gen_spr_thrm (CPUPPCState *env)
/* SPR specific to PowerPC 604 implementation */
static void gen_spr_604 (CPUPPCState *env)
{
-/* Processor identification */
-spr_register(env, SPR_PIR, PIR,
- SPR_NOACCESS, SPR_NOACCESS,
- spr_read_generic, spr_write_pir,
- 0x);
/* Breakpoints */
/* XXX : not implemented */
spr_register(env, SPR_IABR, IABR,
@@ -1259,11 +1259,6 @@ static void gen_spr_601 (CPUPPCState *env)
static void gen_spr_74xx (CPUPPCState *env)
{
-/* Processor identification */
-spr_register(env, SPR_PIR, PIR,
- SPR_NOACCESS, SPR_NOACCESS,
- spr_read_generic, spr_write_pir,
- 0x);
/* XXX : not implemented */
spr_register(env, SPR_MMCR2, MMCR2,
SPR_NOACCESS, SPR_NOACCESS,
@@ -2118,11 +2113,6 @@ static void gen_spr_compress (CPUPPCState *env)
/* SPR specific to PowerPC 620 */
static void gen_spr_620 (CPUPPCState *env)
{
-/* Processor identification */
-spr_register(env, SPR_PIR, PIR,
- SPR_NOACCESS, SPR_NOACCESS,
- spr_read_generic, spr_write_pir,
- 0x);
spr_register(env, SPR_ASR, ASR,
SPR_NOACCESS, SPR_NOACCESS,
spr_read_asr, spr_write_asr,
Re: [Qemu-devel] QEMU for ppc440 on i386 host
On 31.05.2011, at 18:05, Lê Đức Tài wrote: Hi! My name is Tai. Sorry for bother you! I have a question about QEMU for powerpc. Can QEMU emulate the ppc440 on a i386 host? I mean it is full-system emulation. Because when I'm trying to run linux ppc440 with qemu on my i386 PC I alway get the error like that: $ qemu-system-ppc -M bamboo -kernel vmlinux qemu: fatal: Trying to execute code outside RAM or ROM at 0xc000 NIP c000 LR CTR XER MSR HID0 0300 HF idx 0 Segmentation fault $ qemu-system-ppc -M bamboo -kernel arch/powerpc/boot/uImage Trying to read privileged spr 947 3b3 at 1014 Trying to read invalid spr 62 03e at 0778 I using QEMU that configured and built with device tree support (enable libfdt). QEMU version 0.14.1 The kernel image is built for bamboo using powerpc-440 toolchain. kernel-version 2.6.38.2 PPC440 emulation support has only been added to Qemu very recently (0.14). So far, the only board that is somewhat known to work is the virtex5 ml507 one with a 440x5 xilinx cpu. Please see http://wiki.qemu.org/ChangeLog/0.14#PPC for details. The bamboo board was added to enable KVM support for 440, it hasn't been used with the emulation target yet. What exactly are you trying to emulate? Alex
Re: [Qemu-devel] [PATCH] audio: fix integer overflow expression
This definitely had malc on the cc list when I sent it; as far as I can tell the mailing list server ate that cc... -- PMM On 31 May 2011 18:28, Peter Maydell peter.mayd...@linaro.org wrote: From: Juha Riihimäki juha.riihim...@nokia.com Fix an integer overflow that can happen for signed 32 bit types when using FLOAT_MIXENG. (Note that at the moment this is only true when using the MacOSX coreaudio audio driver.) Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com Reviewed-by: Peter Maydell peter.mayd...@linaro.org --- I'm trying to get random patches out of my patch-stack and upstream. This one looks obviously correct but it only kicks in for MacOSX and coreaudio, and I don't have access to that platform to test myself, so treat my reviewed-by accordingly. This has actually been posted here before, last year: http://patchwork.ozlabs.org/patch/48703/ audio/mixeng_template.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/audio/mixeng_template.h b/audio/mixeng_template.h index a2d0ef8..e01da0a 100644 --- a/audio/mixeng_template.h +++ b/audio/mixeng_template.h @@ -46,7 +46,7 @@ static mixeng_real inline glue (conv_, ET) (IN_T v) #endif #else /* !RECIPROCAL */ #ifdef SIGNED - return nv / (mixeng_real) (IN_MAX - IN_MIN); + return nv / (mixeng_real) ((mixeng_real)IN_MAX - (mixeng_real)IN_MIN); #else return (nv - HALF) / (mixeng_real) IN_MAX; #endif @@ -63,7 +63,7 @@ static IN_T inline glue (clip_, ET) (mixeng_real v) } #ifdef SIGNED - return ENDIAN_CONVERT ((IN_T) (v * (IN_MAX - IN_MIN))); + return ENDIAN_CONVERT ((IN_T) (v * ((mixeng_real)IN_MAX - (mixeng_real)IN_MIN))); #else return ENDIAN_CONVERT ((IN_T) ((v * IN_MAX) + HALF)); #endif -- 1.7.1
Re: [Qemu-devel] [PATCH] ppc64: fix mtmsr behavior on 64-bit targets
On 31.05.2011, at 16:56, Nathan Whitehorn wrote:
The mtmsr instruction is required not to modify the upper 32-bits of the
machine state register, but checks the current value of MSR[SF] to decide
whether to do this. This has the effect of zeroing the upper 32 bits of the
MSR whenever mtmsr is executed in 64-bit mode. Unconditionally preserve the
upper 32-bits in mtmsr for TARGET_PPC64.
This patch is missing a Signed-off-by line. Without, I unfortunately can't take
the code upstream yet. See http://wiki.qemu.org/Contribute/SubmitAPatch for
details.
---
target-ppc/translate.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index 9b3f90c..a60dbe9 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -3886,7 +3886,6 @@ static void gen_mtmsr(DisasContext *ctx)
*/
gen_update_nip(ctx, ctx-nip);
#if defined(TARGET_PPC64)
-if (!ctx-sf_mode) {
TCGv t0 = tcg_temp_new();
This code needs reindenting.
TCGv t1 = tcg_temp_new();
tcg_gen_andi_tl(t0, cpu_msr, 0xULL);
@@ -3895,9 +3894,9 @@ static void gen_mtmsr(DisasContext *ctx)
tcg_temp_free(t1);
gen_helper_store_msr(t0);
tcg_temp_free(t0);
-} else
-#endif
+#else
gen_helper_store_msr(cpu_gpr[rS(ctx-opcode)]);
This does too
Functionality-wise it looks good to me.
Alex
