Re: [Qemu-devel] Lack of codes in logging
On Tue, May 29, 2012 at 12:25:51AM -0400, Yue Chen wrote: Do you know how to use that? When I use log(-d) exec and log(-d) pcall, the qemu.log is always empty. `qemu -d in_asm,exec` will do. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] Lack of codes in logging
On Tue, May 29, 2012 at 8:25 AM, Yue Chen ycyc...@gmail.com wrote: Do you know how to use that? When I use log(-d) exec and log(-d) pcall, the qemu.log is always empty. AFAIK exec only prints execution trace in the debug build of QEMU. -- Thanks. -- Max
Re: [Qemu-devel] nested page table translation for non-x86 operating system
Hi Xin Tong, On Fri, Jan 20, 2012 at 08:54:12AM -0500, Xin Tong wrote: On Fri, Jan 20, 2012 at 3:23 AM, 陳韋任 che...@iis.sinica.edu.tw wrote: 1. The control of gCR3 and hCR3 needs kernel access. While they can be set with a device module as what is done in kvm. Trapping into the kernel every time gCR3 is reseted might be too expensive. Why the control of gCR3 needs kernel access? Isn't gCR3 just a field of the CPUX86State? QEMU should have the control of it. Or you mean the trapping thing? I do not think gCR3 is a field in the CPUx86State. I think inorder to change the guest CR3, we need to trap into the kernel as kvm does. I read stuff about Intel NPT again. Is gCR3 a field of VMCS, then loaded into CR3 at runtime? Thanks! Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [PATCH for-1.1] Makefile: Fix QOM dependencies
Hi, # Include automatically generated dependency files --include $(wildcard *.d audio/*.d slirp/*.d block/*.d net/*.d ui/*.d qapi/*.d qga/*.d) +-include $(wildcard *.d audio/*.d slirp/*.d block/*.d net/*.d ui/*.d qapi/*.d qga/*.d qom/*.d) I wonder if, independently of QOM, we also need to consider... - qapi-generated/*.d, - usb/*.d and - tests/*.d? Maybe we should just stop spreading the dep files over all directories? RfC patch attached. cheers, Gerd From 7b830d2394b17d8480d0d6dca8de940d591a4a3a Mon Sep 17 00:00:00 2001 From: Gerd Hoffmann kra...@redhat.com Date: Tue, 29 May 2012 09:03:30 +0200 Subject: [PATCH] dep fixup Signed-off-by: Gerd Hoffmann kra...@redhat.com --- Makefile | 10 +- rules.mak |2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Makefile b/Makefile index 9b7a85e..e872a8a 100644 --- a/Makefile +++ b/Makefile @@ -214,12 +214,12 @@ clean: # avoid old build problems by removing potentially incorrect old files rm -f config.mak op-i386.h opc-i386.h gen-op-i386.h op-arm.h opc-arm.h gen-op-arm.h rm -f qemu-options.def - rm -f *.o *.d *.a *.lo $(TOOLS) $(HELPERS-y) qemu-ga TAGS cscope.* *.pod *~ */*~ + rm -f *.o .*.d *.a *.lo $(TOOLS) $(HELPERS-y) qemu-ga TAGS cscope.* *.pod *~ */*~ rm -Rf .libs - rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d net/*.o net/*.d fsdev/*.o fsdev/*.d ui/*.o ui/*.d qapi/*.o qapi/*.d qga/*.o qga/*.d - rm -f qom/*.o qom/*.d + rm -f slirp/*.o audio/*.o block/*.o net/*.o fsdev/*.o ui/*.o qapi/*.o qga/*.o + rm -f qom/*.o rm -f qemu-img-cmds.h - rm -f trace/*.o trace/*.d + rm -f trace/*.o rm -f trace-dtrace.dtrace trace-dtrace.dtrace-timestamp @# May not be present in GENERATED_HEADERS rm -f trace-dtrace.h trace-dtrace.h-timestamp @@ -400,4 +400,4 @@ tar: rm -rf /tmp/$(FILE) # Include automatically generated dependency files --include $(wildcard *.d audio/*.d slirp/*.d block/*.d net/*.d ui/*.d qapi/*.d qga/*.d) +-include $(wildcard .*.d) diff --git a/rules.mak b/rules.mak index efef6f2..9937855 100644 --- a/rules.mak +++ b/rules.mak @@ -12,7 +12,7 @@ MAKEFLAGS += -rR %.mak: # Flags for dependency generation -QEMU_DGFLAGS += -MMD -MP -MT $@ -MF $(*D)/$(*F).d +QEMU_DGFLAGS += -MMD -MP -MT $@ -MF .$(subst /,-,$*).d %.o: %.c $(call quiet-command,$(CC) $(QEMU_INCLUDES) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) -c -o $@ $, CC$(TARGET_DIR)$@) -- 1.7.1
Re: [Qemu-devel] [PATCH v2] hmp/qxl: info spice: add qxl info
Hi,
How would that work? I have QXLInfo that only makes sense when the
information is about a qxl device. Can't have opaque data in a QMP
response, so would this be a info display qxl info display cirrus
etc. or info qxl?
You could show what's available and/or being used currently.
I think (Alon, correct me if I'm wrong) the use case is being able to
figure whenever the guest drivers are installed and active.
There isn't much point in doing that for stdvga and cirrus IMHO. It
might be useful for other paravirtual devices where we have to install
drivers (in windows guests, also older linux). I'm not sure it is
possible given that ipxe and seabios support booting from
virtio-{blk,net,scsi}, so you'll see the device being used even if the
guest os lacks drivers ...
cheers,
Gerd
[Qemu-devel] [PULL] slirp: Various build fixes
The following changes since commit 24f50d7ea5896a30b0e78f68884586bb8b40ff97: tcg/ppc: Handle _CALL_DARWIN being undefined on Darwin (2012-05-27 21:52:56 +0400) are available in the git repository at: git://git.kiszka.org/qemu.git queues/slirp Andreas Färber (3): slirp: Untangle TCPOLEN_* from TCPOPT_* slirp: Avoid statements without effect on Big Endian host slirp: Avoid redefining MAX_TCPOPTLEN slirp/ip.h | 20 slirp/tcp.h| 13 - slirp/tcp_output.c |1 + 3 files changed, 17 insertions(+), 17 deletions(-)
Re: [Qemu-devel] [PATCH for-1.1] Makefile: Fix QOM dependencies
Il 29/05/2012 09:05, Gerd Hoffmann ha scritto: I wonder if, independently of QOM, we also need to consider... - qapi-generated/*.d, - usb/*.d and - tests/*.d? Maybe we should just stop spreading the dep files over all directories? RfC patch attached. This could in principle break, like hw/usb/core.o vs. hw/usb-core.o. It would be a very bad choice of names, but it is possible in principle. Another choice: we could just subst .o with .d in the *-obj-y variables. Paolo
Re: [Qemu-devel] [PATCH v2] hmp/qxl: info spice: add qxl info
On Tue, May 29, 2012 at 09:25:40AM +0200, Gerd Hoffmann wrote:
Hi,
How would that work? I have QXLInfo that only makes sense when the
information is about a qxl device. Can't have opaque data in a QMP
response, so would this be a info display qxl info display cirrus
etc. or info qxl?
You could show what's available and/or being used currently.
I think (Alon, correct me if I'm wrong) the use case is being able to
figure whenever the guest drivers are installed and active.
There isn't much point in doing that for stdvga and cirrus IMHO. It
might be useful for other paravirtual devices where we have to install
drivers (in windows guests, also older linux). I'm not sure it is
possible given that ipxe and seabios support booting from
virtio-{blk,net,scsi}, so you'll see the device being used even if the
guest os lacks drivers ...
I haven't really generalized it, but you make much sense, more then info
display - so maybe I could put this under info paravirt, have a list
and a register function, with qxl the only registered callback for the
info command. This doesn't answer my other technical (and probably
having an obvious solution I'm missing) question about the type to use -
I could have a:
{ 'type': 'QXLInfo',
'data': {'id': 'int', 'guest_bug': 'int', 'mode': 'SpiceQueryQXLMode'}
}
(like I do now)
And then aggregate that via lists with possibly zero members:
{ 'type': 'ParaVirtInfo',
'data': {'qxl': ['QXLInfo'], 'virtserial': [VirtSerialInfo]} }
Luiz, is there a better solution?
cheers,
Gerd
Re: [Qemu-devel] [PATCH v3 00/16] net: hub-based networking
Luiz Capitulino lcapitul...@redhat.com writes: On Mon, 28 May 2012 12:17:04 +0100 Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote: What we need to decide is whether it's okay to drop QEMU VLANs completely and change dump command-line syntax? I'd vote for dropping it. I think vlan-hub doesn't hurt anyone because the code has been isolated and we keep backwards compatibility. So I'd personally still go the vlan-hub route for QEMU 1.x. Just to make it clear: I'm not against this series. I'm against having the functionality in qemu. If we want to keep the functionality, then I completely agree that this series is the way to go. I agree with Luiz: if we want to reimplement that much of networking within QEMU, this series does it in a much better way than VLANs, but I'd rather not do it at all. Just advice, not a strong objection. [...]
Re: [Qemu-devel] Keysymbol interpretation missing in QEMU's VNC server?
Hello Erik, I'm experiencing the same issues. When using the QEMU VNC server (which I would prefer to Remote Desktop or a VNC server installed on the guest) I get problems when pressing special character keys on the remote keyboard. QEMU reports on the console: Warning: no scancode found for keysym 180 or Warning: no scancode found for keysym 223 I just want to route all keypresses to the guest without interfering with the native QEMU key layout. Is that possible? Yes, if you start kvm without the -k option and use a linux VNC client that supports RFB extended key events (eg gtk-vnc, tigervnc). With the extension the keyboard layout only depends on the OS settings in the VM. How does the QEMU VNC server receive the key presses? In the same manner as the direct way does by getting scancodes or via real characters? http://berrange.com/posts/2010/07/04/more-than-you-or-i-ever-wanted-to-know-about-virtual-keyboard-handling/ http://berrange.com/posts/2010/07/04/a-summary-of-scan-code-key-codes-sets-used-in-the-pc-virtualization-stack/ regards Fabian
[Qemu-devel] qemu xhci mini howto (was: Re: [ANNOUNCE] qemu-kvm-1.1-rc3)
On 05/28/12 11:30, Avi Kivity wrote: On 05/25/2012 11:36 AM, Veruca Salt wrote: Avi- would love to test out 1.1, as we are currently using the ehci method which has been frozen at 'experimental' for so long. Is there any user documentation on the xhci methods? Copying qemu-devel, where someone may know the answer. There are no docs. But xhci can handle all devices by itself, no need to do all this companion controller stuff you have to do with ehci for usb 1.1 compatibility. Thus it's pretty simple actually: (1) You add the xhci host adapter: qemu $args -device nec-usb-xhci,id=xhci (2) You add usb devices devices as usual: qemu $args -device usb-tablet,bus=xhci.0 (3) There is no third step ;) Advantages of xhci: * higher performance, less cpu overhead (thanks to the virtualization/emulation friendly hardware design). Known issues (for qemu 1.1, list hopefully becomes shorter for 1.2): * Got less testing than ehci. * No usb-hub support yet (i.e. you are limited to the 4 root ports, but as the qemu-emulated usb hub supports usb 1.1 only you probably want avoid it anyway ...). * No usb 3.0 ports yet. * No isochronous transfer support yet. * No seabios support yet (i.e. you can't boot from xhci-connected usbsticks). cheers, Gerd
Re: [Qemu-devel] KVM call agenda for Tuesday, May 29th
On 05/28/2012 06:20 PM, Juan Quintela wrote: Hi Please send in any agenda items you are interested in covering. I'm in China for the next two weeks and this time is now pretty inconvenient. Unless there's anything that requires urgent discussion on the phone, I'd prefer to just handle things over the mailing list if no one objects. Regards, Anthony Liguori Thanks, Juan. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PULL 1.1 0/2] SCSI patches for 1.1.0-rc3
On 05/28/2012 01:46 AM, Paolo Bonzini wrote: Il 26/05/2012 11:18, ronnie sahlberg ha scritto: I have compiled your branch and run through some tests. It all looks good as long as you apply the patch to #include hw/scsi-defs.h Thanks, I updated the scsi-next branch. So should I expect a new branch for this pull? Regards, Anthony Liguori Paolo
[Qemu-devel] [PULL 0/6] updated SCSI changes for 1.1.0-rc4
The following changes since commit aeb29b6459cb9496b38c820f3faff64cf2369d0d: audio: Always call fini on exit (2012-05-24 19:35:27 +0400) are available in the git repository at: git://github.com/bonzini/qemu.git scsi-next for you to fetch changes up to f4dfa67f04037c1b1a8f4e4ddc944c5ab308f35b: ISCSI: Switch to using READ16/WRITE16 for I/O to the LUN (2012-05-28 14:04:16 +0200) The only difference from v1 is in the libiscsi patches. Jim Meyering (1): scsi: declare vmstate_info_scsi_requests to be static Paolo Bonzini (1): ISCSI: change num_blocks to 64-bit Ronnie Sahlberg (4): ISCSI: redo how we set up the events ISCSI: get device type at connection time ISCSI: Only call READCAPACITY16 for SBC devices, use READCAPACITY10 for MMC ISCSI: Switch to using READ16/WRITE16 for I/O to the LUN block/iscsi.c | 240 - hw/scsi-bus.c |2 +- trace-events |4 +- 3 files changed, 206 insertions(+), 40 deletions(-) -- 1.7.10.1
[Qemu-devel] [PATCH 1/6] scsi: declare vmstate_info_scsi_requests to be static
From: Jim Meyering meyer...@redhat.com
Signed-off-by: Jim Meyering meyer...@redhat.com
---
hw/scsi-bus.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
index 8ab9bcd..f10f3ec 100644
--- a/hw/scsi-bus.c
+++ b/hw/scsi-bus.c
@@ -1561,7 +1561,7 @@ static int get_scsi_requests(QEMUFile *f, void *pv,
size_t size)
return 0;
}
-const VMStateInfo vmstate_info_scsi_requests = {
+static const VMStateInfo vmstate_info_scsi_requests = {
.name = scsi-requests,
.get = get_scsi_requests,
.put = put_scsi_requests,
--
1.7.10.1
[Qemu-devel] [PATCH 2/6] ISCSI: redo how we set up the events
From: Ronnie Sahlberg ronniesahlb...@gmail.com
Call qemu_notify_event() after updating events. Otherwise, If we add
an event for -is-writeable but the socket is already writeable there
may be a delay before the event callback is actually triggered.
Those delays would in particular hurt performance during BIOS boot and
when the GRUB bootloader reads the kernel and initrd.
But first call out to the socket write functions directly, and only set up
the write event if the socket is full. This will happen very rarely and
this improves performance.
Signed-off-by: Ronnie Sahlberg ronniesahlb...@gmail.com
---
block/iscsi.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index d37c4ee..db41bb7 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -39,6 +39,7 @@ typedef struct IscsiLun {
int lun;
int block_size;
unsigned long num_blocks;
+int events;
} IscsiLun;
typedef struct IscsiAIOCB {
@@ -104,11 +105,27 @@ static void
iscsi_set_events(IscsiLun *iscsilun)
{
struct iscsi_context *iscsi = iscsilun-iscsi;
+int ev;
-qemu_aio_set_fd_handler(iscsi_get_fd(iscsi), iscsi_process_read,
- (iscsi_which_events(iscsi) POLLOUT)
- ? iscsi_process_write : NULL,
- iscsi_process_flush, iscsilun);
+/* We always register a read handler. */
+ev = POLLIN;
+ev |= iscsi_which_events(iscsi);
+if (ev != iscsilun-events) {
+qemu_aio_set_fd_handler(iscsi_get_fd(iscsi),
+ iscsi_process_read,
+ (ev POLLOUT) ? iscsi_process_write : NULL,
+ iscsi_process_flush,
+ iscsilun);
+
+}
+
+/* If we just added an event, the callback might be delayed
+ * unless we call qemu_notify_event().
+ */
+if (ev ~iscsilun-events) {
+qemu_notify_event();
+}
+iscsilun-events = ev;
}
static void
--
1.7.10.1
Re: [Qemu-devel] [PULL 1.1 0/2] SCSI patches for 1.1.0-rc3
Il 29/05/2012 11:15, Anthony Liguori ha scritto: It all looks good as long as you apply the patch to #include hw/scsi-defs.h Thanks, I updated the scsi-next branch. So should I expect a new branch for this pull? No, same branch, one more patch. I just sent the pull request again. Paolo
Re: [Qemu-devel] [PATCH for-1.1] Makefile: Fix QOM dependencies
Am 29.05.2012 09:44, schrieb Paolo Bonzini: Il 29/05/2012 09:05, Gerd Hoffmann ha scritto: I wonder if, independently of QOM, we also need to consider... - qapi-generated/*.d, - usb/*.d and - tests/*.d? Maybe we should just stop spreading the dep files over all directories? RfC patch attached. This could in principle break, like hw/usb/core.o vs. hw/usb-core.o. It would be a very bad choice of names, but it is possible in principle. I concur, it's quite risky for the final RC. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH for-1.1] Makefile: Fix QOM dependencies
Am 29.05.2012 09:05, schrieb Gerd Hoffmann: - rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d net/*.o net/*.d fsdev/*.o fsdev/*.d ui/*.o ui/*.d qapi/*.o qapi/*.d qga/*.o qga/*.d - rm -f qom/*.o qom/*.d + rm -f slirp/*.o audio/*.o block/*.o net/*.o fsdev/*.o ui/*.o qapi/*.o qga/*.o + rm -f qom/*.o I think this is calling for a centrally maintained (or automatically derived) list of build directories. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH 4/6] ISCSI: get device type at connection time
From: Ronnie Sahlberg ronniesahlb...@gmail.com
This is needed to avoid READ CAPACITY(16) for MMC devices.
Signed-off-by: Ronnie Sahlberg ronniesahlb...@gmail.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
block/iscsi.c | 45 +++--
1 file changed, 43 insertions(+), 2 deletions(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index 9cd258f..91cca83 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -29,6 +29,7 @@
#include qemu-error.h
#include block_int.h
#include trace.h
+#include hw/scsi-defs.h
#include iscsi/iscsi.h
#include iscsi/scsi-lowlevel.h
@@ -37,6 +38,7 @@
typedef struct IscsiLun {
struct iscsi_context *iscsi;
int lun;
+enum scsi_inquiry_peripheral_device_type type;
int block_size;
uint64_t num_blocks;
int events;
@@ -508,18 +510,33 @@ iscsi_readcapacity16_cb(struct iscsi_context *iscsi, int
status,
}
static void
-iscsi_connect_cb(struct iscsi_context *iscsi, int status, void *command_data,
+iscsi_inquiry_cb(struct iscsi_context *iscsi, int status, void *command_data,
void *opaque)
{
struct IscsiTask *itask = opaque;
-struct scsi_task *task;
+struct scsi_task *task = command_data;
+struct scsi_inquiry_standard *inq;
if (status != 0) {
itask-status = 1;
itask-complete = 1;
+scsi_free_scsi_task(task);
return;
}
+inq = scsi_datain_unmarshall(task);
+if (inq == NULL) {
+error_report(iSCSI: Failed to unmarshall inquiry data.);
+itask-status = 1;
+itask-complete = 1;
+scsi_free_scsi_task(task);
+return;
+}
+
+itask-iscsilun-type = inq-periperal_device_type;
+
+scsi_free_scsi_task(task);
+
task = iscsi_readcapacity16_task(iscsi, itask-iscsilun-lun,
iscsi_readcapacity16_cb, opaque);
if (task == NULL) {
@@ -530,6 +547,30 @@ iscsi_connect_cb(struct iscsi_context *iscsi, int status,
void *command_data,
}
}
+static void
+iscsi_connect_cb(struct iscsi_context *iscsi, int status, void *command_data,
+ void *opaque)
+{
+struct IscsiTask *itask = opaque;
+struct scsi_task *task;
+
+if (status != 0) {
+itask-status = 1;
+itask-complete = 1;
+return;
+}
+
+task = iscsi_inquiry_task(iscsi, itask-iscsilun-lun,
+ 0, 0, 36,
+ iscsi_inquiry_cb, opaque);
+if (task == NULL) {
+error_report(iSCSI: failed to send inquiry command.);
+itask-status = 1;
+itask-complete = 1;
+return;
+}
+}
+
static int parse_chap(struct iscsi_context *iscsi, const char *target)
{
QemuOptsList *list;
--
1.7.10.1
[Qemu-devel] [PATCH 3/6] ISCSI: change num_blocks to 64-bit
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
block/iscsi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index db41bb7..9cd258f 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -38,7 +38,7 @@ typedef struct IscsiLun {
struct iscsi_context *iscsi;
int lun;
int block_size;
-unsigned long num_blocks;
+uint64_t num_blocks;
int events;
} IscsiLun;
--
1.7.10.1
Re: [Qemu-devel] [PATCH for-1.1] Makefile: Fix QOM dependencies
Il 29/05/2012 11:28, Andreas Färber ha scritto: Am 29.05.2012 09:05, schrieb Gerd Hoffmann: -rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d net/*.o net/*.d fsdev/*.o fsdev/*.d ui/*.o ui/*.d qapi/*.o qapi/*.d qga/*.o qga/*.d -rm -f qom/*.o qom/*.d +rm -f slirp/*.o audio/*.o block/*.o net/*.o fsdev/*.o ui/*.o qapi/*.o qga/*.o +rm -f qom/*.o I think this is calling for a centrally maintained (or automatically derived) list of build directories. Quite difficult with the abuse of vpath that we currently have... but we can still proceed incrementally. Paolo
Re: [Qemu-devel] [PATCH for-1.1] Makefile: Fix QOM dependencies
Am 29.05.2012 11:43, schrieb Paolo Bonzini: Il 29/05/2012 11:28, Andreas Färber ha scritto: Am 29.05.2012 09:05, schrieb Gerd Hoffmann: - rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d net/*.o net/*.d fsdev/*.o fsdev/*.d ui/*.o ui/*.d qapi/*.o qapi/*.d qga/*.o qga/*.d - rm -f qom/*.o qom/*.d + rm -f slirp/*.o audio/*.o block/*.o net/*.o fsdev/*.o ui/*.o qapi/*.o qga/*.o + rm -f qom/*.o I think this is calling for a centrally maintained (or automatically derived) list of build directories. Quite difficult with the abuse of vpath that we currently have... but we can still proceed incrementally. For 1.1 I was thinking of something like BUILDSUBDIRS=slirp audio block net fsdev ui qapi qga qom for dir in $(BUILDSUBDIRS); do \ rm -rf $dir/*.o $dir/*.d; \ done which possibly could also be reused for the list of *.d includes with some clever macro usage. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH for-1.1] Makefile: Fix QOM dependencies
On 05/29/2012 04:47 AM, Andreas Färber wrote: Am 29.05.2012 11:43, schrieb Paolo Bonzini: Il 29/05/2012 11:28, Andreas Färber ha scritto: Am 29.05.2012 09:05, schrieb Gerd Hoffmann: - rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d net/*.o net/*.d fsdev/*.o fsdev/*.d ui/*.o ui/*.d qapi/*.o qapi/*.d qga/*.o qga/*.d - rm -f qom/*.o qom/*.d + rm -f slirp/*.o audio/*.o block/*.o net/*.o fsdev/*.o ui/*.o qapi/*.o qga/*.o + rm -f qom/*.o I think this is calling for a centrally maintained (or automatically derived) list of build directories. Quite difficult with the abuse of vpath that we currently have... but we can still proceed incrementally. For 1.1 I was thinking of something like BUILDSUBDIRS=slirp audio block net fsdev ui qapi qga qom for dir in $(BUILDSUBDIRS); do \ rm -rf $dir/*.o $dir/*.d; \ done which possibly could also be reused for the list of *.d includes with some clever macro usage. I'd prefer not to make this change in 1.1.0 as this doesn't seem to be a release blocker to me. I'd rather do something more significant in 1.2 and backport to a 1.1.1 release. Regards, Anthony Liguori Andreas
[Qemu-devel] [PATCH 6/6] ISCSI: Switch to using READ16/WRITE16 for I/O to the LUN
From: Ronnie Sahlberg ronniesahlb...@gmail.com
This allows using LUNs bigger than 2TB. Keep using READ10 for other
device types such as MMC.
Signed-off-by: Ronnie Sahlberg ronniesahlb...@gmail.com
---
block/iscsi.c | 112 ++---
trace-events |4 +--
2 files changed, 85 insertions(+), 31 deletions(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index 472c853..22888a0 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -25,6 +25,7 @@
#include config-host.h
#include poll.h
+#include arpa/inet.h
#include qemu-common.h
#include qemu-error.h
#include block_int.h
@@ -180,12 +181,12 @@ iscsi_readv_writev_bh_cb(void *p)
static void
-iscsi_aio_write10_cb(struct iscsi_context *iscsi, int status,
+iscsi_aio_write16_cb(struct iscsi_context *iscsi, int status,
void *command_data, void *opaque)
{
IscsiAIOCB *acb = opaque;
-trace_iscsi_aio_write10_cb(iscsi, status, acb, acb-canceled);
+trace_iscsi_aio_write16_cb(iscsi, status, acb, acb-canceled);
g_free(acb-buf);
@@ -198,7 +199,7 @@ iscsi_aio_write10_cb(struct iscsi_context *iscsi, int
status,
acb-status = 0;
if (status 0) {
-error_report(Failed to write10 data to iSCSI lun. %s,
+error_report(Failed to write16 data to iSCSI lun. %s,
iscsi_get_error(iscsi));
acb-status = -EIO;
}
@@ -223,12 +224,9 @@ iscsi_aio_writev(BlockDriverState *bs, int64_t sector_num,
struct iscsi_context *iscsi = iscsilun-iscsi;
IscsiAIOCB *acb;
size_t size;
-int fua = 0;
-
-/* set FUA on writes when cache mode is write through */
-if (!(bs-open_flags BDRV_O_CACHE_WB)) {
-fua = 1;
-}
+uint32_t num_sectors;
+uint64_t lba;
+struct iscsi_data data;
acb = qemu_aio_get(iscsi_aio_pool, bs, cb, opaque);
trace_iscsi_aio_writev(iscsi, sector_num, nb_sectors, opaque, acb);
@@ -238,18 +236,44 @@ iscsi_aio_writev(BlockDriverState *bs, int64_t sector_num,
acb-canceled = 0;
-/* XXX we should pass the iovec to write10 to avoid the extra copy */
+/* XXX we should pass the iovec to write16 to avoid the extra copy */
/* this will allow us to get rid of 'buf' completely */
size = nb_sectors * BDRV_SECTOR_SIZE;
acb-buf = g_malloc(size);
qemu_iovec_to_buffer(acb-qiov, acb-buf);
-acb-task = iscsi_write10_task(iscsi, iscsilun-lun, acb-buf, size,
- sector_qemu2lun(sector_num, iscsilun),
- fua, 0, iscsilun-block_size,
- iscsi_aio_write10_cb, acb);
+
+
+acb-task = malloc(sizeof(struct scsi_task));
if (acb-task == NULL) {
-error_report(iSCSI: Failed to send write10 command. %s,
- iscsi_get_error(iscsi));
+error_report(iSCSI: Failed to allocate task for scsi WRITE16
+ command. %s, iscsi_get_error(iscsi));
+qemu_aio_release(acb);
+return NULL;
+}
+memset(acb-task, 0, sizeof(struct scsi_task));
+
+acb-task-xfer_dir = SCSI_XFER_WRITE;
+acb-task-cdb_size = 16;
+acb-task-cdb[0] = 0x8a;
+if (!(bs-open_flags BDRV_O_CACHE_WB)) {
+/* set FUA on writes when cache mode is write through */
+acb-task-cdb[1] |= 0x04;
+}
+lba = sector_qemu2lun(sector_num, iscsilun);
+*(uint32_t *)acb-task-cdb[2] = htonl(lba 32);
+*(uint32_t *)acb-task-cdb[6] = htonl(lba 0x);
+num_sectors = size / iscsilun-block_size;
+*(uint32_t *)acb-task-cdb[10] = htonl(num_sectors);
+acb-task-expxferlen = size;
+
+data.data = acb-buf;
+data.size = size;
+
+if (iscsi_scsi_command_async(iscsi, iscsilun-lun, acb-task,
+ iscsi_aio_write16_cb,
+ data,
+ acb) != 0) {
+scsi_free_scsi_task(acb-task);
g_free(acb-buf);
qemu_aio_release(acb);
return NULL;
@@ -261,12 +285,12 @@ iscsi_aio_writev(BlockDriverState *bs, int64_t sector_num,
}
static void
-iscsi_aio_read10_cb(struct iscsi_context *iscsi, int status,
+iscsi_aio_read16_cb(struct iscsi_context *iscsi, int status,
void *command_data, void *opaque)
{
IscsiAIOCB *acb = opaque;
-trace_iscsi_aio_read10_cb(iscsi, status, acb, acb-canceled);
+trace_iscsi_aio_read16_cb(iscsi, status, acb, acb-canceled);
if (acb-canceled != 0) {
qemu_aio_release(acb);
@@ -277,7 +301,7 @@ iscsi_aio_read10_cb(struct iscsi_context *iscsi, int status,
acb-status = 0;
if (status != 0) {
-error_report(Failed to read10 data from iSCSI lun. %s,
+error_report(Failed to read16 data from iSCSI lun. %s,
iscsi_get_error(iscsi));
acb-status = -EIO;
}
@@ -296,8 +320,10 @@ iscsi_aio_readv(BlockDriverState *bs, int64_t sector_num,
IscsiLun *iscsilun = bs-opaque;
struct
[Qemu-devel] [PATCH 1/2] arch_init: Fix AltiVec build on Darwin/ppc
Commit f29a56147b66845914d0a645bf9b4c5bb9a6af57 (implement -no-user-config command-line option (v3)) introduced uses of bool in arch_init.c. Shortly before that usage is support code for AltiVec (conditional to __ALTIVEC__). GCC's altivec.h may in a !__APPLE_ALTIVEC__ code path redefine bool, leading to type mismatches. altivec.h recommends to #undef for C++ compatibility, but doing so in C leads to bool remaining undefined. Fix by redefining bool to _Bool as mandated for stdbool.h by POSIX. Signed-off-by: Andreas Färber andreas.faer...@web.de Reviewed-by: Paolo Bonzini pbonz...@redhat.com --- arch_init.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch_init.c b/arch_init.c index 988adca..a9e8b74 100644 --- a/arch_init.c +++ b/arch_init.c @@ -100,6 +100,10 @@ const uint32_t arch_type = QEMU_ARCH; #define VECTYPEvector unsigned char #define SPLAT(p) vec_splat(vec_ld(0, p), 0) #define ALL_EQ(v1, v2) vec_all_eq(v1, v2) +/* altivec.h may redefine the bool macro as vector type. + * Reset it to POSIX semantics. */ +#undef bool +#define bool _Bool #elif defined __SSE2__ #include emmintrin.h #define VECTYPE__m128i -- 1.7.7
[Qemu-devel] [PULL 1.1] Cocoa patch queue for v1.1 2012-05-29
Hello Anthony, Please pull the Cocoa queue into qemu.git master: One general build fix for Darwin/ppc, one behavioral fix for make check with Cocoa. The following changes since commit 24f50d7ea5896a30b0e78f68884586bb8b40ff97: tcg/ppc: Handle _CALL_DARWIN being undefined on Darwin (2012-05-27 21:52:56 +0400) are available in the git repository at: git://repo.or.cz/qemu/afaerber.git cocoa-for-upstream Andreas Färber (2): arch_init: Fix AltiVec build on Darwin/ppc cocoa: Suppress Cocoa frontend for -qtest arch_init.c |4 ui/cocoa.m |3 ++- 2 files changed, 6 insertions(+), 1 deletions(-)
[Qemu-devel] [PATCH 2/2] cocoa: Suppress Cocoa frontend for -qtest
Signed-off-by: Andreas Färber andreas.faer...@web.de
---
ui/cocoa.m |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/ui/cocoa.m b/ui/cocoa.m
index e7d6e89..2383646 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -879,7 +879,8 @@ int main (int argc, const char * argv[]) {
!strcmp(opt, -vnc) ||
!strcmp(opt, -nographic) ||
!strcmp(opt, -version) ||
-!strcmp(opt, -curses)) {
+!strcmp(opt, -curses) ||
+!strcmp(opt, -qtest)) {
return qemu_main(gArgc, gArgv, *_NSGetEnviron());
}
}
--
1.7.7
Re: [Qemu-devel] [PATCH for-1.1] Makefile: Fix QOM dependencies
Il 29/05/2012 11:47, Andreas Färber ha scritto: Am 29.05.2012 11:43, schrieb Paolo Bonzini: Il 29/05/2012 11:28, Andreas Färber ha scritto: Am 29.05.2012 09:05, schrieb Gerd Hoffmann: - rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d net/*.o net/*.d fsdev/*.o fsdev/*.d ui/*.o ui/*.d qapi/*.o qapi/*.d qga/*.o qga/*.d - rm -f qom/*.o qom/*.d + rm -f slirp/*.o audio/*.o block/*.o net/*.o fsdev/*.o ui/*.o qapi/*.o qga/*.o + rm -f qom/*.o I think this is calling for a centrally maintained (or automatically derived) list of build directories. Quite difficult with the abuse of vpath that we currently have... but we can still proceed incrementally. For 1.1 I was thinking of something like BUILDSUBDIRS=slirp audio block net fsdev ui qapi qga qom for dir in $(BUILDSUBDIRS); do \ rm -rf $dir/*.o $dir/*.d; \ done which possibly could also be reused for the list of *.d includes with some clever macro usage. I think even this is too much for 1.1. After all the problems come only if you modify the source, and right now 99.99% of the people will use the git tree for that. Paolo
Re: [Qemu-devel] [PATCH for-1.1] Makefile: Fix QOM dependencies
Am 29.05.2012 11:50, schrieb Anthony Liguori: On 05/29/2012 04:47 AM, Andreas Färber wrote: Am 29.05.2012 11:43, schrieb Paolo Bonzini: Il 29/05/2012 11:28, Andreas Färber ha scritto: Am 29.05.2012 09:05, schrieb Gerd Hoffmann: -rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d net/*.o net/*.d fsdev/*.o fsdev/*.d ui/*.o ui/*.d qapi/*.o qapi/*.d qga/*.o qga/*.d -rm -f qom/*.o qom/*.d +rm -f slirp/*.o audio/*.o block/*.o net/*.o fsdev/*.o ui/*.o qapi/*.o qga/*.o +rm -f qom/*.o I think this is calling for a centrally maintained (or automatically derived) list of build directories. Quite difficult with the abuse of vpath that we currently have... but we can still proceed incrementally. For 1.1 I was thinking of something like BUILDSUBDIRS=slirp audio block net fsdev ui qapi qga qom for dir in $(BUILDSUBDIRS); do \ rm -rf $dir/*.o $dir/*.d; \ done which possibly could also be reused for the list of *.d includes with some clever macro usage. I'd prefer not to make this change in 1.1.0 as this doesn't seem to be a release blocker to me. I'd rather do something more significant in 1.2 and backport to a 1.1.1 release. Is this change referring to my patch, Gerd's attachment or my above snippet? I don't see it as a release blocker, but having proper dependencies in the release would be good for people patching the tarball. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH for-1.1] Makefile: Fix QOM dependencies
On 05/29/2012 05:01 AM, Paolo Bonzini wrote: Il 29/05/2012 11:47, Andreas Färber ha scritto: Am 29.05.2012 11:43, schrieb Paolo Bonzini: Il 29/05/2012 11:28, Andreas Färber ha scritto: Am 29.05.2012 09:05, schrieb Gerd Hoffmann: - rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d net/*.o net/*.d fsdev/*.o fsdev/*.d ui/*.o ui/*.d qapi/*.o qapi/*.d qga/*.o qga/*.d - rm -f qom/*.o qom/*.d + rm -f slirp/*.o audio/*.o block/*.o net/*.o fsdev/*.o ui/*.o qapi/*.o qga/*.o + rm -f qom/*.o I think this is calling for a centrally maintained (or automatically derived) list of build directories. Quite difficult with the abuse of vpath that we currently have... but we can still proceed incrementally. For 1.1 I was thinking of something like BUILDSUBDIRS=slirp audio block net fsdev ui qapi qga qom for dir in $(BUILDSUBDIRS); do \ rm -rf $dir/*.o $dir/*.d; \ done which possibly could also be reused for the list of *.d includes with some clever macro usage. I think even this is too much for 1.1. After all the problems come only if you modify the source, and right now 99.99% of the people will use the git tree for that. Agreed. I think this is 1.2 material with a possible backport to 1.1.x if we find a nice solution to the problem. Regards, Anthony Liguori Paolo
[Qemu-devel] [PATCH 5/6] ISCSI: Only call READCAPACITY16 for SBC devices, use READCAPACITY10 for MMC
From: Ronnie Sahlberg ronniesahlb...@gmail.com
Signed-off-by: Ronnie Sahlberg ronniesahlb...@gmail.com
---
block/iscsi.c | 64 -
1 file changed, 59 insertions(+), 5 deletions(-)
diff --git a/block/iscsi.c b/block/iscsi.c
index 91cca83..472c853 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -510,6 +510,42 @@ iscsi_readcapacity16_cb(struct iscsi_context *iscsi, int
status,
}
static void
+iscsi_readcapacity10_cb(struct iscsi_context *iscsi, int status,
+void *command_data, void *opaque)
+{
+struct IscsiTask *itask = opaque;
+struct scsi_readcapacity10 *rc10;
+struct scsi_task *task = command_data;
+
+if (status != 0) {
+error_report(iSCSI: Failed to read capacity of iSCSI lun. %s,
+ iscsi_get_error(iscsi));
+itask-status = 1;
+itask-complete = 1;
+scsi_free_scsi_task(task);
+return;
+}
+
+rc10 = scsi_datain_unmarshall(task);
+if (rc10 == NULL) {
+error_report(iSCSI: Failed to unmarshall readcapacity10 data.);
+itask-status = 1;
+itask-complete = 1;
+scsi_free_scsi_task(task);
+return;
+}
+
+itask-iscsilun-block_size = rc10-block_size;
+itask-iscsilun-num_blocks = rc10-lba + 1;
+itask-bs-total_sectors= itask-iscsilun-num_blocks *
+ itask-iscsilun-block_size / BDRV_SECTOR_SIZE ;
+
+itask-status = 0;
+itask-complete = 1;
+scsi_free_scsi_task(task);
+}
+
+static void
iscsi_inquiry_cb(struct iscsi_context *iscsi, int status, void *command_data,
void *opaque)
{
@@ -537,13 +573,31 @@ iscsi_inquiry_cb(struct iscsi_context *iscsi, int status,
void *command_data,
scsi_free_scsi_task(task);
-task = iscsi_readcapacity16_task(iscsi, itask-iscsilun-lun,
+switch (itask-iscsilun-type) {
+case TYPE_DISK:
+task = iscsi_readcapacity16_task(iscsi, itask-iscsilun-lun,
iscsi_readcapacity16_cb, opaque);
-if (task == NULL) {
-error_report(iSCSI: failed to send readcapacity16 command.);
-itask-status = 1;
+if (task == NULL) {
+error_report(iSCSI: failed to send readcapacity16 command.);
+itask-status = 1;
+itask-complete = 1;
+return;
+}
+break;
+case TYPE_ROM:
+task = iscsi_readcapacity10_task(iscsi, itask-iscsilun-lun,
+ 0, 0,
+ iscsi_readcapacity10_cb, opaque);
+if (task == NULL) {
+error_report(iSCSI: failed to send readcapacity16 command.);
+itask-status = 1;
+itask-complete = 1;
+return;
+}
+break;
+default:
+itask-status = 0;
itask-complete = 1;
-return;
}
}
--
1.7.10.1
[Qemu-devel] [PATCH 1.1] xhci: add usage info to docs
Signed-off-by: Gerd Hoffmann kra...@redhat.com --- docs/usb2.txt | 15 +++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/docs/usb2.txt b/docs/usb2.txt index 228aa33..d17e3c0 100644 --- a/docs/usb2.txt +++ b/docs/usb2.txt @@ -55,6 +55,21 @@ try ... ... then use bus=ehci.0 to assign your usb devices to that bus. +xhci controller support +--- + +There also is xhci host controller support available. It got alot +less testing than ehci and there are a bunch of known limitations, so +ehci may work better for you. On the other hand the xhci hardware +design is much more virtualization-friendly, thus xhci emulation uses +less ressources (especially cpu). If you wanna give xhci a try +use this to add the host controller ... + +qemu -device nec-usb-xhci,id=xhci + +... then use bus=xhci.0 when assigning usb devices. + + More USB tips tricks == -- 1.7.1
[Qemu-devel] [Bug 1003054] Re: Socket not closed when a connection ends
This implies serious duplication problem in case of reboot : A [192.168.0.1] -- B [192.168.0.2] A# ping 192.168.0.1 PING 192.168.0.1 56(84) bytes of data 64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=3.82 ms 64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=0.344 ms 64 bytes from 192.168.0.1: icmp_req=3 ttl=64 time=0.325 ms B# reboot A# ping 192.168.0.1 PING 192.168.0.1 56(84) bytes of data 64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=3.82 ms 64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=3.82 ms (DUP!) 64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=0.344 ms 64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=0.344 ms (DUP!) 64 bytes from 192.168.0.1: icmp_req=3 ttl=64 time=0.325 ms 64 bytes from 192.168.0.1: icmp_req=3 ttl=64 time=0.325 ms (DUP!) Vince -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1003054 Title: Socket not closed when a connection ends Status in QEMU: New Bug description: Hi, I've noticed in the QEMU monitor that when a TCP connection between to QEMU virtual machines is closed in one side, the other side is not closed. Consequence is that the network behavior is completely messed up in case of a reconnection. For instance, we consider that we have 2 virtual machines : $ qemu -name A -net nic vlan=0 -net socket,vlan=0,listen=127.0.0.1:7000 $ qemu -name B -net nic vlan=0 -net socket,vlan=0,connect=127.0.0.1:7000 If the socket of B is closed (error or machine down), the socket in A is not closed : B % host_net_remove 0 socket.0 A % info network e1000.0: ... socket.0: ... (The removed connection) B % host_net_add socket vlan=0,connect=127.0.0.1:7000 A % info network e1000.0: ... socket.0: ... (The removed connection) socket.1: ... (The new connection) By not perform any close on sockets of A, the new communication between A and B is corrupted (duplicated packets, invalid transmission, etc.). In the case of the close was performed by A, B should detect a problem on the socket and retry a new connection, unfortunately, this is not the case. Those two problems corrupt the dynamicity of a QEMU topology which could be strongly problematic for the development of network tools based on QEMU. Thanks a lot. Vince To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1003054/+subscriptions
[Qemu-devel] [PATCH 0/3][v17] megasas: LSI Megaraid SAS HBA emulation
This is an updated patchset for megasas. Upon popular demand I've split it into three parts, the header file, the emulation itself, and a patch adding trace events to the emulation. Paolo, can you merge it via your tree? Or should I ask someone else? Changes since v17: - Fix crash when booting without Option ROM, reported by Alex Graf Changes since v16: - Codingstyle fixes, reported by Alex Graf Changes since v15: - Move to new SCSI API - Use generic trace functions for DCMDs - Replace bitfields with defines - Implement CFG_READ - Fix enclosure ID reporting Changes since v14: - Rename MPTState to MegasasState - Use bool type - Enable 64 bit PCI accesses - Replace raid mode string handling - Use common function for requests handling Changes since v13: - Remove separate MSI-X BAR - Simplify BAR allocation Changes since v12: - Fixup flag setting via properties - Fixup MSI-X handling - Disable MSI-X per default Changes since v11: - Remove unneeded variables Changes since v10: - Port to new device type API - Include suggestion from Alex Graf: - Remove 'inline' function declaration - Queue setup and interrupt enablement needs to be treated independently - Always read in 64 bit context and just mask out the top bits if required Changes since v9: - Split off trace events into a separate patch - Do not check for max_luns in PD Info - Update trace events - Clarify license statement - Fixup coding style issues Changes since v8: - Remove 'disable' keyword from trace definitions - Convert hand-crafted debugging statements with trace definitions - Treat 'context' tag as little endian Changes since v7: - Port to new memory API - Port to new PCI infrastructure - Use fixed buffers for sense processing - Update to updated SCSI infrastructure Changes since v6: - Preliminary patches pushed to Kevins block tree - Implement 64bit contexts, required for Windows7 - Use iovecs for DCMD processing - Add MSI-X support Latest Linux driver now happily uses MSI-X. - Static iovec allocation We have a fixed upper number of iovecs, so we can save us the allocation. Suggested by Alex Graf. - Update MFI header Latest Linux driver has some more definitions, add them - Fixup AEN handling - Update tracing details - Remove sdev pointer from megasas_cmd_t Changes since v5: - megasas: Use tracing infrastructure instead of DPRINTF - megasas: Use new PCI infrastructure - megasas: Check for iovec mapping failure cpu_map_physical_memory() might fail, so we need to check for it when mapping iovecs. - megasas: Trace scsi buffer overflow The transfer length as specified in the SCSI command might disagree with the length of the iovec. We should be tracing these issues. - megasas: Reset frames after init firmware When receiving an INIT FIRMWARE command we need reset all frames, otherwise some frames might point to invalid memory. Chances since v4: - megasas: checkpatch.pl fixes and update to work with the changed interface in scsi_req_new(). Also included the suggested fixes from Alex. Hannes Reinecke (3): megasas: Add header file megasas: LSI Megaraid SAS HBA emulation megasas: Add trace events Makefile.objs |1 + default-configs/pci.mak |1 + hw/megasas.c| 2198 +++ hw/mfi.h| 1248 +++ hw/pci_ids.h|3 +- trace-events| 79 ++ 6 files changed, 3529 insertions(+), 1 deletions(-) create mode 100644 hw/megasas.c create mode 100644 hw/mfi.h -- 1.7.3.4
[Qemu-devel] [PATCH 1/3] megasas: Add header file
This patch adds the header file for megasas. Signed-off-by: Hannes Reinecke h...@suse.de --- hw/mfi.h | 1248 ++ 1 files changed, 1248 insertions(+), 0 deletions(-) create mode 100644 hw/mfi.h diff --git a/hw/mfi.h b/hw/mfi.h new file mode 100644 index 000..8a82162 --- /dev/null +++ b/hw/mfi.h @@ -0,0 +1,1248 @@ +/* + * NetBSD header file, copied from + * http://gitorious.org/freebsd/freebsd/blobs/HEAD/sys/dev/mfi/mfireg.h + */ +/*- + * Copyright (c) 2006 IronPort Systems + * Copyright (c) 2007 LSI Corp. + * Copyright (c) 2007 Rajesh Prabhakaran. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#ifndef MFI_REG_H +#define MFI_REG_H + +/* + * MegaRAID SAS MFI firmware definitions + */ + +/* + * Start with the register set. All registers are 32 bits wide. + * The usual Intel IOP style setup. + */ +#define MFI_IMSG0 0x10/* Inbound message 0 */ +#define MFI_IMSG1 0x14/* Inbound message 1 */ +#define MFI_OMSG0 0x18/* Outbound message 0 */ +#define MFI_OMSG1 0x1c/* Outbound message 1 */ +#define MFI_IDB 0x20/* Inbound doorbell */ +#define MFI_ISTS 0x24/* Inbound interrupt status */ +#define MFI_IMSK 0x28/* Inbound interrupt mask */ +#define MFI_ODB 0x2c/* Outbound doorbell */ +#define MFI_OSTS 0x30/* Outbound interrupt status */ +#define MFI_OMSK 0x34/* Outbound interrupt mask */ +#define MFI_IQP 0x40/* Inbound queue port */ +#define MFI_OQP 0x44/* Outbound queue port */ + +/* + * 1078 specific related register + */ +#define MFI_ODR00x9c/* outbound doorbell register0 */ +#define MFI_ODCR0 0xa0/* outbound doorbell clear register0 */ +#define MFI_OSP00xb0/* outbound scratch pad0 */ +#define MFI_IQPL0xc0/* Inbound queue port (low bytes) */ +#define MFI_IQPH0xc4/* Inbound queue port (high bytes) */ +#define MFI_DIAG0xf8/* Host diag */ +#define MFI_SEQ 0xfc/* Sequencer offset */ +#define MFI_1078_EIM0x8004 /* 1078 enable intrrupt mask */ +#define MFI_RMI 0x2 /* reply message interrupt */ +#define MFI_1078_RM 0x8000 /* reply 1078 message interrupt */ +#define MFI_ODC 0x4 /* outbound doorbell change interrupt */ + +/* + * gen2 specific changes + */ +#define MFI_GEN2_EIM0x0005 /* gen2 enable interrupt mask */ +#define MFI_GEN2_RM 0x0001 /* reply gen2 message interrupt */ + +/* + * skinny specific changes + */ +#define MFI_SKINNY_IDB 0x00/* Inbound doorbell is at 0x00 for skinny */ +#define MFI_SKINNY_RM 0x0001 /* reply skinny message interrupt */ + +/* Bits for MFI_OSTS */ +#define MFI_OSTS_INTR_VALID 0x0002 + +/* + * Firmware state values. Found in OMSG0 during initialization. + */ +#define MFI_FWSTATE_MASK0xf000 +#define MFI_FWSTATE_UNDEFINED 0x +#define MFI_FWSTATE_BB_INIT 0x1000 +#define MFI_FWSTATE_FW_INIT 0x4000 +#define MFI_FWSTATE_WAIT_HANDSHAKE 0x6000 +#define MFI_FWSTATE_FW_INIT_2 0x7000 +#define MFI_FWSTATE_DEVICE_SCAN 0x8000 +#define MFI_FWSTATE_BOOT_MSG_PENDING0x9000 +#define MFI_FWSTATE_FLUSH_CACHE 0xa000 +#define MFI_FWSTATE_READY 0xb000 +#define MFI_FWSTATE_OPERATIONAL 0xc000 +#define MFI_FWSTATE_FAULT 0xf000 +#define MFI_FWSTATE_MAXSGL_MASK 0x00ff +#define MFI_FWSTATE_MAXCMD_MASK 0x +#define MFI_FWSTATE_MSIX_SUPPORTED 0x0400 +#define
[Qemu-devel] [PATCH 3/3] megasas: Add trace events
This patch add trace events to the megasas HBA emulation.
Signed-off-by: Hannes Reinecke h...@suse.de
---
hw/megasas.c | 348 +-
trace-events | 79 +
2 files changed, 377 insertions(+), 50 deletions(-)
diff --git a/hw/megasas.c b/hw/megasas.c
index bf5f8cd..af7f175 100644
--- a/hw/megasas.c
+++ b/hw/megasas.c
@@ -26,6 +26,7 @@
#include scsi.h
#include scsi-defs.h
#include block_int.h
+#include trace.h
#include mfi.h
@@ -221,6 +222,8 @@ static int megasas_map_sgl(MegasasCmd *cmd, union mfi_sgl
*sgl)
cmd-flags = le16_to_cpu(cmd-frame-header.flags);
iov_count = cmd-frame-header.sge_count;
if (iov_count MEGASAS_MAX_SGE) {
+trace_megasas_iovec_sgl_overflow(cmd-index, iov_count,
+ MEGASAS_MAX_SGE);
return iov_count;
}
qemu_sglist_init(cmd-qsg, iov_count);
@@ -228,17 +231,25 @@ static int megasas_map_sgl(MegasasCmd *cmd, union mfi_sgl
*sgl)
dma_addr_t iov_pa, iov_size_p;
if (!sgl) {
+trace_megasas_iovec_sgl_underflow(cmd-index, i);
goto unmap;
}
iov_pa = megasas_sgl_get_addr(cmd, sgl);
iov_size_p = megasas_sgl_get_len(cmd, sgl);
if (!iov_pa || !iov_size_p) {
+trace_megasas_iovec_sgl_invalid(cmd-index, i,
+iov_pa, iov_size_p);
goto unmap;
}
qemu_sglist_add(cmd-qsg, iov_pa, iov_size_p);
sgl = megasas_sgl_next(cmd, sgl);
iov_size += (size_t)iov_size_p;
}
+if (cmd-iov_size iov_size) {
+trace_megasas_iovec_overflow(cmd-index, iov_size, cmd-iov_size);
+} else if (cmd-iov_size iov_size) {
+trace_megasas_iovec_underflow(cmd-iov_size, iov_size, cmd-iov_size);
+}
cmd-iov_offset = 0;
return 0;
unmap:
@@ -411,6 +422,7 @@ static MegasasCmd *megasas_next_frame(MegasasState *s,
cmd = megasas_lookup_frame(s, frame);
if (cmd) {
+trace_megasas_qf_found(cmd-index, cmd-pa);
return cmd;
}
index = s-reply_queue_head;
@@ -423,6 +435,10 @@ static MegasasCmd *megasas_next_frame(MegasasState *s,
index = megasas_next_index(s, index, s-fw_cmds);
num++;
}
+if (!cmd) {
+trace_megasas_qf_failed(frame);
+}
+trace_megasas_qf_new(index, cmd);
return cmd;
}
@@ -443,6 +459,7 @@ static MegasasCmd *megasas_enqueue_frame(MegasasState *s,
/* Map all possible frames */
cmd-frame = cpu_physical_memory_map(frame, frame_size_p, 0);
if (frame_size_p != frame_size) {
+trace_megasas_qf_map_failed(cmd-index, (unsigned long)frame);
if (cmd-frame) {
cpu_physical_memory_unmap(cmd-frame, frame_size_p, 0, 0);
cmd-frame = NULL;
@@ -460,6 +477,9 @@ static MegasasCmd *megasas_enqueue_frame(MegasasState *s,
cmd-count = count;
s-busy++;
+trace_megasas_qf_enqueue(cmd-index, cmd-count, cmd-context,
+ s-reply_queue_head, s-busy);
+
return cmd;
}
@@ -485,6 +505,8 @@ static void megasas_complete_frame(MegasasState *s,
uint64_t context)
stl_le_phys(s-reply_queue_pa + queue_offset, context);
}
s-reply_queue_head = megasas_next_index(s, tail, s-fw_cmds);
+trace_megasas_qf_complete(context, tail, queue_offset,
+ s-busy, s-doorbell);
}
if (megasas_intr_enabled(s)) {
@@ -492,11 +514,15 @@ static void megasas_complete_frame(MegasasState *s,
uint64_t context)
s-doorbell++;
if (s-doorbell == 1) {
if (msix_enabled(s-dev)) {
+trace_megasas_msix_raise(0);
msix_notify(s-dev, 0);
} else {
+trace_megasas_irq_raise();
qemu_irq_raise(s-dev.irq[0]);
}
}
+} else {
+trace_megasas_qf_complete_noirq(context);
}
}
@@ -534,15 +560,18 @@ static int megasas_init_firmware(MegasasState *s,
MegasasCmd *cmd)
pa_lo = le32_to_cpu(cmd-frame-init.qinfo_new_addr_lo);
pa_hi = le32_to_cpu(cmd-frame-init.qinfo_new_addr_hi);
iq_pa = (((uint64_t) pa_hi 32) | pa_lo);
+trace_megasas_init_firmware((uint64_t)iq_pa);
initq_size = sizeof(*initq);
initq = cpu_physical_memory_map(iq_pa, initq_size, 0);
if (!initq || initq_size != sizeof(*initq)) {
+trace_megasas_initq_map_failed(cmd-index);
s-event_count++;
ret = MFI_STAT_MEMORY_NOT_AVAILABLE;
goto out;
}
s-reply_queue_len = le32_to_cpu(initq-rq_entries) 0x;
if (s-reply_queue_len s-fw_cmds) {
+trace_megasas_initq_mismatch(s-reply_queue_len, s-fw_cmds);
s-event_count++;
ret = MFI_STAT_INVALID_PARAMETER;
goto out;
@@ -562,6 +591,9 @@ static int megasas_init_firmware(MegasasState *s,
MegasasCmd *cmd)
Re: [Qemu-devel] [PATCH 3/3] qapi: convert sendkey
On 05/25/2012 09:14 PM, Anthony Liguori wrote:
On 05/24/2012 10:51 PM, Eric Blake wrote:
On 05/24/2012 09:32 PM, Amos Kong wrote:
Convert 'sendkey' to use. do_sendkey() depends on some variables
in monitor.c, so reserve qmp_sendkey() to monitor.c Rename
'string' to 'keys', rename 'hold_time' to 'hold-time'
Signed-off-by: Amos Kongak...@redhat.com
+## +# @sendkey: +# +# Send keys to VM. +# +# @keys: key
sequence +# @hold-time: time to delay key up events +# +#
Returns: Nothing on success +# If key is unknown or
redundant, QERR_INVALID_PARAMETER +# If key is invalid,
QERR_INVALID_PARAMETER_VALUE +# +# Notes: Send @var{keys} to the
emulator. @var{keys} could be the name of the +#key or
the raw value in either decimal or hexadecimal format. Use +#
@code{-} to press several keys simultaneously. +# +# Since:
0.14.0 +## +{ 'command': 'sendkey', 'data': {'keys': 'str',
'*hold-time': 'int'} }
Rather than making 'keys' a free-form string where qemu then has
to parse '-' to separate keys, should we instead make it a JSON
array? For example,
{ execute:sendky, data:{ keys:[ctrl, alt, del],
hold-time:200 } }
Actually, we should do:
{ 'enum': 'KeyCode', 'data': [ 'map', 'exclam', 'at', 'numbersign',
...] }
{ 'command': 'sendkey', 'data': { 'keys': [ 'KeyCode' ],
'*hold-time': 'int' } }
That also has the benefit of making it clear what symbolic names of
the keycodes we support are.
Talked with Anthony in IRC, paste a summary.
There is a definition of supported keys in monitor.c (key_defs[]),
we need to add all the items to enum.
There is a macro in monitor.c (key_defs[]), just ignore it.
#if defined(TARGET_SPARC) !defined(TARGET_SPARC64)
If we use enum, we don't need to check the keycodes in qmp_sendkey(),
and key-names need to be converted to keycodes in hmp_sendkey().
The keycodes are not consecutive, enum values do not need to be the
keysym values, use a different table to map enum names to keysym values.
--
Amos.
Re: [Qemu-devel] qtest: setitimer() failures on Darwin and illumos
On Mon, 28 May 2012, Paolo Bonzini wrote:
Il 28/05/2012 21:40, Andreas Färber ha scritto:
I'm seeing qemu-timer.c:unix_rearm_timer()'s setitimer() abort with
EINVAL during `make check` on both platforms. The value of
nearest_delta_ns appears to be INT64_MAX. Is this expected? Is it
possible that this value is too large for it_value on some platforms?
Apple's man page mentions that as possible reason for EINVAL but doesn't
describe how to obtain such an upper value, nor of course where in the
QEMU code base we would need to make adaptions. ;)
Any suggestions?
You shouldn't call the rearm function at all if you get INT64_MAX. This
applies to all timers.
Yep. In fact qemu_rearm_alarm_timer returns immediately if none of the
clocks have active timers.
However if at least one of them does, we call qemu_next_alarm_deadline
(that potentially can return INT64_MAX) and then rearm.
So for example if the clock that has active timers is disabled (I don't
if it is possible to get in this state), qemu_next_alarm_deadline would
return INT64_MAX.
I think we should make the appended change in order to make the code
more reliable.
Regarding setitimer returning -EINVAL, we could check for out of bound
parameters in unix_rearm_timer, but we need to know exactly what the
upper limit is. I tried to look for the Darwin manpage of setitimer, but
that information is missing.
Could you please run a couple of tests to find out what the actual limit
is?
---
diff --git a/qemu-timer.c b/qemu-timer.c
index de98977..81ff824 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -112,14 +112,10 @@ static int64_t qemu_next_alarm_deadline(void)
static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t)
{
-int64_t nearest_delta_ns;
-if (!rt_clock-active_timers
-!vm_clock-active_timers
-!host_clock-active_timers) {
-return;
+int64_t nearest_delta_ns = qemu_next_alarm_deadline();
+if (nearest_delta_ns INT64_MAX) {
+t-rearm(t, nearest_delta_ns);
}
-nearest_delta_ns = qemu_next_alarm_deadline();
-t-rearm(t, nearest_delta_ns);
}
/* TODO: MIN_TIMER_REARM_NS should be optimized */
Re: [Qemu-devel] [PATCH 3/3] qapi: convert sendkey
On 05/29/2012 07:57 PM, Amos Kong wrote:
On 05/25/2012 09:14 PM, Anthony Liguori wrote:
On 05/24/2012 10:51 PM, Eric Blake wrote:
On 05/24/2012 09:32 PM, Amos Kong wrote:
Convert 'sendkey' to use. do_sendkey() depends on some variables
in monitor.c, so reserve qmp_sendkey() to monitor.c Rename
'string' to 'keys', rename 'hold_time' to 'hold-time'
Signed-off-by: Amos Kongak...@redhat.com
+## +# @sendkey: +# +# Send keys to VM. +# +# @keys: key
sequence +# @hold-time: time to delay key up events +# +#
Returns: Nothing on success +# If key is unknown or
redundant, QERR_INVALID_PARAMETER +# If key is invalid,
QERR_INVALID_PARAMETER_VALUE +# +# Notes: Send @var{keys} to the
emulator. @var{keys} could be the name of the +#key or
the raw value in either decimal or hexadecimal format. Use +#
@code{-} to press several keys simultaneously. +# +# Since:
0.14.0 +## +{ 'command': 'sendkey', 'data': {'keys': 'str',
'*hold-time': 'int'} }
Rather than making 'keys' a free-form string where qemu then has
to parse '-' to separate keys, should we instead make it a JSON
array? For example,
{ execute:sendky, data:{ keys:[ctrl, alt, del],
hold-time:200 } }
Actually, we should do:
{ 'enum': 'KeyCode', 'data': [ 'map', 'exclam', 'at', 'numbersign',
...] }
{ 'command': 'sendkey', 'data': { 'keys': [ 'KeyCode' ],
'*hold-time': 'int' } }
^^^
It doesn't work. KeyCodeList could not be defined automatically. I
try to add a type definition to make it works, is it ok?
{ 'enum': 'Keycode',
'data': [ 'shift', 'shift_r', 'alt', 'alt_r', 'altgr', 'altgr_r',
..
'lf', 'help', 'meta_l', 'meta_r', 'compose' ] }
{ 'type': 'KeyCodes',
'data': { 'name', 'Keycode' } }
{ 'command': 'sendkey',
'data': { 'keys': ['KeyCodes'], '*hold-time': 'int' } }
New problems: special character '' could not be added to enum, other
characters are fine.
That also has the benefit of making it clear what symbolic names of
the keycodes we support are.
Talked with Anthony in IRC, paste a summary.
There is a definition of supported keys in monitor.c (key_defs[]),
we need to add all the items to enum.
There is a macro in monitor.c (key_defs[]), just ignore it.
#if defined(TARGET_SPARC) !defined(TARGET_SPARC64)
If we use enum, we don't need to check the keycodes in qmp_sendkey(),
and key-names need to be converted to keycodes in hmp_sendkey().
The keycodes are not consecutive, enum values do not need to be the
keysym values, use a different table to map enum names to keysym values.
--
Amos.
Re: [Qemu-devel] qtest: setitimer() failures on Darwin and illumos
Il 29/05/2012 14:01, Stefano Stabellini ha scritto: On Mon, 28 May 2012, Paolo Bonzini wrote: Il 28/05/2012 21:40, Andreas Färber ha scritto: I'm seeing qemu-timer.c:unix_rearm_timer()'s setitimer() abort with EINVAL during `make check` on both platforms. The value of nearest_delta_ns appears to be INT64_MAX. Is this expected? Is it possible that this value is too large for it_value on some platforms? Apple's man page mentions that as possible reason for EINVAL but doesn't describe how to obtain such an upper value, nor of course where in the QEMU code base we would need to make adaptions. ;) Any suggestions? You shouldn't call the rearm function at all if you get INT64_MAX. This applies to all timers. Yep. In fact qemu_rearm_alarm_timer returns immediately if none of the clocks have active timers. However if at least one of them does, we call qemu_next_alarm_deadline (that potentially can return INT64_MAX) and then rearm. So for example if the clock that has active timers is disabled (I don't if it is possible to get in this state), qemu_next_alarm_deadline would return INT64_MAX. I think we should make the appended change in order to make the code more reliable. Yes, that makes sense, can you submit it with SoB? Paolo
Re: [Qemu-devel] [PATCH 0/3][v17] megasas: LSI Megaraid SAS HBA emulation
Il 29/05/2012 13:51, Hannes Reinecke ha scritto: This is an updated patchset for megasas. Upon popular demand I've split it into three parts, the header file, the emulation itself, and a patch adding trace events to the emulation. Paolo, can you merge it via your tree? Or should I ask someone else? Yes, of course. I'll wait for an Acked-by or a couple of weeks, whatever comes first. Paolo
[Qemu-devel] [PATCH] ANSI escape characters support for Windows console
This patch adds support of ANSI escape characters used in readline module
to impelementation of stdio character device for Windows.
Signed-off-by: Pavel Dovgalyuk pavel.dovga...@gmail.com
---
qemu-char.c | 48 ++--
1 files changed, 38 insertions(+), 10 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index fe1126f..6035b79 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1810,19 +1810,41 @@ static int win_stdio_write(CharDriverState *chr, const
uint8_t *buf, int
len)
{
HANDLE hStdOut = GetStdHandle(STD_OUTPUT_HANDLE);
DWORD dwSize;
-int len1;
+int ret = 0;
+CONSOLE_SCREEN_BUFFER_INFO info;
-len1 = len;
-
-while (len1 0) {
-if (!WriteFile(hStdOut, buf, len1, dwSize, NULL)) {
-break;
+while (len 0) {
+if (len 2 buf[0] == '\033' buf[1] == '[') {
+switch (buf[2]) {
+case 'D':
+if (!WriteFile(hStdOut, \b, 1, dwSize, NULL)) {
+return ret;
+}
+break;
+case 'K':
+if (!GetConsoleScreenBufferInfo(hStdOut, info)) {
+return ret;
+}
+if (!FillConsoleOutputCharacter(hStdOut, ' ',
+info.dwSize.X - info.dwCursorPosition.X,
+info.dwCursorPosition, dwSize)) {
+return ret;
+}
+break;
+}
+dwSize = 3;
+} else {
+if (!WriteFile(hStdOut, buf, 1, dwSize, NULL)) {
+return ret;
+}
}
-buf += dwSize;
-len1 -= dwSize;
+
+buf += dwSize;
+len -= dwSize;
+ret += dwSize;
}
-return len - len1;
+return ret;
}
static void win_stdio_wait_func(void *opaque)
@@ -1948,7 +1970,9 @@ static CharDriverState *qemu_chr_open_win_stdio(QemuOpts
*opts)
{
CharDriverState *chr;
WinStdioCharState *stdio;
+HANDLE hStdOut;
DWORD dwMode;
+DWORD dwOutMode;
intis_console = 0;
if (stdio_nb_clients = STDIO_MAX_CLIENTS
@@ -1960,12 +1984,14 @@ static CharDriverState
*qemu_chr_open_win_stdio(QemuOpts *opts)
stdio = g_malloc0(sizeof(WinStdioCharState));
stdio-hStdIn = GetStdHandle(STD_INPUT_HANDLE);
-if (stdio-hStdIn == INVALID_HANDLE_VALUE) {
+if (stdio-hStdIn == INVALID_HANDLE_VALUE
+|| hStdOut == INVALID_HANDLE_VALUE) {
fprintf(stderr, cannot open stdio: invalid handle\n);
exit(1);
}
is_console = GetConsoleMode(stdio-hStdIn, dwMode) != 0;
+GetConsoleMode(hStdOut, dwOutMode);
chr-opaque= stdio;
chr-chr_write = win_stdio_write;
@@ -2005,9 +2031,11 @@ static CharDriverState *qemu_chr_open_win_stdio(QemuOpts
*opts)
/* set the terminal in raw mode */
/* ENABLE_QUICK_EDIT_MODE | ENABLE_EXTENDED_FLAGS */
dwMode |= ENABLE_PROCESSED_INPUT;
+dwOutMode |= ENABLE_PROCESSED_OUTPUT;
}
SetConsoleMode(stdio-hStdIn, dwMode);
+SetConsoleMode(hStdOut, dwOutMode);
chr-chr_set_echo = qemu_chr_set_echo_win_stdio;
qemu_chr_fe_set_echo(chr, false);
Re: [Qemu-devel] qtest: setitimer() failures on Darwin and illumos
Am 28.05.2012 22:15, schrieb Paolo Bonzini: Il 28/05/2012 21:40, Andreas Färber ha scritto: I'm seeing qemu-timer.c:unix_rearm_timer()'s setitimer() abort with EINVAL during `make check` on both platforms. The value of nearest_delta_ns appears to be INT64_MAX. Is this expected? Is it possible that this value is too large for it_value on some platforms? Apple's man page mentions that as possible reason for EINVAL but doesn't describe how to obtain such an upper value, nor of course where in the QEMU code base we would need to make adaptions. ;) Any suggestions? You shouldn't call the rearm function at all if you get INT64_MAX. This applies to all timers. I had tried doing if (... == INT64_MAX) return; in unix_rearm_timer() this morning. That avoided the abort, but the process ran at close to 100% CPU and seemed to hang make check. Don't know if that's related to timers though. Not a 1.1 release blocker anyway. It's unfortunate though that qtest has such bad error handling with lots of assertions - the previous accept() issue on illumos left zombie child processes behind and on my machine I've seen intermittent hangs of tests. I can certainly kill processes on my local machine if I notice, but for our RPM builds I'm avoiding make check for now... Andreas
Re: [Qemu-devel] [PATCH 3/3] qapi: convert sendkey
On Tue, 29 May 2012 20:17:53 +0800
Amos Kong ak...@redhat.com wrote:
On 05/29/2012 07:57 PM, Amos Kong wrote:
On 05/25/2012 09:14 PM, Anthony Liguori wrote:
On 05/24/2012 10:51 PM, Eric Blake wrote:
On 05/24/2012 09:32 PM, Amos Kong wrote:
Convert 'sendkey' to use. do_sendkey() depends on some variables
in monitor.c, so reserve qmp_sendkey() to monitor.c Rename
'string' to 'keys', rename 'hold_time' to 'hold-time'
Signed-off-by: Amos Kongak...@redhat.com
+## +# @sendkey: +# +# Send keys to VM. +# +# @keys: key
sequence +# @hold-time: time to delay key up events +# +#
Returns: Nothing on success +# If key is unknown or
redundant, QERR_INVALID_PARAMETER +# If key is invalid,
QERR_INVALID_PARAMETER_VALUE +# +# Notes: Send @var{keys} to the
emulator. @var{keys} could be the name of the +#key or
the raw value in either decimal or hexadecimal format. Use +#
@code{-} to press several keys simultaneously. +# +# Since:
0.14.0 +## +{ 'command': 'sendkey', 'data': {'keys': 'str',
'*hold-time': 'int'} }
Rather than making 'keys' a free-form string where qemu then has
to parse '-' to separate keys, should we instead make it a JSON
array? For example,
{ execute:sendky, data:{ keys:[ctrl, alt, del],
hold-time:200 } }
Actually, we should do:
{ 'enum': 'KeyCode', 'data': [ 'map', 'exclam', 'at', 'numbersign',
...] }
{ 'command': 'sendkey', 'data': { 'keys': [ 'KeyCode' ],
'*hold-time': 'int' } }
^^^
It doesn't work. KeyCodeList could not be defined automatically. I
try to add a type definition to make it works, is it ok?
Looks like we don't support enum lists yet, so the right thing to do is to add
it.
I can do it if you want, or you could give it a try.
{ 'enum': 'Keycode',
'data': [ 'shift', 'shift_r', 'alt', 'alt_r', 'altgr', 'altgr_r',
..
'lf', 'help', 'meta_l', 'meta_r', 'compose' ] }
{ 'type': 'KeyCodes',
'data': { 'name', 'Keycode' } }
{ 'command': 'sendkey',
'data': { 'keys': ['KeyCodes'], '*hold-time': 'int' } }
New problems: special character '' could not be added to enum, other
characters are fine.
Shouldn't the enum contain only symbolic names?
[Qemu-devel] [PATCH v3] Prevent disk data loss when closing qemu
Prevent disk data loss when closing qemu console window
under Windows 7.
v3. Comment for Sleep() parameter was updated.
Signed-off-by: Pavel Dovgalyuk pavel.dovga...@gmail.com
---
os-win32.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/os-win32.c b/os-win32.c
index ad76370..66c39b8 100644
--- a/os-win32.c
+++ b/os-win32.c
@@ -57,7 +57,11 @@ int setenv(const char *name, const char *value, int
overwrite)
static BOOL WINAPI qemu_ctrl_handler(DWORD type)
{
-exit(STATUS_CONTROL_C_EXIT);
+qemu_system_shutdown_request();
+/* Windows 7 kills application when the function returns.
+ Sleep here to give QEMU a try for closing.
+ Sleep period is 1ms because Windows kills the program
+ after 10 seconds anyway. */
+Sleep(1);
+
return TRUE;
}
Re: [Qemu-devel] [PATCH 1.1 v2] Prevent disk data loss when closing qemu
From: Anthony Liguori [mailto:anth...@codemonkey.ws]
Sent: Thursday, May 24, 2012 5:12 PM
On 05/24/2012 05:10 AM, Paolo Bonzini wrote:
Il 24/05/2012 09:42, Pavel Dovgaluk ha scritto:
Prevent disk data loss when closing qemu console window
under Windows 7.
Signed-off-by: Pavel Dovgalyukpavel.dovga...@gmail.com
---
os-win32.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/os-win32.c b/os-win32.c
index ad76370..66c39b8 100644
--- a/os-win32.c
+++ b/os-win32.c
@@ -57,7 +57,11 @@ int setenv(const char *name, const char *value, int
overwrite)
static BOOL WINAPI qemu_ctrl_handler(DWORD type)
{
-exit(STATUS_CONTROL_C_EXIT);
+qemu_system_shutdown_request();
+/* Windows 7 kills application when the function returns.
+ Sleep here to give QEMU a try for closing */
+Sleep(1);
+
return TRUE;
}
Reviewed-by: Paolo Bonzinipbonz...@redhat.com
Anthony, can you queue it for 1.1?
Is that a 10 second sleep? I really think this needs a much, much better
commit
message. Random sleeps like this are poison and need to be carefully
justified.
I've updated the comment in the code, please check the new version of the
patch.
Pavel Dovgaluk
[Qemu-devel] qemu_rearm_alarm_timer: do not call rearm if the next deadline is INT64_MAX
qemu_rearm_alarm_timer partially duplicates the code in
qemu_next_alarm_deadline to figure out if it needs to rearm the timer.
If it calls qemu_next_alarm_deadline, it always rearms the timer even if
the next deadline is INT64_MAX.
This patch simplifies the behavior of qemu_rearm_alarm_timer and removes
the duplicated code, always calling qemu_next_alarm_deadline and only
rearming the timer if the deadline is less than INT64_MAX.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
diff --git a/qemu-timer.c b/qemu-timer.c
index de98977..81ff824 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -112,14 +112,10 @@ static int64_t qemu_next_alarm_deadline(void)
static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t)
{
-int64_t nearest_delta_ns;
-if (!rt_clock-active_timers
-!vm_clock-active_timers
-!host_clock-active_timers) {
-return;
+int64_t nearest_delta_ns = qemu_next_alarm_deadline();
+if (nearest_delta_ns INT64_MAX) {
+t-rearm(t, nearest_delta_ns);
}
-nearest_delta_ns = qemu_next_alarm_deadline();
-t-rearm(t, nearest_delta_ns);
}
/* TODO: MIN_TIMER_REARM_NS should be optimized */
Re: [Qemu-devel] [PATCH v2] hmp/qxl: info spice: add qxl info
On Tue, 29 May 2012 09:25:40 +0200 Gerd Hoffmann kra...@redhat.com wrote: Hi, How would that work? I have QXLInfo that only makes sense when the information is about a qxl device. Can't have opaque data in a QMP response, so would this be a info display qxl info display cirrus etc. or info qxl? You could show what's available and/or being used currently. I think (Alon, correct me if I'm wrong) the use case is being able to figure whenever the guest drivers are installed and active. Alon, can you confirm this? I'm still not clear on the use-case. The two points I'm wondering are 1. If this is really tied to spice (and thus this info should be part of query-spice) and now 2. if the use case above really pertains to QMP. I've talked to someone in the past about having a way to get information about guest drivers statuses and the conclusion was that the guest-agent agent was better suited for that.
Re: [Qemu-devel] KVM call agenda for Tuesday, May 29th
Anthony Liguori anth...@codemonkey.ws wrote: On 05/28/2012 06:20 PM, Juan Quintela wrote: Hi Please send in any agenda items you are interested in covering. I'm in China for the next two weeks and this time is now pretty inconvenient. Unless there's anything that requires urgent discussion on the phone, I'd prefer to just handle things over the mailing list if no one objects. As our fearless leader is out. There are no topics. And nobody have objected to his visit to China (I think that next time he should ask for objections before he go there O:-) This week call is canceled. Later, Juan.
Re: [Qemu-devel] [PATCH 5/9] unicore32-softmmu: initialize ucv2 cpu
Am 28.05.2012 11:43, schrieb guanxue...@mprc.pku.edu.cn: Am 25.05.2012 13:29, schrieb Guan Xuetao: Signed-off-by: Guan Xuetao g...@mprc.pku.edu.cn --- target-unicore32/cpu.c | 17 + target-unicore32/cpu.h |2 +- 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/target-unicore32/cpu.c b/target-unicore32/cpu.c index de63f58..62c0a22 100644 --- a/target-unicore32/cpu.c +++ b/target-unicore32/cpu.c @@ -32,13 +32,16 @@ static void unicore_ii_cpu_initfn(Object *obj) UniCore32CPU *cpu = UNICORE32_CPU(obj); CPUUniCore32State *env = cpu-env; -env-cp0.c0_cpuid = 0x40010863; +env-cp0.c0_cpuid = UC32_CPUID_UCV2; Please don't revert this change. I'll send you the patch to drop the CPUID #defines instead. But, the kernel need this CPUID to check whether it is a unicore32 processor, and if check fail, the kernel will halt. I'm not discussing about a guest kernel but about your source change above: The UC32_CPUID_UC32 #define should go away, i.e. please ack (today, if we want it in 1.1) and prepend my patch, and if the value is wrong here it should be changed *here* and not in UC32_CPUID_UCV2. If you're introducing new uses of UC32_CPUID_UCV2 elsewhere (e.g., for register behavior) then that is a design fault and needs to be fixed. Compare the copro series for target-arm, which gets rid of the CPUID-based switches there. Andreas Ok, I see. Thanks for your explanation. I will rebase my repo on qom-cpu-unicore32-v1.2 branch. Guan Xuetao
Re: [Qemu-devel] [PATCH v2] hmp/qxl: info spice: add qxl info
On Tue, May 29, 2012 at 10:38:20AM -0300, Luiz Capitulino wrote: On Tue, 29 May 2012 09:25:40 +0200 Gerd Hoffmann kra...@redhat.com wrote: Hi, How would that work? I have QXLInfo that only makes sense when the information is about a qxl device. Can't have opaque data in a QMP response, so would this be a info display qxl info display cirrus etc. or info qxl? You could show what's available and/or being used currently. I think (Alon, correct me if I'm wrong) the use case is being able to figure whenever the guest drivers are installed and active. Alon, can you confirm this? I'm still not clear on the use-case. The two points I'm wondering are 1. If this is really tied to spice (and thus this info should be part of query-spice) and now 2. if the use case above really pertains to QMP. I've talked to someone in the past about having a way to get information about guest drivers statuses and the conclusion was that the guest-agent agent was better suited for that. The information I'm suggesting to expose is state of the guest as seen from device pov: * guest_bug - this indicates that the qxl device has been instructed to do something illegal that it has ignored, and until a reset from the guest, (QXL_RESET io write), that would presumably indicate a restart of the guest driver, we would like to ignore the guest from now on. This information would be helpful for error report. * mode - this is another indication of presence or lack of a guest driver. This time more straight forward - if a certain IO is issued (QXL_CREATE_PRIMARY) then the driver is in native mode. If another IO (SET_MODE) we are in compat mode. If anything to change back to vga happens (vga io read/write), we are back in vga, and if a DESTROY_SURFACE happens we are in undefined mode. This status would be helpful for error reporting as well. Since both pieces of information already exist in the qemu side, there is no need to introduce an agent to retrieve them. They are easy to retrive with existing management (libvirt/vdsm can do random monitor commands iirc). Alon
Re: [Qemu-devel] [PATCH 8/9] unicore32-softmmu: add config and makefile support
Am 28.05.2012 12:08, schrieb guanxue...@mprc.pku.edu.cn: Am 25.05.2012 13:29, schrieb Guan Xuetao: This patch adds configure and makefile support for unicore32-softmmu. All puv3-soc devices are put into hw/pkunity directory, so this dir will be added when unicore32-softmmu is selected. Signed-off-by: Guan Xuetao g...@mprc.pku.edu.cn --- Makefile.target |5 + arch_init.c |2 ++ arch_init.h |1 + configure |4 default-configs/unicore32-softmmu.mak |4 5 files changed, 16 insertions(+), 0 deletions(-) create mode 100644 default-configs/unicore32-softmmu.mak diff --git a/Makefile.target b/Makefile.target index 1582904..2f850d3 100644 --- a/Makefile.target +++ b/Makefile.target @@ -387,6 +387,11 @@ obj-xtensa-y += core-dc232b.o obj-xtensa-y += core-dc233c.o obj-xtensa-y += core-fsf.o +obj-unicore32-y += uc32_softmmu.o +obj-unicore32-y += pkunity/puv3.o +obj-unicore32-y += pkunity/puv3_intc.o pkunity/puv3_ost.o pkunity/puv3_gpio.o +obj-unicore32-y += pkunity/puv3_pm.o pkunity/puv3_dma.o [snip] You need to put the Makefile/configure changes into the patches that introduce the files please, otherwise they cannot be checked for compiler warnings/errors. I think the patch series is considered as a whole, and only compiling/building one device sim-code doesn't make sense. In fact, when unicore32-softmmu not enabled, the device sim-code isn't going to be compiled at all. Well, we expect each patch in a series to build warning-free for bisectability (even if applied in one PULL), and only compiling things in the final patch does not help. The series should be ordered so that we can either manually enable it with --target-list=unicore32-softmmu until it finally gets enabled by default, or like the openrisc target enables itself by default with some stubs and refines itself over the next patches. The other aspect is to make it easy for humans to review your patches before they can get applied, and personally I find it easier to review small patches. But opinions are divided on that. The criteria for acceptance is not just whether your kernel works in the end [*], my concern is more about how its design aligns with upstream trends like QOM awareness. I see. Thanks. Another thing: It is advisable to place SoC devices (as opposed to the machine) into Makefile.objs (hw-unicore32-y) so that they get compiled into libhw32 rather than into the target's directory. That avoids duplicates when a second endianness or a 64-bit version is introduced. (Yes, some existing targets violate that principle. I am working towards fixing it.) Thanks. That's exactly what I want to know. Andreas [*] It would be helpful if you could share linux-user and softmmu binaries on the Wiki for us to avoid regressions. http://wiki.qemu.org/Testing I'm wandering who maintains Testing, then I could handin unicore32 testcase. Thanks Regards, Guan Xuetao
[Qemu-devel] OpenBIOS for v1.1.0
Hello Blue, commit 7d21dcc84b8c07918124a9c0708694d2fb013f65 Author: Blue Swirl blauwir...@gmail.com Date: Tue May 1 10:56:46 2012 + pc-bios: update OpenBIOS images Update OpenBIOS images to SVN r1056. Signed-off-by: Blue Swirl blauwir...@gmail.com updated the binaries to r1056 but did not update the submodule, so the tarballs are shipping old sources. Do you plan to update to r1057 / r1060? Otherwise the submodule should be set to openbios.git 03922b1ca6a0b54e4a2d29544207fdbb0da33d90 please. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCH for-1.1] qemu-ga: Fix use of environ on Darwin
On Sun, May 27, 2012 at 05:02:20PM +0200, Andreas Färber wrote: Use _NSGetEnviron() helper to access the environment. Signed-off-by: Andreas Färber andreas.faer...@web.de Cc: Charlie Somerville char...@charliesomerville.com --- Michael, can you please append this to your qemu-ga PULL? Thanks, applied to qga tree. I'll send an updated PULL and mark the other one stale. qga/commands-posix.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/qga/commands-posix.c b/qga/commands-posix.c index dab3bf9..4a71c27 100644 --- a/qga/commands-posix.c +++ b/qga/commands-posix.c @@ -22,8 +22,13 @@ #include host-utils.h #ifndef CONFIG_HAS_ENVIRON +#ifdef __APPLE__ +#include crt_externs.h +#define environ (*_NSGetEnviron()) +#else extern char **environ; #endif +#endif #if defined(__linux__) #include mntent.h -- 1.7.5.3
Re: [Qemu-devel] Android Goldfish on QEMU
On 2012-05-28 14:28, Stefan Hajnoczi wrote: On Sat, May 26, 2012 at 2:25 PM, 陳韋任 che...@iis.sinica.edu.tw wrote: On Sat, May 26, 2012 at 02:51:29PM +0200, Andreas Färber wrote: Am 26.05.2012 07:55, schrieb 陳韋任: On Fri, May 25, 2012 at 06:13:25PM -0400, Ira Ray Jenkins wrote: I found a GSOC11 project that attempted to port the Android Goldfish platform to mainline QEMU. Was this project successful, or is this currently being worked on? The author sent the patchset last year [1], but apparently it not get merged into trunk. I don't know why. :) Presumably because the student didn't react to any of the review comments and never sent a fixed v2. It would be great if we can bring it back. ;) Is goldfish still a relevant Android dev platform? In other words - would goldfish be useful to Android developers or just cool for QEMU hackers and old-school Android enthusiasts? It's still the base of the emulator you get with current SDKs. FWIW, latest AOSP (today's git checkout) built for the vbox_x86-eng target runs nicely in QEMU/KVM (using the intermediate disk image android_disk.img). So, adding device models to improve this environment would likely be more helpful to provide a first alternative to the Android emulator. And it's likely a lower hanging fruit. And a much sweeter one (KVM makes it pretty fast :) ). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PULL 1.1] qemu-ga build fix for OpenBSD
On Thu, May 24, 2012 at 01:52:39PM -0500, Michael Roth wrote: The following changes since commit aeb29b6459cb9496b38c820f3faff64cf2369d0d: audio: Always call fini on exit (2012-05-24 19:35:27 +0400) are available in the git repository at: git://github.com/mdroth/qemu.git qga-pull-5-24-12 Luiz Capitulino (2): configure: check if environ is declared qemu-ga: Fix missing environ declaration configure| 19 +++ qga/commands-posix.c |6 +- 2 files changed, 24 insertions(+), 1 deletions(-) Please ignore. There are a couple new patches in the queue that are dependent on patches in this pull. Will send a new pull request.
[Qemu-devel] [PATCH] linux-user: ARM: Ignore immediate value for svc in thumb mode
When running in thumb mode, Linux doesn't evaluate the immediate value
of the svc instruction, but instead just always assumes the syscall number
to be in r7.
This fixes executing go_bootstrap while building go for me.
Signed-off-by: Alexander Graf ag...@suse.de
---
linux-user/main.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/linux-user/main.c b/linux-user/main.c
index 191b750..a7fefe7 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -822,8 +822,7 @@ void cpu_loop(CPUARMState *env)
} else if (n == ARM_NR_semihosting
|| n == ARM_NR_thumb_semihosting) {
env-regs[0] = do_arm_semihosting (env);
-} else if (n == 0 || n = ARM_SYSCALL_BASE
- || (env-thumb n == ARM_THUMB_SYSCALL)) {
+} else if (n == 0 || n = ARM_SYSCALL_BASE || env-thumb) {
/* linux syscall */
if (env-thumb || n == 0) {
n = env-regs[7];
--
1.6.0.2
[Qemu-devel] arm exit code.
In arm user mode, where does qemu exit? Where is last qemu's instruction?
Re: [Qemu-devel] [PATCH 1/3 v9] add-cow file format
+ image_sectors = image_bs-total_sectors;
Please use bdrv_getlength() instead of accessing total_sectors directly.
+ image_drv = bdrv_find_format(raw);
+ ret = bdrv_open(s-image_hd, image_filename, flags, image_drv);
+ if (ret 0) {
+ bdrv_delete(s-image_hd);
+ goto fail;
+ }
+ bs-total_sectors = s-image_hd-total_sectors;
bdrv_getlength()
+static coroutine_fn int add_cow_is_allocated(BlockDriverState *bs,
+ int64_t sector_num, int nb_sectors, int *num_same)
+{
+ int changed;
+ int64_t cluster_num;
+
+ if (nb_sectors == 0) {
+ *num_same = 0;
+ return 0;
+ }
+
+ cluster_num = sector_num / SECTORS_PER_CLUSTER;
+ changed = is_allocated(bs, sector_num);
Do we need to hold the lock before (indirectly) accessing the cache?
+ *num_same =
+ MIN(nb_sectors, (cluster_num + 1) * SECTORS_PER_CLUSTER -
sector_num);
+
+ for (cluster_num = sector_num / SECTORS_PER_CLUSTER + 1;
+ cluster_num = (sector_num + nb_sectors - 1) / SECTORS_PER_CLUSTER;
+ cluster_num++) {
+ if (is_allocated(bs, cluster_num * SECTORS_PER_CLUSTER) != changed) {
+ break;
+ }
+ *num_same = MIN(nb_sectors,
+ (cluster_num + 1) * SECTORS_PER_CLUSTER - sector_num);
+ }
I think this makes sense but it would be easier to use a loop counter
that is in sector units instead of clusters. Then you can calculate
*num_name after the loop simply by subtracting the starting sector_num
from the final cur_sector value. And it saves you from constantly
converting back and forth between clusters and sectors.
+static coroutine_fn int add_cow_co_writev(BlockDriverState *bs,
+ int64_t sector_num, int remaining_sectors, QEMUIOVector *qiov)
+{
+ BDRVAddCowState *s = bs-opaque;
+ int ret = 0, i;
+ QEMUIOVector hd_qiov;
+ uint8_t *table;
+ bool changed = false;
+
+ qemu_co_mutex_lock(s-lock);
+ qemu_iovec_init(hd_qiov, qiov-niov);
+ ret = bdrv_co_writev(s-image_hd,
+ sector_num,
+ remaining_sectors, qiov);
We don't need to lock across all writes.
lock()
if write requires allocation:
...do allocation stuff under lock...
unlock()
write data
Internal data structure (cache, metadata, and copying unmodified
sectors) access needs to be locked during allocating writes. The
guest's data can be written without the lock held.
This means that most writes will only lock for a short time to check
that the clusters are already allocated. Then they will be able to
write in parallel.
If any cluster is not yet allocated then the allocation needs to
happen under lock. This ensures that we don't copy backing file
sectors while processing another write request that touches those
sectors.
+
+ if (ret 0) {
+ goto fail;
+ }
+ /* copy content of unmodified sectors */
+ if (!is_cluster_head(sector_num) !is_allocated(bs, sector_num)) {
+ qemu_co_mutex_unlock(s-lock);
+ ret = copy_sectors(bs, sector_num ~(SECTORS_PER_CLUSTER - 1),
+ sector_num);
As mentioned above, I think we need to lock during copy_sectors() so
that other requests cannot race with this. (The guest's writes must
always take priority over copying unmodified sectors.)
+ qemu_co_mutex_lock(s-lock);
+ if (ret 0) {
+ goto fail;
+ }
+ }
+
+ if (!is_cluster_tail(sector_num + remaining_sectors - 1)
+ !is_allocated(bs, sector_num + remaining_sectors - 1)) {
+ qemu_co_mutex_unlock(s-lock);
+ ret = copy_sectors(bs, sector_num + remaining_sectors,
+ ((sector_num + remaining_sectors) | (SECTORS_PER_CLUSTER - 1)) +
1);
+ qemu_co_mutex_lock(s-lock);
+ if (ret 0) {
+ goto fail;
+ }
+ }
+
+ for (i = sector_num / SECTORS_PER_CLUSTER;
+ i = (sector_num + remaining_sectors - 1) / SECTORS_PER_CLUSTER;
+ i++) {
+ ret = add_cow_cache_get(bs, s-bitmap_cache,
+ i * SECTORS_PER_CLUSTER, (void **)table);
+ if (ret 0) {
+ return 0;
return ret?
+ }
+ if ((table[i / 8] (1 (i % 8))) == 0) {
+ table[i / 8] |= (1 (i % 8));
+ changed = true;
+ add_cow_cache_entry_mark_dirty(s-bitmap_cache, table);
+ }
+
+ }
+ ret = 0;
+fail:
+ if (changed) {
+ ret = add_cow_cache_flush(bs, s-bitmap_cache);
+ }
+ qemu_co_mutex_unlock(s-lock);
+ qemu_iovec_destroy(hd_qiov);
+ return ret;
+}
+
+static int bdrv_add_cow_truncate(BlockDriverState *bs, int64_t size)
+{
+ BDRVAddCowState *s = bs-opaque;
+ int sector_per_byte = SECTORS_PER_CLUSTER * 8;
+ int ret;
+ int64_t old_image_sector = s-image_hd-total_sectors;
+ int64_t bitmap_size =
+ (size / BDRV_SECTOR_SIZE + sector_per_byte - 1) / sector_per_byte;
+
+ ret =
[Qemu-devel] [PATCH 1.1 v2] sheepdog: fix return value of do_load_save_vm_state
bdrv_save_vmstate and bdrv_load_vmstate should return the vmstate size
on success, and -errno on error.
Signed-off-by: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp
---
Changes from v1
- return an error for short reads/writes
- fix a coding style problem
block/sheepdog.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/block/sheepdog.c b/block/sheepdog.c
index 6d52277..f46ca8f 100644
--- a/block/sheepdog.c
+++ b/block/sheepdog.c
@@ -1957,7 +1957,7 @@ static int do_load_save_vmstate(BDRVSheepdogState *s,
uint8_t *data,
int64_t pos, int size, int load)
{
int fd, create;
-int ret = 0;
+int ret = 0, remaining = size;
unsigned int data_len;
uint64_t vmstate_oid;
uint32_t vdi_index;
@@ -1968,11 +1968,11 @@ static int do_load_save_vmstate(BDRVSheepdogState *s,
uint8_t *data,
return fd;
}
-while (size) {
+while (remaining) {
vdi_index = pos / SD_DATA_OBJ_SIZE;
offset = pos % SD_DATA_OBJ_SIZE;
-data_len = MIN(size, SD_DATA_OBJ_SIZE);
+data_len = MIN(remaining, SD_DATA_OBJ_SIZE);
vmstate_oid = vid_to_vmstate_oid(s-inode.vdi_id, vdi_index);
@@ -1993,9 +1993,9 @@ static int do_load_save_vmstate(BDRVSheepdogState *s,
uint8_t *data,
}
pos += data_len;
-size -= data_len;
-ret += data_len;
+remaining -= data_len;
}
+ret = size;
cleanup:
closesocket(fd);
return ret;
--
1.7.2.5
Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support for replication]
Hi, On 05/24/2012 04:19 PM, Paolo Bonzini wrote: Here is how the bitmaps are handled when doing I/O on the source: - after writing to the source: - clear bit in the volatile in-flight bitmap - set bit in the persistent dirty bitmap - after flushing the source: - msync the persistent bitmap to disk Here is how the bitmaps are handled in the drive-mirror coroutine: - before reading from the source: - set bit in the volatile in-flight bitmap - after writing to the target: - if the dirty count will become zero, flush the target - if the bit is still set in the in-flight bitmap, clear bit in the persistent dirty bitmap - clear bit in the volatile in-flight bitmap I have a few questions, apologies if some of these are obvious.. I assume the target can be any QEmu block driver including e.g. NBD? A networked block driver would be required for a continuous replication solution. Does the drive-mirror coroutine send the writes to the target in the same order as they are sent to the source? I assume so. Does the drive-mirror coroutine require that writes are acknowledged? I'd assume so, as you mention that the bit from the persistent bitmap is cleared after a write, so you'd need to know the write arrived otherwise you cannot safely clear the bit. If the two above are true (sending in-order, and require acknowledgment of writes by the target), then I assume there is a need to keep an in-memory list with the IOs that still need to be sent to the target? That list could get too large if i.e. the target cannot keep up or becomes unavailable. When this happens, the dirty bitmap is needed to re-establish synchronized state again between the two images. For this re-sync, i think there will be two phases. The first phase would send blocks marked as dirty by the bitmap. I assume these would be sent in arbitrary order, not the order in which they were sent to the source, right? After the copy phase is done, in order to avoid race conditions, the bitmap should be reset and mirroring should start directly and atomically. Is that currently handed by your design? Also probably the target would need some kind of signal that the copy ended and that we are now mirroring because this is when writes are in-order again, and therefore only in this phase the solution can provide crash consistent protection. In the copy phase no crash consistency can be provided if i am not mistaken. Finally, again if i am not mistaken, I think that the scenario where synchronization is lost with the target is exactly the same as when you need to do an initial copy, expect that in the latter case all bits in the bitmap are set, right? Regards, Geert
[Qemu-devel] [PATCH 1.1] sheepdog: add coroutine_fn markers to coroutine functions
Signed-off-by: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp
---
block/sheepdog.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/block/sheepdog.c b/block/sheepdog.c
index f46ca8f..046f52a 100644
--- a/block/sheepdog.c
+++ b/block/sheepdog.c
@@ -522,8 +522,8 @@ static int send_req(int sockfd, SheepdogReq *hdr, void
*data,
return ret;
}
-static int send_co_req(int sockfd, SheepdogReq *hdr, void *data,
- unsigned int *wlen)
+static coroutine_fn int send_co_req(int sockfd, SheepdogReq *hdr, void *data,
+ unsigned int *wlen)
{
int ret;
@@ -540,6 +540,7 @@ static int send_co_req(int sockfd, SheepdogReq *hdr, void
*data,
return ret;
}
+
static int do_req(int sockfd, SheepdogReq *hdr, void *data,
unsigned int *wlen, unsigned int *rlen)
{
@@ -576,8 +577,8 @@ out:
return ret;
}
-static int do_co_req(int sockfd, SheepdogReq *hdr, void *data,
- unsigned int *wlen, unsigned int *rlen)
+static coroutine_fn int do_co_req(int sockfd, SheepdogReq *hdr, void *data,
+ unsigned int *wlen, unsigned int *rlen)
{
int ret;
--
1.7.2.5
Re: [Qemu-devel] [PATCH 1.1] sheepdog: add coroutine_fn markers to coroutine functions
Am 29.05.2012 18:22, schrieb MORITA Kazutaka:
Signed-off-by: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp
Patch is tab-damaged.
Andreas
---
block/sheepdog.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/block/sheepdog.c b/block/sheepdog.c
index f46ca8f..046f52a 100644
--- a/block/sheepdog.c
+++ b/block/sheepdog.c
@@ -522,8 +522,8 @@ static int send_req(int sockfd, SheepdogReq *hdr, void
*data,
return ret;
}
-static int send_co_req(int sockfd, SheepdogReq *hdr, void *data,
- unsigned int *wlen)
+static coroutine_fn int send_co_req(int sockfd, SheepdogReq *hdr, void *data,
+ unsigned int *wlen)
{
int ret;
@@ -540,6 +540,7 @@ static int send_co_req(int sockfd, SheepdogReq *hdr, void
*data,
return ret;
}
+
static int do_req(int sockfd, SheepdogReq *hdr, void *data,
unsigned int *wlen, unsigned int *rlen)
{
@@ -576,8 +577,8 @@ out:
return ret;
}
-static int do_co_req(int sockfd, SheepdogReq *hdr, void *data,
- unsigned int *wlen, unsigned int *rlen)
+static coroutine_fn int do_co_req(int sockfd, SheepdogReq *hdr, void *data,
+ unsigned int *wlen, unsigned int *rlen)
{
int ret;
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [Bug 998435] Re: qemu-kvm-spice doesn't support spice/qxl installs
Confirmed for winXP guest: qemu-kvm-spice doesn't support spice/qxl (bugs: 100%CPU, vdservice doesnt start, no guest screen at boot) Boris's recipe works ( http://bderzhavets.wordpress.com/2012/05/22/set- up-qemu-kvm-1-0noroms-as-spice-enabled-qemu-server/) NB: used guest winXP drivers from spice-guest-tools-0.1.exe (http ://spice-space.org/download/binaries/) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/998435 Title: qemu-kvm-spice doesn't support spice/qxl installs Status in QEMU: Confirmed Status in “qemu-kvm-spice” package in Ubuntu: Confirmed Bug description: Been setup as follows :- boris@boris-P5Q-E:~$ dpkg -l | grep spice ii gir1.2-spice-client-glib-2.0 0.9-0ubuntu1 GObject for communicating with Spice servers (GObject-Introspection) ii gir1.2-spice-client-gtk-2.00.9-0ubuntu1 GTK2 widget for SPICE clients (GObject-Introspection) ii gir1.2-spice-client-gtk-3.00.9-0ubuntu1 GTK3 widget for SPICE clients (GObject-Introspection) ii libspice-client-glib-2.0-1 0.9-0ubuntu1 GObject for communicating with Spice servers (runtime library) ii libspice-client-glib-2.0-dev 0.9-0ubuntu1 GObject for communicating with Spice servers (development files) ii libspice-client-gtk-2.0-1 0.9-0ubuntu1 GTK2 widget for SPICE clients (runtime library) ii libspice-client-gtk-2.0-dev0.9-0ubuntu1 GTK2 widget for SPICE clients (development files) ii libspice-client-gtk-3.0-1 0.9-0ubuntu1 GTK3 widget for SPICE clients (runtime library) ii libspice-client-gtk-3.0-dev0.9-0ubuntu1 GTK3 widget for SPICE clients (development files) ii libspice-protocol-dev 0.10.1-1 SPICE protocol headers ii libspice-server-dev0.10.0-1 Header files and development documentation for spice-server ii libspice-server1 0.10.0-1 Implements the server side of the SPICE protocol ii python-spice-client-gtk0.9-0ubuntu1 GTK2 widget for SPICE clients (Python binding) ii qemu-kvm-spice 1.0.50-2012.03-0ubuntu2 Full virtualization on amd64 hardware Spice/QXL install doesn't work on Ubuntu 12.04 . View also https://bugs.launchpad.net/ubuntu/+source/seabios/+bug/823494 It doesn't look like duplicate of bug mentioned above. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/998435/+subscriptions
Re: [Qemu-devel] [PATCH v2] hmp/qxl: info spice: add qxl info
On Tue, 29 May 2012 17:51:50 +0300 Alon Levy al...@redhat.com wrote: On Tue, May 29, 2012 at 10:38:20AM -0300, Luiz Capitulino wrote: On Tue, 29 May 2012 09:25:40 +0200 Gerd Hoffmann kra...@redhat.com wrote: Hi, How would that work? I have QXLInfo that only makes sense when the information is about a qxl device. Can't have opaque data in a QMP response, so would this be a info display qxl info display cirrus etc. or info qxl? You could show what's available and/or being used currently. I think (Alon, correct me if I'm wrong) the use case is being able to figure whenever the guest drivers are installed and active. Alon, can you confirm this? I'm still not clear on the use-case. The two points I'm wondering are 1. If this is really tied to spice (and thus this info should be part of query-spice) and now 2. if the use case above really pertains to QMP. I've talked to someone in the past about having a way to get information about guest drivers statuses and the conclusion was that the guest-agent agent was better suited for that. The information I'm suggesting to expose is state of the guest as seen from device pov: Do you expect mngt apps to use that info or is it just for debugging? If it's the latter, then maybe we could add query-qxl as gen=no and declare it unstable. * guest_bug - this indicates that the qxl device has been instructed to do something illegal that it has ignored, and until a reset from the guest, (QXL_RESET io write), that would presumably indicate a restart of the guest driver, we would like to ignore the guest from now on. This information would be helpful for error report. * mode - this is another indication of presence or lack of a guest driver. This time more straight forward - if a certain IO is issued (QXL_CREATE_PRIMARY) then the driver is in native mode. If another IO (SET_MODE) we are in compat mode. If anything to change back to vga happens (vga io read/write), we are back in vga, and if a DESTROY_SURFACE happens we are in undefined mode. This status would be helpful for error reporting as well. What kind of error report? Since both pieces of information already exist in the qemu side, there is no need to introduce an agent to retrieve them. They are easy to retrive with existing management (libvirt/vdsm can do random monitor commands iirc). Alon
Re: [Qemu-devel] [PATCH 1.1?] qemu_rearm_alarm_timer: do not call rearm if the next deadline is INT64_MAX
Am 29.05.2012 15:35, schrieb Stefano Stabellini:
qemu_rearm_alarm_timer partially duplicates the code in
qemu_next_alarm_deadline to figure out if it needs to rearm the timer.
If it calls qemu_next_alarm_deadline, it always rearms the timer even if
the next deadline is INT64_MAX.
This patch simplifies the behavior of qemu_rearm_alarm_timer and removes
the duplicated code, always calling qemu_next_alarm_deadline and only
rearming the timer if the deadline is less than INT64_MAX.
Signed-off-by: Stefano Stabellinistefano.stabell...@eu.citrix.com
diff --git a/qemu-timer.c b/qemu-timer.c
index de98977..81ff824 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -112,14 +112,10 @@ static int64_t qemu_next_alarm_deadline(void)
static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t)
{
-int64_t nearest_delta_ns;
-if (!rt_clock-active_timers
-!vm_clock-active_timers
-!host_clock-active_timers) {
-return;
+int64_t nearest_delta_ns = qemu_next_alarm_deadline();
+if (nearest_delta_ns INT64_MAX) {
+t-rearm(t, nearest_delta_ns);
}
-nearest_delta_ns = qemu_next_alarm_deadline();
-t-rearm(t, nearest_delta_ns);
}
/* TODO: MIN_TIMER_REARM_NS should be optimized */
Reviewed-by: Stefan Weil s...@weilnetz.de
This patch clearly improves the current code and fixes
an abort on Darwin (reported by Andreas Färber) and maybe
other hosts. Therefore I changed the subject and suggest
to consider this patch for QEMU 1.1.
There remain issues which can be fixed after 1.1:
nearest_delta_ns also gets negative values (rtdelta 0,
maybe because the expiration time already expired).
I did not check whether all different timers handle
a negative time gracefully.
nearest_delta_ns should also be limited to INT32_MAX
seconds, because some timers assign the seconds
to a long (see setitimer) or UINT value. On 32 bit
Linux and on all variants of Windows, long is less
or equal INT32_MAX. If we limit nearest_delta_ns
to 100 seconds (or some other limit which allows
ULONG milliseconds), we could further simplify the code
because most timers would no longer have to test the
upper limit.
Regards,
Stefan W.
Re: [Qemu-devel] [PATCH 1.1?] qemu_rearm_alarm_timer: do not call rearm if the next deadline is INT64_MAX
On Tue, 29 May 2012, Stefan Weil wrote:
Am 29.05.2012 15:35, schrieb Stefano Stabellini:
qemu_rearm_alarm_timer partially duplicates the code in
qemu_next_alarm_deadline to figure out if it needs to rearm the timer.
If it calls qemu_next_alarm_deadline, it always rearms the timer even if
the next deadline is INT64_MAX.
This patch simplifies the behavior of qemu_rearm_alarm_timer and removes
the duplicated code, always calling qemu_next_alarm_deadline and only
rearming the timer if the deadline is less than INT64_MAX.
Signed-off-by: Stefano Stabellinistefano.stabell...@eu.citrix.com
diff --git a/qemu-timer.c b/qemu-timer.c
index de98977..81ff824 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -112,14 +112,10 @@ static int64_t qemu_next_alarm_deadline(void)
static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t)
{
-int64_t nearest_delta_ns;
-if (!rt_clock-active_timers
-!vm_clock-active_timers
-!host_clock-active_timers) {
-return;
+int64_t nearest_delta_ns = qemu_next_alarm_deadline();
+if (nearest_delta_ns INT64_MAX) {
+t-rearm(t, nearest_delta_ns);
}
-nearest_delta_ns = qemu_next_alarm_deadline();
-t-rearm(t, nearest_delta_ns);
}
/* TODO: MIN_TIMER_REARM_NS should be optimized */
Reviewed-by: Stefan Weil s...@weilnetz.de
thanks
This patch clearly improves the current code and fixes
an abort on Darwin (reported by Andreas Färber) and maybe
other hosts. Therefore I changed the subject and suggest
to consider this patch for QEMU 1.1.
There remain issues which can be fixed after 1.1:
nearest_delta_ns also gets negative values (rtdelta 0,
maybe because the expiration time already expired).
I did not check whether all different timers handle
a negative time gracefully.
nearest_delta_ns should also be limited to INT32_MAX
seconds, because some timers assign the seconds
to a long (see setitimer) or UINT value. On 32 bit
Linux and on all variants of Windows, long is less
or equal INT32_MAX. If we limit nearest_delta_ns
to 100 seconds (or some other limit which allows
ULONG milliseconds), we could further simplify the code
because most timers would no longer have to test the
upper limit.
If that's the issue we could limit nearest_delta_ns to LONG_MAX.
However I got the feeling that Darwin has an undocumented limit
for tv_sec, lower than INT32_MAX.
Re: [Qemu-devel] [PATCH 1.1?] qemu_rearm_alarm_timer: do not call rearm if the next deadline is INT64_MAX
Am 29.05.2012 19:23, schrieb Stefano Stabellini:
On Tue, 29 May 2012, Stefan Weil wrote:
Am 29.05.2012 15:35, schrieb Stefano Stabellini:
qemu_rearm_alarm_timer partially duplicates the code in
qemu_next_alarm_deadline to figure out if it needs to rearm the timer.
If it calls qemu_next_alarm_deadline, it always rearms the timer even if
the next deadline is INT64_MAX.
This patch simplifies the behavior of qemu_rearm_alarm_timer and removes
the duplicated code, always calling qemu_next_alarm_deadline and only
rearming the timer if the deadline is less than INT64_MAX.
Signed-off-by: Stefano Stabellinistefano.stabell...@eu.citrix.com
diff --git a/qemu-timer.c b/qemu-timer.c
index de98977..81ff824 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -112,14 +112,10 @@ static int64_t qemu_next_alarm_deadline(void)
static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t)
{
-int64_t nearest_delta_ns;
-if (!rt_clock-active_timers
-!vm_clock-active_timers
-!host_clock-active_timers) {
-return;
+int64_t nearest_delta_ns = qemu_next_alarm_deadline();
+if (nearest_delta_ns INT64_MAX) {
+t-rearm(t, nearest_delta_ns);
}
-nearest_delta_ns = qemu_next_alarm_deadline();
-t-rearm(t, nearest_delta_ns);
}
/* TODO: MIN_TIMER_REARM_NS should be optimized */
Reviewed-by: Stefan Weils...@weilnetz.de
thanks
This patch clearly improves the current code and fixes
an abort on Darwin (reported by Andreas Färber) and maybe
other hosts. Therefore I changed the subject and suggest
to consider this patch for QEMU 1.1.
There remain issues which can be fixed after 1.1:
nearest_delta_ns also gets negative values (rtdelta 0,
maybe because the expiration time already expired).
I did not check whether all different timers handle
a negative time gracefully.
nearest_delta_ns should also be limited to INT32_MAX
seconds, because some timers assign the seconds
to a long (see setitimer) or UINT value. On 32 bit
Linux and on all variants of Windows, long is less
or equal INT32_MAX. If we limit nearest_delta_ns
to 100 seconds (or some other limit which allows
ULONG milliseconds), we could further simplify the code
because most timers would no longer have to test the
upper limit.
If that's the issue we could limit nearest_delta_ns to LONG_MAX.
However I got the feeling that Darwin has an undocumented limit
for tv_sec, lower than INT32_MAX.
Yes, we could set the upper limit to LONG_MAX seconds for some
timers, but I did not want to have a dependency of the
upper limit on sizeof(long). The function win32_rearm_timer
only allows 4294967 seconds. Is there any reason why we
should allow timers which expire after more than 11 days
(100 seconds are about 11 days)? If there is none,
100 seconds would be a good upper limit for most timers
(maybe also for Darwin). mm_rearm_timer is the only timer
which then still needs its own upper limit.
Regards,
Stefan W.
Re: [Qemu-devel] [PATCH 1.1?] qemu_rearm_alarm_timer: do not call rearm if the next deadline is INT64_MAX
On Tue, 29 May 2012, Stefan Weil wrote: Yes, we could set the upper limit to LONG_MAX seconds for some timers, but I did not want to have a dependency of the upper limit on sizeof(long). The function win32_rearm_timer only allows 4294967 seconds. Is there any reason why we should allow timers which expire after more than 11 days (100 seconds are about 11 days)? If there is none, 100 seconds would be a good upper limit for most timers (maybe also for Darwin). mm_rearm_timer is the only timer which then still needs its own upper limit. If 100 works for Darwin, then I think it is a good idea.
Re: [Qemu-devel] Keysymbol interpretation missing in QEMU's VNC server?
Hi Fabian, Fabian Holler wrote: Hello Erik, I just want to route all keypresses to the guest without interfering with the native QEMU key layout. Is that possible? Yes, if you start kvm without the -k option and use a linux VNC client that supports RFB extended key events (eg gtk-vnc, tigervnc). With the extension the keyboard layout only depends on the OS settings in the VM. I tried tigervnc and tightvnc for Windows - which both advertise the feature on their website - same issues as I have with UltraVNC - no AltGr combinations and no Umlaute available. I need a Windows VNC client that can handle that - do you know a vnc client that can do that? How does the QEMU VNC server receive the key presses? In the same manner as the direct way does by getting scancodes or via real characters? http://berrange.com/posts/2010/07/04/more-than-you-or-i-ever-wanted-to-know-about-virtual-keyboard-handling/ http://berrange.com/posts/2010/07/04/a-summary-of-scan-code-key-codes-sets-used-in-the-pc-virtualization-stack/ Really interesting - Linux works, Windows doesn't :-( Also when using a Linux remote X-Windows (via SSH tunnel) on my Windows PC it works - only the plain Windows VNC client corrupts the keypresses regards Fabian Best regards, Erik
Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support for replication]
Il 29/05/2012 13:57, Geert Jansen ha scritto: I assume the target can be any QEmu block driver including e.g. NBD? A networked block driver would be required for a continuous replication solution. Yes. Does the drive-mirror coroutine send the writes to the target in the same order as they are sent to the source? I assume so. No, it doesn't. It's asynchronous; for continuous replication, the target knows that it has a consistent view whenever it sees a flush on the NBD stream. Flushing the target is needed anyway before writing the dirty bitmap, so the target might as well exploit them to get information about the state of the source. The target _must_ flush to disk when it receives a flush commands, not matter how close they are. It _may_ choose to snapshot the disk, for example establishing one new snapshot every 5 seconds. A synchronous implementation is not forbidden by the spec (by design), but at the moment it's a bit more complex to implement because, as you mention, it requires buffering the I/O data on the host. Does the drive-mirror coroutine require that writes are acknowledged? I'd assume so, as you mention that the bit from the persistent bitmap is cleared after a write, so you'd need to know the write arrived otherwise you cannot safely clear the bit. Yes, the drive-mirror coroutine will not go on to the next write until the previous one is acked. For this re-sync, i think there will be two phases. The first phase would send blocks marked as dirty by the bitmap. I assume these would be sent in arbitrary order, not the order in which they were sent to the source, right? After the copy phase is done, in order to avoid race conditions, the bitmap should be reset and mirroring should start directly and atomically. Is that currently handed by your design? Yes, this is already all correct. Also probably the target would need some kind of signal that the copy ended and that we are now mirroring because this is when writes are in-order again, and therefore only in this phase the solution can provide crash consistent protection. In the copy phase no crash consistency can be provided if i am not mistaken. The copy phase will not have flushes (they are kind of useless). Finally, again if i am not mistaken, I think that the scenario where synchronization is lost with the target is exactly the same as when you need to do an initial copy, expect that in the latter case all bits in the bitmap are set, right? Yes. Paolo
Re: [Qemu-devel] [PATCH 1.1?] qemu_rearm_alarm_timer: do not call rearm if the next deadline is INT64_MAX
Il 29/05/2012 19:09, Stefan Weil ha scritto:
Am 29.05.2012 15:35, schrieb Stefano Stabellini:
qemu_rearm_alarm_timer partially duplicates the code in
qemu_next_alarm_deadline to figure out if it needs to rearm the timer.
If it calls qemu_next_alarm_deadline, it always rearms the timer even if
the next deadline is INT64_MAX.
This patch simplifies the behavior of qemu_rearm_alarm_timer and removes
the duplicated code, always calling qemu_next_alarm_deadline and only
rearming the timer if the deadline is less than INT64_MAX.
Signed-off-by: Stefano Stabellinistefano.stabell...@eu.citrix.com
diff --git a/qemu-timer.c b/qemu-timer.c
index de98977..81ff824 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -112,14 +112,10 @@ static int64_t qemu_next_alarm_deadline(void)
static void qemu_rearm_alarm_timer(struct qemu_alarm_timer *t)
{
-int64_t nearest_delta_ns;
-if (!rt_clock-active_timers
-!vm_clock-active_timers
-!host_clock-active_timers) {
-return;
+int64_t nearest_delta_ns = qemu_next_alarm_deadline();
+if (nearest_delta_ns INT64_MAX) {
+t-rearm(t, nearest_delta_ns);
}
-nearest_delta_ns = qemu_next_alarm_deadline();
-t-rearm(t, nearest_delta_ns);
}
/* TODO: MIN_TIMER_REARM_NS should be optimized */
Reviewed-by: Stefan Weil s...@weilnetz.de
This patch clearly improves the current code and fixes
an abort on Darwin (reported by Andreas Färber) and maybe
other hosts. Therefore I changed the subject and suggest
to consider this patch for QEMU 1.1.
Only with a Tested-by from Andreas.
Paolo
[Qemu-devel] [PATCH qom-next v3 0/12] target-i386: re-factor CPU creation/initialization to QOM
Moving code related to CPU creation and initialization internal parts from board level into apic and cpu objects will allow X86CPU to better model QOM object life-cycle. It will allow to create X86CPU as any other object by creating it with object_new() then setting properties and then calling x86_cpu_realize() to make it running. Later x86_cpu_realize() should become realize property. git tree for testing: https://github.com/imammedo/qemu/tree/x86-cpu-realize-v3 Compile Run tested: target-i386: tcg and kvm mode i386-linux-user: running of /bin/ls and /usr/bin/make on qemu tree (12): store prev_debug_excp_handler globaly and not per target target-xtensa: use global prev_debug_excp_handler instead of local one target-i386: use global prev_debug_excp_handler instead of local one target-i386: move tcg initialization into x86_cpu_initfn() pc: Add CPU as /machine/cpu[n] apic: Replace cpu_env pointer by X86CPU link taken from Andreas' QOM CPUState part 4 series, to avoid conflict with reintroducing set_ptr replaced by linkX86CPU in this patches target-i386: move cpu halted decision into x86_cpu_reset target-i386: introduce cpu-model property for x86_cpu target-i386: make cpu a child of /machine right after it's created pc: Enable MSI support at APIC level http://thread.gmane.org/gmane.comp.emulators.kvm.devel/91186 included here to prevent confilict since qom-next doesn't have it but next patch is depending on it. target-i386: initialize APIC at CPU level target-i386: move reset callback to cpu.c and call cpu_reset() in x86_cpu_realize() cpu-defs.h |2 +- cpu-exec.c |7 +-- exec-all.h |3 +- hw/apic.c | 37 +-- hw/apic.h |2 +- hw/apic_common.c | 30 +--- hw/apic_internal.h |2 +- hw/kvm/apic.c |9 ++-- hw/pc.c| 92 +++--- hw/xen.h | 10 hw/xen_apic.c |5 ++ target-i386/cpu.c | 117 target-i386/cpu.h |2 + target-i386/helper.c | 41 ++--- target-i386/kvm.c |5 +- target-xtensa/helper.c |5 +--
[Qemu-devel] [PATCH qom-next 11/12] target-i386: initialize APIC at CPU level
(L)APIC is a part of cpu [1] so move APIC initialization inside of
x86_cpu object. Since cpu_model and override flags currently specify
whether APIC should be created or not, APIC creation is moved into
cpu_model property setter. And APIC initialization is moved into
x86_cpu_apic_init() which is called from x86_cpu_realize().
[1] - all x86 cpus have integrated APIC if we overlook existence of i486,
and it's more convenient to model after majority of them.
v2:
* init APIC mapping at cpu level, due to Peter's objection to putting
it into APIC's initfn and Jan's suggestion to do it inside cpu.
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
hw/pc.c | 44 -
target-i386/cpu.c | 62 +
2 files changed, 62 insertions(+), 44 deletions(-)
diff --git a/hw/pc.c b/hw/pc.c
index d178801..986f119 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -42,7 +42,6 @@
#include sysbus.h
#include sysemu.h
#include kvm.h
-#include xen.h
#include blockdev.h
#include ui/qemu-spice.h
#include memory.h
@@ -70,8 +69,6 @@
#define FW_CFG_E820_TABLE (FW_CFG_ARCH_LOCAL + 3)
#define FW_CFG_HPET (FW_CFG_ARCH_LOCAL + 4)
-#define MSI_ADDR_BASE 0xfee0
-
#define E820_NR_ENTRIES16
struct e820_entry {
@@ -879,42 +876,6 @@ DeviceState *cpu_get_current_apic(void)
}
}
-static DeviceState *apic_init(void *env, uint8_t apic_id)
-{
-DeviceState *dev;
-Error *error = NULL;
-static int apic_mapped;
-
-if (kvm_irqchip_in_kernel()) {
-dev = qdev_create(NULL, kvm-apic);
-} else if (xen_enabled()) {
-dev = qdev_create(NULL, xen-apic);
-} else {
-dev = qdev_create(NULL, apic);
-}
-
-qdev_prop_set_uint8(dev, id, apic_id);
-object_property_set_link(OBJECT(dev), OBJECT(ENV_GET_CPU(env)), cpu,
- error);
-if (error_is_set(error)) {
-qerror_report_err(error);
-error_free(error);
-exit(1);
-}
-qdev_init_nofail(dev);
-
-/* XXX: mapping more APICs at the same memory location */
-if (apic_mapped == 0) {
-/* NOTE: the APIC is directly connected to the CPU - it is not
- on the global memory bus. */
-/* XXX: what if the base changes? */
-sysbus_mmio_map(sysbus_from_qdev(dev), 0, MSI_ADDR_BASE);
-apic_mapped = 1;
-}
-
-return dev;
-}
-
void pc_acpi_smi_interrupt(void *opaque, int irq, int level)
{
CPUX86State *s = opaque;
@@ -933,17 +894,12 @@ static void pc_cpu_reset(void *opaque)
static X86CPU *pc_new_cpu(const char *cpu_model)
{
X86CPU *cpu;
-CPUX86State *env;
cpu = cpu_x86_init(cpu_model);
if (cpu == NULL) {
exit(1);
}
-env = cpu-env;
-if ((env-cpuid_features CPUID_APIC) || smp_cpus 1) {
-env-apic_state = apic_init(env, env-cpuid_apic_id);
-}
qemu_register_reset(pc_cpu_reset, cpu);
pc_cpu_reset(cpu);
return cpu;
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 2610d96..b649904 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -23,6 +23,7 @@
#include cpu.h
#include kvm.h
+#include hw/xen.h
#include qemu-option.h
#include qemu-config.h
@@ -31,6 +32,11 @@
#include hyperv.h
+#include sysemu.h
+#ifndef CONFIG_USER_ONLY
+#include hw/sysbus.h
+#endif
+
/* feature flags taken from Intel Processor Identification and the CPUID
* Instruction and AMD's CPUID Specification. In cases of disagreement
* between feature naming conventions, aliases may be added.
@@ -1749,13 +1755,69 @@ static void x86_set_cpu_model(Object *obj, const char
*value, Error **errp)
if (cpu_x86_register(cpu, env-cpu_model_str) 0) {
fprintf(stderr, Unable to find x86 CPU definition\n);
error_set(errp, QERR_INVALID_PARAMETER_COMBINATION);
+return;
+}
+
+#ifndef CONFIG_USER_ONLY
+if (((env-cpuid_features CPUID_APIC) || smp_cpus 1)) {
+if (kvm_irqchip_in_kernel()) {
+env-apic_state = qdev_create(NULL, kvm-apic);
+} else if (xen_enabled()) {
+env-apic_state = qdev_create(NULL, xen-apic);
+} else {
+env-apic_state = qdev_create(NULL, apic);
+}
+object_property_add_child(OBJECT(cpu), apic,
+OBJECT(env-apic_state), NULL);
+
+qdev_prop_set_uint8(env-apic_state, id, env-cpuid_apic_id);
+object_property_set_link(OBJECT(env-apic_state), OBJECT(cpu), cpu,
+ errp);
+if (error_is_set(errp)) {
+return;
+}
+}
+#endif
+}
+
+#ifndef CONFIG_USER_ONLY
+#define MSI_ADDR_BASE 0xfee0
+
+static void x86_cpu_apic_init(X86CPU *cpu, Error **errp)
+{
+static int apic_mapped;
+CPUX86State *env = cpu-env;
+
+if (env-apic_state == NULL) {
+return;
+}
+
+if (qdev_init(env-apic_state)) {
+error_set(errp, QERR_DEVICE_INIT_FAILED,
+
[Qemu-devel] [PATCH qom-next 08/12] target-i386: introduce cpu-model property for x86_cpu
it's probably intermidiate step till cpu modeled as
sub-classes. After then we probably could drop it.
However it still could be used for overiding default
cpu subclasses definition, and probably renamed to
something like 'features'.
v2:
- remove accidential tcg_* init code move
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
cpu-defs.h |2 +-
hw/pc.c | 10 --
target-i386/cpu.c| 24
target-i386/helper.c | 17 -
4 files changed, 37 insertions(+), 16 deletions(-)
diff --git a/cpu-defs.h b/cpu-defs.h
index f49e950..8f4623c 100644
--- a/cpu-defs.h
+++ b/cpu-defs.h
@@ -221,7 +221,7 @@ typedef struct CPUWatchpoint {
struct QemuCond *halt_cond; \
int thread_kicked; \
struct qemu_work_item *queued_work_first, *queued_work_last;\
-const char *cpu_model_str; \
+char *cpu_model_str;\
struct KVMState *kvm_state; \
struct kvm_run *kvm_run;\
int kvm_fd; \
diff --git a/hw/pc.c b/hw/pc.c
index 2f681db..4a687d6 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -948,7 +948,6 @@ static X86CPU *pc_new_cpu(const char *cpu_model)
cpu = cpu_x86_init(cpu_model);
if (cpu == NULL) {
-fprintf(stderr, Unable to find x86 CPU definition\n);
exit(1);
}
env = cpu-env;
@@ -974,15 +973,6 @@ void pc_cpus_init(const char *cpu_model)
{
int i;
-/* init CPUs */
-if (cpu_model == NULL) {
-#ifdef TARGET_X86_64
-cpu_model = qemu64;
-#else
-cpu_model = qemu32;
-#endif
-}
-
for(i = 0; i smp_cpus; i++) {
pc_new_cpu(cpu_model);
}
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index f029f2a..2610d96 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1731,6 +1731,27 @@ static void mce_init(X86CPU *cpu)
}
}
+static char *x86_get_cpu_model(Object *obj, Error **errp)
+{
+X86CPU *cpu = X86_CPU(obj);
+CPUX86State *env = cpu-env;
+return g_strdup(env-cpu_model_str);
+}
+
+static void x86_set_cpu_model(Object *obj, const char *value, Error **errp)
+{
+X86CPU *cpu = X86_CPU(obj);
+CPUX86State *env = cpu-env;
+
+g_free((gpointer)env-cpu_model_str);
+env-cpu_model_str = g_strdup(value);
+
+if (cpu_x86_register(cpu, env-cpu_model_str) 0) {
+fprintf(stderr, Unable to find x86 CPU definition\n);
+error_set(errp, QERR_INVALID_PARAMETER_COMBINATION);
+}
+}
+
void x86_cpu_realize(Object *obj, Error **errp)
{
X86CPU *cpu = X86_CPU(obj);
@@ -1772,6 +1793,9 @@ static void x86_cpu_initfn(Object *obj)
x86_cpuid_get_tsc_freq,
x86_cpuid_set_tsc_freq, NULL, NULL, NULL);
+object_property_add_str(obj, cpu-model,
+x86_get_cpu_model, x86_set_cpu_model, NULL);
+
env-cpuid_apic_id = env-cpu_index;
/* init various static tables used in TCG mode */
diff --git a/target-i386/helper.c b/target-i386/helper.c
index fd20fd4..748eee8 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -1152,14 +1152,21 @@ int cpu_x86_get_descr_debug(CPUX86State *env, unsigned
int selector,
X86CPU *cpu_x86_init(const char *cpu_model)
{
X86CPU *cpu;
-CPUX86State *env;
+Error *errp = NULL;
cpu = X86_CPU(object_new(TYPE_X86_CPU));
-env = cpu-env;
-env-cpu_model_str = cpu_model;
-if (cpu_x86_register(cpu, cpu_model) 0) {
-object_delete(OBJECT(cpu));
+if (cpu_model) {
+object_property_set_str(OBJECT(cpu), cpu_model, cpu-model, errp);
+} else {
+#ifdef TARGET_X86_64
+object_property_set_str(OBJECT(cpu), qemu64, cpu-model, errp);
+#else
+object_property_set_str(OBJECT(cpu), qemu32, cpu-model, errp);
+#endif
+}
+if (errp) {
+ object_delete(OBJECT(cpu));
return NULL;
}
--
1.7.7.6
[Qemu-devel] [PATCH qom-next 04/12] target-i386: move tcg initialization into x86_cpu_initfn()
In order to make cpu object not depended on external ad-hoc
initialization routines, move tcg initialization from cpu_x86_init
inside cpu object x86_cpu_initfn().
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
target-i386/cpu.c| 10 ++
target-i386/cpu.h|2 ++
target-i386/helper.c | 11 +--
3 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 89b4ac7..41a0436 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1734,6 +1734,7 @@ static void x86_cpu_initfn(Object *obj)
{
X86CPU *cpu = X86_CPU(obj);
CPUX86State *env = cpu-env;
+static int inited;
cpu_exec_init(env);
@@ -1763,6 +1764,15 @@ static void x86_cpu_initfn(Object *obj)
x86_cpuid_set_tsc_freq, NULL, NULL, NULL);
env-cpuid_apic_id = env-cpu_index;
+
+/* init various static tables used in TCG mode */
+if (tcg_enabled() !inited) {
+inited = 1;
+optimize_flags_init();
+#ifndef CONFIG_USER_ONLY
+cpu_set_debug_excp_handler(breakpoint_handler);
+#endif
+}
}
static void x86_cpu_common_class_init(ObjectClass *oc, void *data)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index adc569c..0caa942 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -932,6 +932,8 @@ void hw_breakpoint_insert(CPUX86State *env, int index);
void hw_breakpoint_remove(CPUX86State *env, int index);
int check_hw_breakpoints(CPUX86State *env, int force_dr6_update);
+void breakpoint_handler(CPUX86State *env);
+
/* will be suppressed */
void cpu_x86_update_cr0(CPUX86State *env, uint32_t new_cr0);
void cpu_x86_update_cr3(CPUX86State *env, target_ulong new_cr3);
diff --git a/target-i386/helper.c b/target-i386/helper.c
index da6f850..a94be0a 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -941,7 +941,7 @@ int check_hw_breakpoints(CPUX86State *env, int
force_dr6_update)
return hit_enabled;
}
-static void breakpoint_handler(CPUX86State *env)
+void breakpoint_handler(CPUX86State *env)
{
CPUBreakpoint *bp;
@@ -1153,20 +1153,11 @@ X86CPU *cpu_x86_init(const char *cpu_model)
{
X86CPU *cpu;
CPUX86State *env;
-static int inited;
cpu = X86_CPU(object_new(TYPE_X86_CPU));
env = cpu-env;
env-cpu_model_str = cpu_model;
-/* init various static tables used in TCG mode */
-if (tcg_enabled() !inited) {
-inited = 1;
-optimize_flags_init();
-#ifndef CONFIG_USER_ONLY
-cpu_set_debug_excp_handler(breakpoint_handler);
-#endif
-}
if (cpu_x86_register(cpu, cpu_model) 0) {
object_delete(OBJECT(cpu));
return NULL;
--
1.7.7.6
Re: [Qemu-devel] OpenBIOS for v1.1.0
On 29 May 2012 16:02, Andreas Färber afaer...@suse.de wrote: commit 7d21dcc84b8c07918124a9c0708694d2fb013f65 updated the binaries to r1056 but did not update the submodule, so the tarballs are shipping old sources. ...I wonder if it would be possible to write a git commit hook that spotted commits which update only the binary but not the submodule? -- PMM
Re: [Qemu-devel] Android Goldfish on QEMU
On 28 May 2012 13:28, Stefan Hajnoczi stefa...@gmail.com wrote: Is goldfish still a relevant Android dev platform? In other words - would goldfish be useful to Android developers or just cool for QEMU hackers and old-school Android enthusiasts? I would suggest not, unless we're going to actually solve the accelerate guest OpenGL(ES) issue in mainline QEMU... -- PMM
[Qemu-devel] [PATCH qom-next 09/12] target-i386: make cpu a child of /machine right after it's created
Make cpu child of /machine before any properties are set.
It is reqired before apic creation is moved to cpu_model property
setter because setting link to cpu in apic requires cpu to have
canonical path.
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
hw/pc.c | 11 ---
target-i386/helper.c | 15 +++
2 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/hw/pc.c b/hw/pc.c
index 4a687d6..e38bf24 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -943,8 +943,6 @@ static X86CPU *pc_new_cpu(const char *cpu_model)
{
X86CPU *cpu;
CPUX86State *env;
-char *name;
-Error *error = NULL;
cpu = cpu_x86_init(cpu_model);
if (cpu == NULL) {
@@ -952,15 +950,6 @@ static X86CPU *pc_new_cpu(const char *cpu_model)
}
env = cpu-env;
-name = g_strdup_printf(cpu[%d], env-cpu_index);
-object_property_add_child(OBJECT(qdev_get_machine()), name,
- OBJECT(cpu), error);
-g_free(name);
-if (error_is_set(error)) {
-qerror_report_err(error);
-exit(1);
-}
-
if ((env-cpuid_features CPUID_APIC) || smp_cpus 1) {
env-apic_state = apic_init(env, env-cpuid_apic_id);
}
diff --git a/target-i386/helper.c b/target-i386/helper.c
index 748eee8..8444f2c 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -21,6 +21,7 @@
#include kvm.h
#ifndef CONFIG_USER_ONLY
#include sysemu.h
+#include hw/qdev.h
#include monitor.h
#endif
@@ -1153,9 +1154,23 @@ X86CPU *cpu_x86_init(const char *cpu_model)
{
X86CPU *cpu;
Error *errp = NULL;
+#ifndef CONFIG_USER_ONLY
+char *name;
+#endif
cpu = X86_CPU(object_new(TYPE_X86_CPU));
+#ifndef CONFIG_USER_ONLY
+name = g_strdup_printf(cpu[%d], cpu-env.cpu_index);
+object_property_add_child(OBJECT(qdev_get_machine()), name,
+ OBJECT(cpu), errp);
+g_free(name);
+if (error_is_set(errp)) {
+qerror_report_err(errp);
+exit(1);
+}
+#endif
+
if (cpu_model) {
object_property_set_str(OBJECT(cpu), cpu_model, cpu-model, errp);
} else {
--
1.7.7.6
[Qemu-devel] [PATCH qom-next 01/12] store prev_debug_excp_handler globaly and not per target
current callers all do the same thing, storing in prev_debug_excp_handler
previous handler and then calling it in breakpoint_handler.
Move prev_debug_excp_handler from local scope to global and make
cpu_set_debug_excp_handler() always to store previous handler.
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
cpu-exec.c |7 +++
exec-all.h |3 ++-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/cpu-exec.c b/cpu-exec.c
index 83cac93..44c83d9 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -155,13 +155,12 @@ static inline TranslationBlock *tb_find_fast(CPUArchState
*env)
}
static CPUDebugExcpHandler *debug_excp_handler;
+CPUDebugExcpHandler *prev_debug_excp_handler;
-CPUDebugExcpHandler *cpu_set_debug_excp_handler(CPUDebugExcpHandler *handler)
+void cpu_set_debug_excp_handler(CPUDebugExcpHandler *handler)
{
-CPUDebugExcpHandler *old_handler = debug_excp_handler;
-
+prev_debug_excp_handler = debug_excp_handler;
debug_excp_handler = handler;
-return old_handler;
}
static void cpu_handle_debug_exception(CPUArchState *env)
diff --git a/exec-all.h b/exec-all.h
index 9bda7f7..f3c3a8a 100644
--- a/exec-all.h
+++ b/exec-all.h
@@ -357,7 +357,8 @@ tb_page_addr_t get_page_addr_code(CPUArchState *env1,
target_ulong addr);
typedef void (CPUDebugExcpHandler)(CPUArchState *env);
-CPUDebugExcpHandler *cpu_set_debug_excp_handler(CPUDebugExcpHandler *handler);
+extern CPUDebugExcpHandler *prev_debug_excp_handler;
+void cpu_set_debug_excp_handler(CPUDebugExcpHandler *handler);
/* vl.c */
extern int singlestep;
--
1.7.7.6
[Qemu-devel] [PATCH qom-next 06/12] apic: Replace cpu_env pointer by X86CPU link
From: Andreas Färber afaer...@suse.de
Needed for converting cpu_is_bsp().
Signed-off-by: Andreas Färber afaer...@suse.de
Cc: Paolo Bonzini pbonz...@redhat.com
---
hw/apic.c | 34 +++---
hw/apic_common.c | 14 +++---
hw/apic_internal.h |2 +-
hw/kvm/apic.c |9 +
hw/pc.c|9 -
5 files changed, 44 insertions(+), 24 deletions(-)
diff --git a/hw/apic.c b/hw/apic.c
index 4eeaf88..1207c33 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -114,7 +114,7 @@ static void apic_sync_vapic(APICCommonState *s, int
sync_type)
length = offsetof(VAPICState, enabled) - offsetof(VAPICState, isr);
if (sync_type SYNC_TO_VAPIC) {
-assert(qemu_cpu_is_self(s-cpu_env));
+assert(qemu_cpu_is_self(s-cpu-env));
vapic_state.tpr = s-tpr;
vapic_state.enabled = 1;
@@ -158,15 +158,15 @@ static void apic_local_deliver(APICCommonState *s, int
vector)
switch ((lvt 8) 7) {
case APIC_DM_SMI:
-cpu_interrupt(s-cpu_env, CPU_INTERRUPT_SMI);
+cpu_interrupt(s-cpu-env, CPU_INTERRUPT_SMI);
break;
case APIC_DM_NMI:
-cpu_interrupt(s-cpu_env, CPU_INTERRUPT_NMI);
+cpu_interrupt(s-cpu-env, CPU_INTERRUPT_NMI);
break;
case APIC_DM_EXTINT:
-cpu_interrupt(s-cpu_env, CPU_INTERRUPT_HARD);
+cpu_interrupt(s-cpu-env, CPU_INTERRUPT_HARD);
break;
case APIC_DM_FIXED:
@@ -194,7 +194,7 @@ void apic_deliver_pic_intr(DeviceState *d, int level)
reset_bit(s-irr, lvt 0xff);
/* fall through */
case APIC_DM_EXTINT:
-cpu_reset_interrupt(s-cpu_env, CPU_INTERRUPT_HARD);
+cpu_reset_interrupt(s-cpu-env, CPU_INTERRUPT_HARD);
break;
}
}
@@ -255,18 +255,22 @@ static void apic_bus_deliver(const uint32_t
*deliver_bitmask,
case APIC_DM_SMI:
foreach_apic(apic_iter, deliver_bitmask,
-cpu_interrupt(apic_iter-cpu_env, CPU_INTERRUPT_SMI) );
+cpu_interrupt(apic_iter-cpu-env, CPU_INTERRUPT_SMI)
+);
return;
case APIC_DM_NMI:
foreach_apic(apic_iter, deliver_bitmask,
-cpu_interrupt(apic_iter-cpu_env, CPU_INTERRUPT_NMI) );
+cpu_interrupt(apic_iter-cpu-env, CPU_INTERRUPT_NMI)
+);
return;
case APIC_DM_INIT:
/* normal INIT IPI sent to processors */
foreach_apic(apic_iter, deliver_bitmask,
- cpu_interrupt(apic_iter-cpu_env, CPU_INTERRUPT_INIT)
);
+ cpu_interrupt(apic_iter-cpu-env,
+ CPU_INTERRUPT_INIT)
+);
return;
case APIC_DM_EXTINT:
@@ -300,7 +304,7 @@ static void apic_set_base(APICCommonState *s, uint64_t val)
/* if disabled, cannot be enabled again */
if (!(val MSR_IA32_APICBASE_ENABLE)) {
s-apicbase = ~MSR_IA32_APICBASE_ENABLE;
-cpu_clear_apic_feature(s-cpu_env);
+cpu_clear_apic_feature(s-cpu-env);
s-spurious_vec = ~APIC_SV_ENABLE;
}
}
@@ -370,7 +374,7 @@ static void apic_update_irq(APICCommonState *s)
return;
}
if (apic_irq_pending(s) 0) {
-cpu_interrupt(s-cpu_env, CPU_INTERRUPT_HARD);
+cpu_interrupt(s-cpu-env, CPU_INTERRUPT_HARD);
} else if (apic_accept_pic_intr(s-busdev.qdev)
pic_get_output(isa_pic)) {
apic_deliver_pic_intr(s-busdev.qdev, 1);
@@ -480,18 +484,18 @@ static void apic_get_delivery_bitmask(uint32_t
*deliver_bitmask,
static void apic_startup(APICCommonState *s, int vector_num)
{
s-sipi_vector = vector_num;
-cpu_interrupt(s-cpu_env, CPU_INTERRUPT_SIPI);
+cpu_interrupt(s-cpu-env, CPU_INTERRUPT_SIPI);
}
void apic_sipi(DeviceState *d)
{
APICCommonState *s = DO_UPCAST(APICCommonState, busdev.qdev, d);
-cpu_reset_interrupt(s-cpu_env, CPU_INTERRUPT_SIPI);
+cpu_reset_interrupt(s-cpu-env, CPU_INTERRUPT_SIPI);
if (!s-wait_for_sipi)
return;
-cpu_x86_load_seg_cache_sipi(s-cpu_env, s-sipi_vector);
+cpu_x86_load_seg_cache_sipi(s-cpu-env, s-sipi_vector);
s-wait_for_sipi = 0;
}
@@ -666,7 +670,7 @@ static uint32_t apic_mem_readl(void *opaque,
target_phys_addr_t addr)
case 0x08:
apic_sync_vapic(s, SYNC_FROM_VAPIC);
if (apic_report_tpr_access) {
-cpu_report_tpr_access(s-cpu_env, TPR_ACCESS_READ);
+cpu_report_tpr_access(s-cpu-env, TPR_ACCESS_READ);
}
val = s-tpr;
break;
@@ -768,7 +772,7 @@ static void apic_mem_writel(void *opaque,
target_phys_addr_t addr, uint32_t val)
break;
case 0x08:
if (apic_report_tpr_access) {
-cpu_report_tpr_access(s-cpu_env, TPR_ACCESS_WRITE);
+cpu_report_tpr_access(s-cpu-env, TPR_ACCESS_WRITE);
[Qemu-devel] [PATCH qom-next 02/12] target-xtensa: use global prev_debug_excp_handler instead of local one
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
target-xtensa/helper.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/target-xtensa/helper.c b/target-xtensa/helper.c
index 5e7e72e..e2ab83c 100644
--- a/target-xtensa/helper.c
+++ b/target-xtensa/helper.c
@@ -54,8 +54,6 @@ static uint32_t check_hw_breakpoints(CPUXtensaState *env)
return 0;
}
-static CPUDebugExcpHandler *prev_debug_excp_handler;
-
static void breakpoint_handler(CPUXtensaState *env)
{
if (env-watchpoint_hit) {
@@ -105,8 +103,7 @@ XtensaCPU *cpu_xtensa_init(const char *cpu_model)
if (!debug_handler_inited tcg_enabled()) {
debug_handler_inited = 1;
-prev_debug_excp_handler =
-cpu_set_debug_excp_handler(breakpoint_handler);
+cpu_set_debug_excp_handler(breakpoint_handler);
}
xtensa_irq_init(env);
--
1.7.7.6
[Qemu-devel] [PATCH qom-next 07/12] target-i386: move cpu halted decision into x86_cpu_reset
From: Igor Mammedov niall...@gmail.com
MP initialization protocol differs between cpu families, and for P6 and
onward models it is up to CPU to decide if it will be BSP using this
protocol, so try to model this. However there is no point in implementing
MP initialization protocol in qemu. Thus first CPU is always marked as BSP.
This patch:
- moves decision to designate BSP from board into cpu, making cpu
self-sufficient in this regard. Later it will allow to cleanup hw/pc.c
and remove cpu_reset and wrappers from there.
- stores flag that CPU is BSP in IA32_APIC_BASE to model behavior
described in Inted SDM vol 3a part 1 chapter 8.4.1
- uses MSR_IA32_APICBASE_BSP flag in apic_base for checking if cpu is BSP
patch is based on Jan Kiszka's proposal:
http://thread.gmane.org/gmane.comp.emulators.qemu/100806
v2:
- fix build for i386-linux-user
spotted-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
hw/apic.h|2 +-
hw/apic_common.c | 18 --
hw/pc.c |9 -
target-i386/cpu.c|9 +
target-i386/helper.c |1 -
target-i386/kvm.c|5 +++--
6 files changed, 25 insertions(+), 19 deletions(-)
diff --git a/hw/apic.h b/hw/apic.h
index 62179ce..d961ed4 100644
--- a/hw/apic.h
+++ b/hw/apic.h
@@ -20,9 +20,9 @@ void apic_init_reset(DeviceState *s);
void apic_sipi(DeviceState *s);
void apic_handle_tpr_access_report(DeviceState *d, target_ulong ip,
TPRAccess access);
+void apic_designate_bsp(DeviceState *d);
/* pc.c */
-int cpu_is_bsp(CPUX86State *env);
DeviceState *cpu_get_current_apic(void);
#endif
diff --git a/hw/apic_common.c b/hw/apic_common.c
index 46a9ff7..98ad6f0 100644
--- a/hw/apic_common.c
+++ b/hw/apic_common.c
@@ -43,8 +43,8 @@ uint64_t cpu_get_apic_base(DeviceState *d)
trace_cpu_get_apic_base((uint64_t)s-apicbase);
return s-apicbase;
} else {
-trace_cpu_get_apic_base(0);
-return 0;
+trace_cpu_get_apic_base(MSR_IA32_APICBASE_BSP);
+return MSR_IA32_APICBASE_BSP;
}
}
@@ -201,22 +201,28 @@ void apic_init_reset(DeviceState *d)
s-timer_expiry = -1;
}
+void apic_designate_bsp(DeviceState *d)
+{
+if (d) {
+APICCommonState *s = APIC_COMMON(d);
+s-apicbase |= MSR_IA32_APICBASE_BSP;
+}
+}
+
static void apic_reset_common(DeviceState *d)
{
APICCommonState *s = DO_UPCAST(APICCommonState, busdev.qdev, d);
APICCommonClass *info = APIC_COMMON_GET_CLASS(s);
-bool bsp;
-bsp = cpu_is_bsp(s-cpu-env);
s-apicbase = 0xfee0 |
-(bsp ? MSR_IA32_APICBASE_BSP : 0) | MSR_IA32_APICBASE_ENABLE;
+(s-apicbase MSR_IA32_APICBASE_BSP) | MSR_IA32_APICBASE_ENABLE;
s-vapic_paddr = 0;
info-vapic_base_update(s);
apic_init_reset(d);
-if (bsp) {
+if (s-apicbase MSR_IA32_APICBASE_BSP) {
/*
* LINT0 delivery mode on CPU #0 is set to ExtInt at initialization
* time typically by BIOS, so PIC interrupt can be delivered to the
diff --git a/hw/pc.c b/hw/pc.c
index 6bb3d2a..2f681db 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -870,12 +870,6 @@ void pc_init_ne2k_isa(ISABus *bus, NICInfo *nd)
nb_ne2k++;
}
-int cpu_is_bsp(CPUX86State *env)
-{
-/* We hard-wire the BSP to the first CPU. */
-return env-cpu_index == 0;
-}
-
DeviceState *cpu_get_current_apic(void)
{
if (cpu_single_env) {
@@ -942,10 +936,7 @@ void pc_acpi_smi_interrupt(void *opaque, int irq, int
level)
static void pc_cpu_reset(void *opaque)
{
X86CPU *cpu = opaque;
-CPUX86State *env = cpu-env;
-
cpu_reset(CPU(cpu));
-env-halted = !cpu_is_bsp(env);
}
static X86CPU *pc_new_cpu(const char *cpu_model)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 41a0436..f029f2a 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1704,6 +1704,15 @@ static void x86_cpu_reset(CPUState *s)
env-dr[7] = DR7_FIXED_1;
cpu_breakpoint_remove_all(env, BP_CPU);
cpu_watchpoint_remove_all(env, BP_CPU);
+
+#if !defined(CONFIG_USER_ONLY)
+/* We hard-wire the BSP to the first CPU. */
+if (env-cpu_index == 0) {
+apic_designate_bsp(env-apic_state);
+}
+
+env-halted = !(cpu_get_apic_base(env-apic_state)
MSR_IA32_APICBASE_BSP);
+#endif
}
static void mce_init(X86CPU *cpu)
diff --git a/target-i386/helper.c b/target-i386/helper.c
index a94be0a..fd20fd4 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -1179,7 +1179,6 @@ void do_cpu_init(X86CPU *cpu)
env-interrupt_request = sipi;
env-pat = pat;
apic_init_reset(env-apic_state);
-env-halted = !cpu_is_bsp(env);
}
void do_cpu_sipi(X86CPU *cpu)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 0d0d8f6..09621e5 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -583,8 +583,9 @@ void kvm_arch_reset_vcpu(CPUX86State *env)
env-interrupt_injected = -1;
[Qemu-devel] [PATCH qom-next 05/12] pc: Add CPU as /machine/cpu[n]
From: Andreas Färber afaer...@suse.de
Using the cpu_index, give the X86CPU a canonical path.
This must be done before initializing the APIC.
Signed-off-by: Igor Mammedov niall...@gmail.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
hw/pc.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/hw/pc.c b/hw/pc.c
index 4167782..e9d7e05 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -945,6 +945,8 @@ static X86CPU *pc_new_cpu(const char *cpu_model)
{
X86CPU *cpu;
CPUX86State *env;
+char *name;
+Error *error = NULL;
cpu = cpu_x86_init(cpu_model);
if (cpu == NULL) {
@@ -952,6 +954,16 @@ static X86CPU *pc_new_cpu(const char *cpu_model)
exit(1);
}
env = cpu-env;
+
+name = g_strdup_printf(cpu[%d], env-cpu_index);
+object_property_add_child(OBJECT(qdev_get_machine()), name,
+ OBJECT(cpu), error);
+g_free(name);
+if (error_is_set(error)) {
+qerror_report_err(error);
+exit(1);
+}
+
if ((env-cpuid_features CPUID_APIC) || smp_cpus 1) {
env-apic_state = apic_init(env, env-cpuid_apic_id);
}
--
1.7.7.6
[Qemu-devel] [PATCH qom-next 10/12] pc: Enable MSI support at APIC level
From: Jan Kiszka jan.kis...@siemens.com
Push msi_supported enabling to the APIC implementations where we can
encapsulate the decision more cleanly, hiding the details from the
generic code.
Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
---
hw/apic.c |3 +++
hw/pc.c |9 -
hw/xen.h | 10 --
hw/xen_apic.c |5 +
4 files changed, 8 insertions(+), 19 deletions(-)
diff --git a/hw/apic.c b/hw/apic.c
index 1207c33..92e8339 100644
--- a/hw/apic.c
+++ b/hw/apic.c
@@ -19,6 +19,7 @@
#include apic_internal.h
#include apic.h
#include ioapic.h
+#include msi.h
#include host-utils.h
#include trace.h
#include pc.h
@@ -866,6 +867,8 @@ static void apic_init(APICCommonState *s)
s-timer = qemu_new_timer_ns(vm_clock, apic_timer, s);
local_apics[s-idx] = s;
+
+msi_supported = true;
}
static void apic_class_init(ObjectClass *klass, void *data)
diff --git a/hw/pc.c b/hw/pc.c
index e38bf24..d178801 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -912,15 +912,6 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
apic_mapped = 1;
}
-/* KVM does not support MSI yet. */
-if (!kvm_irqchip_in_kernel()) {
-msi_supported = true;
-}
-
-if (xen_msi_support()) {
-msi_supported = true;
-}
-
return dev;
}
diff --git a/hw/xen.h b/hw/xen.h
index 3ae4cd0..e5926b7 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -57,14 +57,4 @@ void xen_register_framebuffer(struct MemoryRegion *mr);
# define HVM_MAX_VCPUS 32
#endif
-static inline int xen_msi_support(void)
-{
-#if defined(CONFIG_XEN_CTRL_INTERFACE_VERSION) \
- CONFIG_XEN_CTRL_INTERFACE_VERSION = 420
-return xen_enabled();
-#else
-return 0;
-#endif
-}
-
#endif /* QEMU_HW_XEN_H */
diff --git a/hw/xen_apic.c b/hw/xen_apic.c
index 1725ff6..a9e101f 100644
--- a/hw/xen_apic.c
+++ b/hw/xen_apic.c
@@ -40,6 +40,11 @@ static void xen_apic_init(APICCommonState *s)
{
memory_region_init_io(s-io_memory, xen_apic_io_ops, s, xen-apic-msi,
MSI_SPACE_SIZE);
+
+#if defined(CONFIG_XEN_CTRL_INTERFACE_VERSION) \
+ CONFIG_XEN_CTRL_INTERFACE_VERSION = 420
+msi_supported = true;
+#endif
}
static void xen_apic_set_base(APICCommonState *s, uint64_t val)
--
1.7.7.6
[Qemu-devel] [PATCH qom-next 12/12] target-i386: move reset callback to cpu.c and call cpu_reset() in x86_cpu_realize()
Moving reset callback into cpu object from board level and
resetting cpu at the end of x86_cpu_realize() will allow properly
create cpu object during run-time (hotplug).
When reset over QOM hierarchy is implemented, reset callback
should be removed.
Additionally, there is only call to cpu_x86_init() left in pc_new_cpu(),
move it into pc_cpus_init() and delete empty pc_new_cpu().
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
hw/pc.c | 28 ++--
target-i386/cpu.c | 12
2 files changed, 18 insertions(+), 22 deletions(-)
diff --git a/hw/pc.c b/hw/pc.c
index 986f119..fda6afc 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -885,32 +885,16 @@ void pc_acpi_smi_interrupt(void *opaque, int irq, int
level)
}
}
-static void pc_cpu_reset(void *opaque)
-{
-X86CPU *cpu = opaque;
-cpu_reset(CPU(cpu));
-}
-
-static X86CPU *pc_new_cpu(const char *cpu_model)
-{
-X86CPU *cpu;
-
-cpu = cpu_x86_init(cpu_model);
-if (cpu == NULL) {
-exit(1);
-}
-
-qemu_register_reset(pc_cpu_reset, cpu);
-pc_cpu_reset(cpu);
-return cpu;
-}
-
void pc_cpus_init(const char *cpu_model)
{
+X86CPU *cpu;
int i;
-for(i = 0; i smp_cpus; i++) {
-pc_new_cpu(cpu_model);
+for (i = 0; i smp_cpus; i++) {
+cpu = cpu_x86_init(cpu_model);
+if (cpu == NULL) {
+exit(1);
+}
}
}
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index b649904..8d9729d 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1781,6 +1781,14 @@ static void x86_set_cpu_model(Object *obj, const char
*value, Error **errp)
}
#ifndef CONFIG_USER_ONLY
+
+/* TODO: remove me, when reset over QOM tree is implemented */
+static void x86_cpu_machine_reset_cb(void *opaque)
+{
+X86CPU *cpu = opaque;
+cpu_reset(CPU(cpu));
+}
+
#define MSI_ADDR_BASE 0xfee0
static void x86_cpu_apic_init(X86CPU *cpu, Error **errp)
@@ -1813,13 +1821,17 @@ void x86_cpu_realize(Object *obj, Error **errp)
{
X86CPU *cpu = X86_CPU(obj);
+#ifndef CONFIG_USER_ONLY
x86_cpu_apic_init(cpu, errp);
if (error_is_set(errp)) {
return;
}
+qemu_register_reset(x86_cpu_machine_reset_cb, cpu);
+#endif
mce_init(cpu);
qemu_init_vcpu(cpu-env);
+cpu_reset(CPU(cpu));
}
static void x86_cpu_initfn(Object *obj)
--
1.7.7.6
[Qemu-devel] [PATCH qom-next v3 0/12] target-i386: re-factor CPU creation/initialization to QOM
Moving code related to CPU creation and initialization internal parts from board level into apic and cpu objects will allow X86CPU to better model QOM object life-cycle. It will allow to create X86CPU as any other object by creating it with object_new() then setting properties and then calling x86_cpu_realize() to make it running. Later x86_cpu_realize() should become realize property. git tree for testing: https://github.com/imammedo/qemu/tree/x86-cpu-realize-v3 Compile Run tested: target-i386: tcg and kvm mode i386-linux-user: running of /bin/ls and /usr/bin/make on qemu tree (12): store prev_debug_excp_handler globaly and not per target target-xtensa: use global prev_debug_excp_handler instead of local one target-i386: use global prev_debug_excp_handler instead of local one target-i386: move tcg initialization into x86_cpu_initfn() pc: Add CPU as /machine/cpu[n] apic: Replace cpu_env pointer by X86CPU link taken from Andreas' QOM CPUState part 4 series, to avoid conflict with reintroducing set_ptr replaced by linkX86CPU in this patches target-i386: move cpu halted decision into x86_cpu_reset target-i386: introduce cpu-model property for x86_cpu target-i386: make cpu a child of /machine right after it's created pc: Enable MSI support at APIC level http://thread.gmane.org/gmane.comp.emulators.kvm.devel/91186 included here to prevent confilict since qom-next doesn't have it but next patch is depending on it. target-i386: initialize APIC at CPU level target-i386: move reset callback to cpu.c and call cpu_reset() in x86_cpu_realize() cpu-defs.h |2 +- cpu-exec.c |7 +-- exec-all.h |3 +- hw/apic.c | 37 +-- hw/apic.h |2 +- hw/apic_common.c | 30 +--- hw/apic_internal.h |2 +- hw/kvm/apic.c |9 ++-- hw/pc.c| 92 +++--- hw/xen.h | 10 hw/xen_apic.c |5 ++ target-i386/cpu.c | 117 target-i386/cpu.h |2 + target-i386/helper.c | 41 ++--- target-i386/kvm.c |5 +- target-xtensa/helper.c |5 +--
[Qemu-devel] [PATCH qom-next 03/12] target-i386: use global prev_debug_excp_handler instead of local one
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
target-i386/helper.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/target-i386/helper.c b/target-i386/helper.c
index 2cc8097..da6f850 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -941,8 +941,6 @@ int check_hw_breakpoints(CPUX86State *env, int
force_dr6_update)
return hit_enabled;
}
-static CPUDebugExcpHandler *prev_debug_excp_handler;
-
static void breakpoint_handler(CPUX86State *env)
{
CPUBreakpoint *bp;
@@ -1166,8 +1164,7 @@ X86CPU *cpu_x86_init(const char *cpu_model)
inited = 1;
optimize_flags_init();
#ifndef CONFIG_USER_ONLY
-prev_debug_excp_handler =
-cpu_set_debug_excp_handler(breakpoint_handler);
+cpu_set_debug_excp_handler(breakpoint_handler);
#endif
}
if (cpu_x86_register(cpu, cpu_model) 0) {
--
1.7.7.6
[Qemu-devel] [Bug 688052] Re: usb does not work 0.13.0
the correct syntax is -usb -device usb-host,vendorid=x,productid=y -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/688052 Title: usb does not work 0.13.0 Status in QEMU: New Bug description: Hi all, I'm using both, debian lenny and debian squeeze. I installed qemu-kvm (0.12.5) form debian repository but I got problem trying to pass a host usb device to the guest. I compiled so the latest stable version (0.13.0) hoping that the problem was fixed. It didn't help, the error I get is always: usb_create: no bus specified, using usb.0 for usb-host The command I use is qemu-system-x86_64 -hda lenny_amd64_vergine.qcow2 -usbdevice host:002.007 -boot order=c On internet I found this, it might help: http://www.mail-archive.com/qemu-devel@nongnu.org/msg38795.html The guest is a simple debian lenny with 2.6.26 kernel. I tried also to download the qemu development version but the download get interruped git clone http://git.qemu.org/qemu.git Cloning into qemu... error: Failed connect to git.qemu.org:80; No such file or directory (curl_result = 7, http_code = 0, sha1 = 62d76a25fe741bdaf1157f0edaf50a7772541db6) error: Unable to find 62d76a25fe741bdaf1157f0edaf50a7772541db6 under http://git.qemu.org/qemu.git I attach more info about the host machine I'm testing on. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/688052/+subscriptions
[Qemu-devel] [Bug 688052] Re: usb does not work 0.13.0
at leats on my app-emulation/qemu-kvm-1.0-r2 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/688052 Title: usb does not work 0.13.0 Status in QEMU: New Bug description: Hi all, I'm using both, debian lenny and debian squeeze. I installed qemu-kvm (0.12.5) form debian repository but I got problem trying to pass a host usb device to the guest. I compiled so the latest stable version (0.13.0) hoping that the problem was fixed. It didn't help, the error I get is always: usb_create: no bus specified, using usb.0 for usb-host The command I use is qemu-system-x86_64 -hda lenny_amd64_vergine.qcow2 -usbdevice host:002.007 -boot order=c On internet I found this, it might help: http://www.mail-archive.com/qemu-devel@nongnu.org/msg38795.html The guest is a simple debian lenny with 2.6.26 kernel. I tried also to download the qemu development version but the download get interruped git clone http://git.qemu.org/qemu.git Cloning into qemu... error: Failed connect to git.qemu.org:80; No such file or directory (curl_result = 7, http_code = 0, sha1 = 62d76a25fe741bdaf1157f0edaf50a7772541db6) error: Unable to find 62d76a25fe741bdaf1157f0edaf50a7772541db6 under http://git.qemu.org/qemu.git I attach more info about the host machine I'm testing on. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/688052/+subscriptions
Re: [Qemu-devel] [PATCH 1.1] sheepdog: add coroutine_fn markers to coroutine functions
At Tue, 29 May 2012 18:30:17 +0200,
Andreas Färber wrote:
Am 29.05.2012 18:22, schrieb MORITA Kazutaka:
Signed-off-by: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp
Patch is tab-damaged.
Oops, I'll send a new version.
Thanks,
Kazutaka
Andreas
---
block/sheepdog.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/block/sheepdog.c b/block/sheepdog.c
index f46ca8f..046f52a 100644
--- a/block/sheepdog.c
+++ b/block/sheepdog.c
@@ -522,8 +522,8 @@ static int send_req(int sockfd, SheepdogReq *hdr, void
*data,
return ret;
}
-static int send_co_req(int sockfd, SheepdogReq *hdr, void *data,
- unsigned int *wlen)
+static coroutine_fn int send_co_req(int sockfd, SheepdogReq *hdr, void
*data,
+ unsigned int *wlen)
{
int ret;
@@ -540,6 +540,7 @@ static int send_co_req(int sockfd, SheepdogReq *hdr,
void *data,
return ret;
}
+
static int do_req(int sockfd, SheepdogReq *hdr, void *data,
unsigned int *wlen, unsigned int *rlen)
{
@@ -576,8 +577,8 @@ out:
return ret;
}
-static int do_co_req(int sockfd, SheepdogReq *hdr, void *data,
- unsigned int *wlen, unsigned int *rlen)
+static coroutine_fn int do_co_req(int sockfd, SheepdogReq *hdr, void *data,
+ unsigned int *wlen, unsigned int *rlen)
{
int ret;
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH 1.1 v2] sheepdog: add coroutine_fn markers to coroutine functions
Signed-off-by: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp
---
Changes from v1:
- use spaces for indentation
block/sheepdog.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/block/sheepdog.c b/block/sheepdog.c
index f46ca8f..8877f45 100644
--- a/block/sheepdog.c
+++ b/block/sheepdog.c
@@ -522,8 +522,8 @@ static int send_req(int sockfd, SheepdogReq *hdr, void
*data,
return ret;
}
-static int send_co_req(int sockfd, SheepdogReq *hdr, void *data,
- unsigned int *wlen)
+static coroutine_fn int send_co_req(int sockfd, SheepdogReq *hdr, void *data,
+unsigned int *wlen)
{
int ret;
@@ -540,6 +540,7 @@ static int send_co_req(int sockfd, SheepdogReq *hdr, void
*data,
return ret;
}
+
static int do_req(int sockfd, SheepdogReq *hdr, void *data,
unsigned int *wlen, unsigned int *rlen)
{
@@ -576,8 +577,8 @@ out:
return ret;
}
-static int do_co_req(int sockfd, SheepdogReq *hdr, void *data,
- unsigned int *wlen, unsigned int *rlen)
+static coroutine_fn int do_co_req(int sockfd, SheepdogReq *hdr, void *data,
+ unsigned int *wlen, unsigned int *rlen)
{
int ret;
--
1.7.2.5
Re: [Qemu-devel] [PATCH v2 01/17] Openrisc: add target stubs
Hi Andreas,
On Sun, May 27, 2012 at 8:44 PM, Andreas Färber afaer...@suse.de wrote:
Am 27.05.2012 07:32, schrieb Jia Liu:
add openrisc target stubs.
Signed-off-by: Jia Liu pro...@gmail.com
Minor nitpick: I'd recommend to stick to the typographic conventions
outlined here:
https://live.gnome.org/Git/CommitMessages
In particular please start the sentence with a capital A. GNOME
recommend a lowercase topic (we usually use the file/directory mainly
affected) and uppercase beginning of the actual description, e.g.
target-or32: Add target stubs
Add OpenRISC target stubs.
Thanks, I'll fix all of them.
Signed-off-by: ...
Writing it that way is not mandatory but when you're reposting and
fixing the English grammar you can just as well make it perfect. ;)
I'm trying, all the time...
As Stefan pointed out, www.opencores.org writes it as OpenRISC, not
Openrisc. I saw no prominent notice whether OpenRISC may be a trademark
but better to respect their naming, seeing all the misspellings of QEMU.
Thanks, I'll fix all of them.
[...]
diff --git a/target-openrisc/cpu.c b/target-openrisc/cpu.c
new file mode 100644
index 000..ef3ffb1
--- /dev/null
+++ b/target-openrisc/cpu.c
@@ -0,0 +1,24 @@
+/*
+ * QEMU Openrisc CPU
+ *
+ * Copyright (c) 2012 Jia Liu pro...@gmail.com
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
http://www.gnu.org/licenses/.
+ */
+
+#include cpu.h
+#include qemu-common.h
+#if !defined(CONFIG_USER_ONLY)
+#include hw/loader.h
+#endif
Missing TypeInfo, missing class_init, missing initfn (where you might
want to move the openrisc_translate_init() call btw, following Igor's
example), missing reset function. This cannot all be deferred to a later
patch.
I'm trying fix this, is target-i386 a good example of QOM? If so, I'll
rewrite the code fellow target-i386.
diff --git a/target-openrisc/cpu.h b/target-openrisc/cpu.h
new file mode 100644
index 000..80018df
--- /dev/null
+++ b/target-openrisc/cpu.h
@@ -0,0 +1,184 @@
+/*
+ * Openrisc virtual CPU header.
+ *
+ * Copyright (c) 2011-2012 Jia Liu pro...@gmail.com
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
http://www.gnu.org/licenses/.
+ */
+
+#ifndef CPU_OPENRISC_H
+#define CPU_OPENRISC_H
+
+#define TARGET_HAS_ICE 1
+
+#define ELF_MACHINE EM_OPENRISC
+
+#define CPUArchState struct CPUOpenriscState
+
+#define TARGET_LONG_BITS 32
+
+#include config.h
+#include qemu-common.h
+#include cpu-defs.h
+#include softfloat.h
+#include qemu/cpu.h
+
+struct CPUOpenriscState;
+
+#define NB_MMU_MODES 3
+#define MMU_NOMMU_IDX 0
+#define MMU_SUPERVISOR_IDX 1
+#define MMU_USER_IDX 2
Maybe make these three an enum?
Thanks, I'll make a enum for them.
+
+#define TARGET_PAGE_BITS 13
+
+#define TARGET_PHYS_ADDR_SPACE_BITS 32
+#define TARGET_VIRT_ADDR_SPACE_BITS 32
+
+/* Verison Register */
+#define SPR_VR 0x1201
+#define SPR_CPUCFGR 0x1201
+
+/* Registers */
+enum {
+ R0 = 0, R1, R2, R3, R4, R5, R6, R7, R8, R9, R10,
+ R11, R12, R13, R14, R15, R16, R17, R18, R19, R20,
+ R21, R22, R23, R24, R25, R26, R27, R28, R29, R30,
+ R31
+};
+
+/* Register aliases */
+enum {
+ R_ZERO = R0,
+ R_SP = R1,
+ R_FP = R2,
+ R_LR = R9,
+ R_RV = R11,
+ R_RVH = R12
+};
+
+typedef struct CPUOpenriscState CPUOpenriscState;
+struct CPUOpenriscState {
+ target_ulong gpr[32]; /* General registers */
+
+ CPU_COMMON
+
+ target_ulong pc; /* Program counter */
+ target_ulong npc; /* Next PC */
+ target_ulong ppc; /* Prev PC */
+ target_ulong jmp_pc; /* Jump PC */
+ uint32_t flags;
+ /* Branch. */
+ uint32_t btaken; /* the SR_F bit */
+};
Why are
[Qemu-devel] ARM: Virtual / Physical address translation
I am working on a qemu modification that would output memory traces in a format acceptable to Dinero IV. I've seen some previous proto-type work done on this with mips and x86, but I am specifically interested in arm. Currently, I am able to dump the virtual address of all ld/st instructions. I believe I am on the right track for instruction fetches, just dumping the pc at translation time - should give me the virtual address of the current instruction. I previously tried dumping r15 - the pc for arm - but it wasn't always updated for every instruction. What I would like is to be able to get the physical addresses of both data and instructions. Can anyone help me work through how to get the properly translated physical addresses given the virtual address? If there isn't an api/function call that does the translation, it would be nice to have a helper function like: uint64_t gen_helper_virtual_to_physical_translation(uint64_t virtualAddr) I'm not sure it needs to be a defined helper function, but I'm familiar with generating those, so it makes sense like that... Thanks for any help,
Re: [Qemu-devel] [PATCH, repost 2] qemu-keymaps: Finnish keyboard mapping broken
On 05/09/2012 03:31 PM, Michael Tokarev wrote: As mentioned in http://bugs.debian.org/660154 , finnish keyboard mapping is kind of broken. Fix it as Timo Sirainen suggests in #660154. Signed-off-By: Michael Tokarevm...@tls.msk.ru index 2a4e0f0..4be7586 100644 Please post patches with git-send-email. Regards, Anthony Liguori --- a/pc-bios/keymaps/fi +++ b/pc-bios/keymaps/fi @@ -99,9 +99,7 @@ asterisk 0x2b shift acute 0x2b altgr multiply 0x2b shift altgr guillemotleft 0x2c altgr -less 0x2c shift altgr guillemotright 0x2d altgr -greater 0x2d shift altgr copyright 0x2e altgr leftdoublequotemark 0x2f altgr grave 0x2f shift altgr Thanks! /mjt
Re: [Qemu-devel] ARM: Virtual / Physical address translation
On 30 May 2012 02:00, Ira Ray Jenkins irarayjenk...@gmail.com wrote: What I would like is to be able to get the physical addresses of both data and instructions. Can anyone help me work through how to get the properly translated physical addresses given the virtual address? See the function get_phys_addr() in target-arm/helper.c ... That is a private function but if you're doing a local hack you can wire it up to what you need it for. -- PMM
Re: [Qemu-devel] [PULL 1.1] Cocoa patch queue for v1.1 2012-05-29
On 05/29/2012 04:59 AM, Andreas Färber wrote: Hello Anthony, Please pull the Cocoa queue into qemu.git master: Pulled. Thanks. Regards, Anthony Liguori One general build fix for Darwin/ppc, one behavioral fix for make check with Cocoa. The following changes since commit 24f50d7ea5896a30b0e78f68884586bb8b40ff97: tcg/ppc: Handle _CALL_DARWIN being undefined on Darwin (2012-05-27 21:52:56 +0400) are available in the git repository at: git://repo.or.cz/qemu/afaerber.git cocoa-for-upstream Andreas Färber (2): arch_init: Fix AltiVec build on Darwin/ppc cocoa: Suppress Cocoa frontend for -qtest arch_init.c |4 ui/cocoa.m |3 ++- 2 files changed, 6 insertions(+), 1 deletions(-)
Re: [Qemu-devel] [PULL 1.1] qemu-ga build fix for OpenBSD
On 05/29/2012 10:30 AM, Michael Roth wrote: On Thu, May 24, 2012 at 01:52:39PM -0500, Michael Roth wrote: The following changes since commit aeb29b6459cb9496b38c820f3faff64cf2369d0d: audio: Always call fini on exit (2012-05-24 19:35:27 +0400) are available in the git repository at: git://github.com/mdroth/qemu.git qga-pull-5-24-12 Luiz Capitulino (2): configure: check if environ is declared qemu-ga: Fix missing environ declaration configure| 19 +++ qga/commands-posix.c |6 +- 2 files changed, 24 insertions(+), 1 deletions(-) Please ignore. There are a couple new patches in the queue that are dependent on patches in this pull. Will send a new pull request. Too late. I applied it last night before you sent this note. Please rebase your pull request with a patch that fixes the previous patch. Regards, Anthony Liguori
Re: [Qemu-devel] [PULL 1.1 0/2] SCSI patches for 1.1.0-rc3
On 05/22/2012 07:25 AM, Paolo Bonzini wrote: The following changes since commit 76ee152a86d5f2533443ce4d2be6fe253cfb3c45: Update version to 1.1.0-rc2 (2012-05-14 17:56:50 -0500) Pulled. Thanks. Regards, Anthony Liguori are available in the git repository at: git://github.com/bonzini/qemu.git scsi-next for you to fetch changes up to e1a2d34f4abd8a117f5c5a25a5bb2e67d597de23: ISCSI: call qemu_notify_event() after updating events (2012-05-22 14:14:05 +0200) Jim Meyering (1): scsi: declare vmstate_info_scsi_requests to be static Ronnie Sahlberg (1): ISCSI: call qemu_notify_event() after updating events block/iscsi.c |7 +++ hw/scsi-bus.c |2 +- 2 files changed, 8 insertions(+), 1 deletion(-)
