[Qemu-devel] [PATCH] virtio-spec: clarify ro/rw bits and updating rule of virtio-net status field
This patch clarifies VIRTIO_NET_S_LINK_UP as a read-only bit and VIRTIO_NET_S_ANNOUNCE as a read-writable bit. Also introduce the write 1 to clear semantics for all read-writable bits of config status field. This could help to reduce the config status field updating race between host and guest and also simplify the implementation. Signed-off-by: Jason Wang jasow...@redhat.com --- virtio-0.9.4.lyx | 23 +-- 1 files changed, 21 insertions(+), 2 deletions(-) diff --git a/virtio-0.9.4.lyx b/virtio-0.9.4.lyx index 6c7bab1..614ab55 100644 --- a/virtio-0.9.4.lyx +++ b/virtio-0.9.4.lyx @@ -58,6 +58,7 @@ \html_be_strict false \author -608949062 Rusty Russell,,, \author 1531152142 pbonzini +\author 2090695081 jason \end_header \begin_body @@ -4013,7 +4014,21 @@ layout Two configuration fields are currently defined. The mac address field always exists (though is only valid if VIRTIO_NET_F_MAC is set), and the status field only exists if VIRTIO_NET_F_STATUS is set. Two bits are currently defined for the status field: VIRTIO_NET_S_LINK_UP - and VIRTIO_NET_S_ANNOUNCE. + +\change_inserted 2090695081 1332220873 +(read-only) +\change_unchanged +and VIRTIO_NET_S_ANNOUNCE +\change_inserted 2090695081 1332220883 + (read-writable) +\change_unchanged +. + +\change_inserted 2090695081 1332220901 + Writing 1 to any read-writable bit of status filed would cause the bit + to be cleared. + +\change_unchanged \begin_inset listings inline false @@ -4915,7 +4930,11 @@ Processing this notification involves: \end_layout \begin_layout Enumerate -Clearing VIRTIO_NET_S_ANNOUNCE bit in the status field. +Clearing VIRTIO_NET_S_ANNOUNCE bit in the status field +\change_inserted 2090695081 1332220849 + (by writing 1 to VIRTIO_NET_S_ANNOUNCE bit) +\change_unchanged +. \end_layout \begin_layout Enumerate
[Qemu-devel] [Bug 959852] [NEW] Build fails: osx 10.7, deprecated CoreAudio APIs
Public bug reported: Virtual audio driver for darwin is using deprecated APIs. ○ → ./configure --cc=/usr/bin/gcc --disable-darwin-user --disable-bsd- user --disable-guest-agent ○ → make . . . CCaudio/noaudio.o CCaudio/wavaudio.o CCaudio/mixeng.o CCaudio/coreaudio.o audio/coreaudio.c: In function ‘isPlaying’: audio/coreaudio.c:152: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) audio/coreaudio.c: In function ‘coreaudio_init_out’: audio/coreaudio.c:310: warning: ‘AudioHardwareGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:1270) audio/coreaudio.c:326: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) audio/coreaudio.c:353: warning: ‘AudioDeviceSetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2675) audio/coreaudio.c:370: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) audio/coreaudio.c:386: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) audio/coreaudio.c:403: warning: ‘AudioDeviceSetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2675) audio/coreaudio.c:419: warning: ‘AudioDeviceAddIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2419) audio/coreaudio.c:431: warning: ‘AudioDeviceRemoveIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2433) audio/coreaudio.c: In function ‘coreaudio_fini_out’: audio/coreaudio.c:456: warning: ‘AudioDeviceRemoveIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2433) CCaudio/wavcapture.o ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/959852 Title: Build fails: osx 10.7, deprecated CoreAudio APIs Status in QEMU: New Bug description: Virtual audio driver for darwin is using deprecated APIs. ○ → ./configure --cc=/usr/bin/gcc --disable-darwin-user --disable-bsd- user --disable-guest-agent ○ → make . . . CCaudio/noaudio.o CCaudio/wavaudio.o CCaudio/mixeng.o CCaudio/coreaudio.o audio/coreaudio.c: In function ‘isPlaying’: audio/coreaudio.c:152: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) audio/coreaudio.c: In function ‘coreaudio_init_out’: audio/coreaudio.c:310: warning: ‘AudioHardwareGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:1270) audio/coreaudio.c:326: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) audio/coreaudio.c:353: warning: ‘AudioDeviceSetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2675) audio/coreaudio.c:370: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) audio/coreaudio.c:386: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) audio/coreaudio.c:403: warning: ‘AudioDeviceSetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2675) audio/coreaudio.c:419: warning: ‘AudioDeviceAddIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2419) audio/coreaudio.c:431: warning: ‘AudioDeviceRemoveIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2433) audio/coreaudio.c: In function ‘coreaudio_fini_out’: audio/coreaudio.c:456: warning: ‘AudioDeviceRemoveIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2433) CCaudio/wavcapture.o To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/959852/+subscriptions
Re: [Qemu-devel] [PATCH 2/6] Redesign of pciinit.c (take 2)
On 16/03/12 13:55, Kevin O'Connor wrote:
On Thu, Mar 15, 2012 at 04:29:30PM +1300, Alexey Korolev wrote:
On 14/03/12 13:48, Kevin O'Connor wrote:
On Tue, Mar 13, 2012 at 05:45:19PM +1300, Alexey Korolev wrote:
Added pci_region_entry structure and list operations to pciinit.c
List is filled with entries during pci_check_devices.
List is used just for printing space allocation if we were using lists.
Next step will resource allocation using mapping functions.
[...]
-struct {
-u32 addr;
-u32 size;
-int is64;
-} bars[PCI_NUM_REGIONS];
[...]
Yes I see what you mean here.
Thanks - I do find this patch much easier to understand. I do have
some comments on the patch (see below).
The code is being changed -
it's not new code being added and old code being deleted - the patches
need to reflect that.
Because of structural changes it is not possible to completely avoid
this scenario where new code is added and old deleted. In this
patch series I tried my best to make migration as obvious and safe
as possible. So the existing approach (with your suggestions) for
pciinit.c redesign is this:
1. Introduce list operations
2. Introduce pci_region_entry structure and add code which fills this new
structure.
We don't modify resource addresses calculations, but we use pci_region_entry
data to do resource assignment.
3. Modify resource addresses calculations to be based on linked lists of
region entries.
4. Remove code which fills the arrays, remove use of arrays for mapping.
(note 34 could be combined altogether but it will be harder to read then)
On patch 3/4, neither patch should introduce code that isn't actually
used nor leave code that isn't used still in. So, for example, if the
arrays are still used after patch 3 then it's okay to leave them to
patch 4, but if they are no longer used at all they should be removed
within patch 3.
Could you please have a look at the other parts in this series and
let me know if you are happy about this approach, so I won't have to
redo patchwork too many times?
patch 1/6 - I'd prefer to have a list.h with struct
hlist_head/hlist_node and container_of before extending to other
parts of seabios. That said, I'm okay with what you have for
pciinit - we can introduce list.h afterwards.
Then, it should be a separate patch. It's is better to do this afterwards.
patch 3/4 - was confusing to me as it added new code in one patch and
removed the replaced code in the second patch.
patch 5 - looked okay to me.
Thanks for looking at this - I know it's time consuming. Given the
churn in this area I want to make sure there is a good understanding
before any big changes.
comments on the patch:
[...]
+struct pci_region_entry *
+pci_region_create_entry(struct pci_bus *bus, struct pci_device *dev,
+ u32 size, int type, int is64bit)
+{
+struct pci_region_entry *entry= malloc_tmp(sizeof(*entry));
+if (!entry) {
+warn_noalloc();
+return NULL;
Minor - whitespace.
[...]
+static int pci_bios_check_devices(struct pci_bus *busses)
{
dprintf(1, PCI: check devices\n);
+struct pci_region_entry *entry;
// Calculate resources needed for regular (non-bus) devices.
struct pci_device *pci;
@@ -378,19 +419,27 @@ static void pci_bios_check_devices(struct pci_bus
*busses)
struct pci_bus *bus = busses[pci_bdf_to_bus(pci-bdf)];
int i;
for (i = 0; i PCI_NUM_REGIONS; i++) {
-u32 val, size;
+u32 val, size, min_size;
+int type, is64bit;
Minor - I prefer to use C99 inline variable declarations though it
isn't a requirement.
+min_size = (type == PCI_REGION_TYPE_IO) ?
(1PCI_IO_INDEX_SHIFT):
+ (1PCI_MEM_INDEX_SHIFT);
+size = (size min_size) ? size : min_size;
My only real comment: Why the min_size change? Is that a fix of some
sort or is it related to the move to lists?
This is a good question.
The min_size changes are to keep the exactly the same behaviour as the original
implementation,
when each PCI MEM bar is aligned to 4KB (1PCI_MEM_INDEX_SHIFT).
The PCI spec. doesn't state the 4KB align requirement.
So if this 4KB requirement is not coming from qemu, it makes sense to remove the
min_size changes. Probably it will be better to remove this as a separate
commit, to simplify
bug location in case of problems.
[...]
-
/
* Main setup code
Minor - whitespace change.
-Kevin
Re: [Qemu-devel] [PATCH 8/9] vl: add -query-capabilities
On 03/19/12 16:09, Anthony Liguori wrote: This dumps the results of query-version, query-commands, and query-config-capabilities into a single JSON object on stdout. I think libvirt needs a query-devices too. cheers, Gerd
Re: [Qemu-devel] [RFC PATCH 0/9] qemu capabilities reporting and config changes
Hi, I have a few patches here that convert almost every option that matters into QemuOpts so that -writeconfig records it: -m, -bios, -localtime, -S, -M, -smp, -numa, -nodefaults, -no-shutdown, -no-reboot. The only thing that is left basically is -display, where I chickened out. This series is complimentary to this. You can still promote options to QemuOpts. The advantage of this series is that we provide a programmatic way for libvirt to discover when this happens. It is still churn, especially considering that paolo has patches already. I'd suggest to go with your patches without [system] + paolo's QemuOpts convert patches, then stick the remaining bits (if any) into [system]. cheers, Gerd
Re: [Qemu-devel] [PATCH v4 0/9] VMXNET3 paravirtual NIC device implementation
Hello, Gerhard I've tested telnet connections on Knoppix running on QEMU-KVM with patch V5. Everything works fine on my setup. What is your network setup? How do you connect tap1 interface to the outer world? Also, since you have ping failure to init MSI-X is not related to the problem - device just falls back to MSI interrupts, but anyway, why does it fail? Could it be some QEMU/KVM versions incompartibility? Best regards, Dmitry Fleytman. On Mon, Mar 19, 2012 at 9:24 PM, Gerhard Wiesinger li...@wiesinger.com wrote: Hello Dmitry, Tried also v5 patch without success: /root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -drive if=ide,index=3,media=cdrom,file=ISO/KNOPPIX_V6.7.1CD-2011-09-14-DE.iso -boot order=cad,menu=on -m 2048 -k de -vga vmware -vnc :0 -bios /root/download/seabios/git/seabios/out/bios.bin -chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios -device vmxnet3,mac=1a:46:0b:ca:bc:7e,vlan=1,romfile= -net tap,ifname=tap1,script=no,downscript=no,vlan=1 ping ok, but outside tcp communication fails: # timeout Knoppix = outside telnet 192.168.0.2 22 # timeout outside = Knoppix failes telnet 192.168.0.30 22 RTL8139 with same command line is ok. Maybe that helps directly at startup: kvm_msix_vector_add: kvm_add_msix failed: No space left on device [vmxnet3][WR][vmxnet3_use_msix_vectors]: Failed to use MSI-X vector 9, error -28 [vmxnet3][WR][vmxnet3_init_msix]: Failed to use MSI-X vectors, error 0 [vmxnet3][WR][vmxnet3_pci_init]: Failed to initialize MSI-X, configuration is inconsistent. [vmxnet3][WR][vmxnet3_peer_has_vnet_hdr]: Peer has no virtio extension. Task offloads will be emulated. I'm using git qemu-kvm and not git qemu. Thnx. Ciao, Gerhard On 18.03.2012 16:30, Dmitry Fleytman wrote: Hello, Gerhard I've rechecked SSH connection both incoming and outgoing with patch v5. Everything works fine. If you still see problems, please, provide your exact configuration. Thanking you for your support, Dmitry Fleytman. On Sun, Mar 18, 2012 at 10:29 AM, Gerhard Wiesinger gerh...@wiesinger.com wrote: Hello, I'm still having problems with v4 patch: ping works well, even with large packet sizes but ssh doesn't work at all. Tested with Knoppix 6.7 and Fedora 16. Thnx. Ciao, Gerhard On 15.03.2012 22:08, Dmitry Fleytman wrote: This set of patches implements VMWare VMXNET3 paravirtual NIC device. The device supports of all the device features including offload capabilties, VLANs and etc. The device is tested on different OSes: Fedora 15 Ubuntu 10.4 Centos 6.2 Windows 2008R2 Windows 2008 64bit Windows 2008 32bit Windows 2003 64bit Windows 2003 32bit Changes in V4: Fixed a few problems uncovered by NETIO test suit Assertion on failure to initialize MSI/MSI-X replaced with warning message and fallback to Legacy/MSI respectively Reported-by: Gerhard Wiesingerli...@wiesinger.com Various coding style adjustments and patch split-up as suggested by Anthony Liguori Reported-by: Anthony Liguorialigu...@us.ibm.com Live migration support added Changes in V3: Fixed crash when net device that is used as network fronted has no virtio HDR support. Task offloads emulation for cases when net device that is used as network fronted has no virtio HDR support. Reported-by: Gerhard Wiesingerli...@wiesinger.com Changes in V2: License text changed accoring to community suggestions Standard license header from GPLv2+ - licensed QEMU files used Dmitry Fleytman (9): Adding missing flag VIRTIO_NET_HDR_F_DATA_VALID from Linux kernel source tre Reformatting comments according to checkpatch.pl requirements Adding utility function net_checksum_add_cont() that allows checksum calculation of scattered data with odd chunk sizes Adding utility function iov_net_csum_add() for iovec checksum calculation MSI-X state save/load invocations moved to PCI Device save/load callbacks to avoid code duplication in MSI-X-enabled devices that support live migration Header with various utility functions shared by VMWARE SCSI and network devi Various utility functions used by VMWARE network devices Packet abstraction used by VMWARE network devices VMXNET3 paravirtual device implementation VMXNET3 paravirtualized device integration. Interface type vmxnet3 added. Makefile.objs | 1 + default-configs/pci.mak | 1 + hw/pci.c | 7 + hw/pci.h | 1 + hw/virtio-net.h | 13 +- hw/virtio-pci.c | 2 - hw/vmware_utils.h | 122 +++ hw/vmxnet3.c | 2435 +++ hw/vmxnet3.h | 757 +++ hw/vmxnet_debug.h | 121 +++ hw/vmxnet_pkt.c | 1243 hw/vmxnet_pkt.h |
[Qemu-devel] [PATCH 00/12] convert many options to QemuOpts
This converts a lot of commonly-used options to QemuOpts. Most of them get in -machine, but I don't intend -machine to become a catch-all option. In fact I refrained from converting those that should go in -display (like -keyboard) or should be moved to enum device properties. With the exception of -display, now a more-or-less complete PC machine can be created from config. This is unfortunately not true of most embedded machines which use arrays such as serial_hd to create devices and do not support using -device instead. This does not mean that all options can be used. Only -monitor and -qmp create a backend/frontend pair in QemuOpts, so things such as -serial stdio will not work. Patch 1 is a bugfix, it was already submitted and informally approved by Blue. Paolo Bonzini (12): vga: disable default VGA if appropriate -device is used QemuOpts: use strtosz cmdline: implement -m with QemuOpts cmdline: implement -S with QemuOpts cmdline: implement -bios with QemuOpts cmdline: implement -localtime with QemuOpts cmdline: make -M a simple alias for -machine type cmdline: convert -smp to QemuOpts cmdline: reindent numa_add cmdline: convert -numa to QemuOpts cmdline: implement -nodefaults with qemuopts cmdline: convert -no-shutdown and -no-reboot to QemuOpts qemu-config.c | 78 +++ qemu-option.c | 41 ++-- vl.c| 289 ++- 3 files changed, 225 insertions(+), 183 deletions(-) -- 1.7.7.6
[Qemu-devel] [PATCH 05/12] cmdline: implement -bios with QemuOpts
This becomes -machine bios.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
qemu-config.c |4
vl.c |4 +++-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/qemu-config.c b/qemu-config.c
index 3a313de..89706df 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -563,6 +563,10 @@ static QemuOptsList qemu_machine_opts = {
.type = QEMU_OPT_BOOL,
.help = start machine immediately,
}, {
+.name = bios,
+.type = QEMU_OPT_STRING,
+.help = BIOS/firmware file,
+}, {
.name = kernel_irqchip,
.type = QEMU_OPT_BOOL,
.help = use KVM in-kernel irqchip,
diff --git a/vl.c b/vl.c
index 52a0ea6..54c5d79 100644
--- a/vl.c
+++ b/vl.c
@@ -2677,7 +2677,7 @@ int main(int argc, char **argv, char **envp)
data_dir = optarg;
break;
case QEMU_OPTION_bios:
-bios_name = optarg;
+qemu_opts_set(qemu_find_opts(machine), 0, bios, optarg);
break;
case QEMU_OPTION_singlestep:
singlestep = 1;
@@ -3313,10 +3313,12 @@ int main(int argc, char **argv, char **envp)
}
machine_opts = qemu_opts_find(qemu_find_opts(machine), 0);
+bios_name = NULL;
kernel_filename = initrd_filename = kernel_cmdline = NULL;
ram_size = DEFAULT_RAM_SIZE * 1024 * 1024;
if (machine_opts) {
autostart = qemu_opt_get_bool(machine_opts, autostart, true);
+bios_name = qemu_opt_get(machine_opts, bios);
ram_size = qemu_opt_get_size(machine_opts, ram_size, ram_size);
kernel_filename = qemu_opt_get(machine_opts, kernel);
initrd_filename = qemu_opt_get(machine_opts, initrd);
--
1.7.7.6
[Qemu-devel] [PATCH 12/12] cmdline: convert -no-shutdown and -no-reboot to QemuOpts
They are also moved inside -machine.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
qemu-config.c |8
vl.c|6 --
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/qemu-config.c b/qemu-config.c
index 6e97ff6..e901826 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -568,6 +568,14 @@ static QemuOptsList qemu_machine_opts = {
.type = QEMU_OPT_BOOL,
.help = start machine immediately,
}, {
+.name = no_reboot,
+.type = QEMU_OPT_BOOL,
+.help = exit instead of rebooting,
+}, {
+.name = no_shutdown,
+.type = QEMU_OPT_BOOL,
+.help = stop before shutdown,
+}, {
.name = bios,
.type = QEMU_OPT_STRING,
.help = BIOS/firmware file,
diff --git a/vl.c b/vl.c
index aa324ed..b2a69a5 100644
--- a/vl.c
+++ b/vl.c
@@ -2990,10 +2990,10 @@ int main(int argc, char **argv, char **envp)
}
break;
case QEMU_OPTION_no_reboot:
-no_reboot = 1;
+qemu_opts_set(qemu_find_opts(machine), 0, no_reboot, on);
break;
case QEMU_OPTION_no_shutdown:
-no_shutdown = 1;
+qemu_opts_set(qemu_find_opts(machine), 0, no_shutdown,
on);
break;
case QEMU_OPTION_show_cursor:
cursor_hide = 0;
@@ -3309,6 +3309,8 @@ int main(int argc, char **argv, char **envp)
kernel_filename = initrd_filename = kernel_cmdline = NULL;
ram_size = DEFAULT_RAM_SIZE * 1024 * 1024;
if (machine_opts) {
+no_reboot = qemu_opt_get_bool(machine_opts, no_reboot, false);
+no_shutdown = qemu_opt_get_bool(machine_opts, no_shutdown, false);
autostart = qemu_opt_get_bool(machine_opts, autostart, true);
bios_name = qemu_opt_get(machine_opts, bios);
ram_size = qemu_opt_get_size(machine_opts, ram_size, ram_size);
--
1.7.7.6
[Qemu-devel] [PATCH 02/12] QemuOpts: use strtosz
This will simplify conversion of -numa node,mem=... and -m to QemuOpts.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
qemu-option.c | 41 ++---
1 files changed, 10 insertions(+), 31 deletions(-)
diff --git a/qemu-option.c b/qemu-option.c
index 35cd609..55cbee8 100644
--- a/qemu-option.c
+++ b/qemu-option.c
@@ -204,41 +204,20 @@ static int parse_option_number(const char *name, const
char *value, uint64_t *re
return 0;
}
-static int parse_option_size(const char *name, const char *value, uint64_t
*ret)
+static int parse_option_size(const char *name, const char *value,
+ const char default_suffix, uint64_t *ret)
{
char *postfix;
-double sizef;
+int64_t size;
-if (value != NULL) {
-sizef = strtod(value, postfix);
-switch (*postfix) {
-case 'T':
-sizef *= 1024;
-/* fall through */
-case 'G':
-sizef *= 1024;
-/* fall through */
-case 'M':
-sizef *= 1024;
-/* fall through */
-case 'K':
-case 'k':
-sizef *= 1024;
-/* fall through */
-case 'b':
-case '\0':
-*ret = (uint64_t) sizef;
-break;
-default:
-qerror_report(QERR_INVALID_PARAMETER_VALUE, name, a size);
-error_printf_unless_qmp(You may use k, M, G or T suffixes for
-kilobytes, megabytes, gigabytes and terabytes.\n);
-return -1;
-}
-} else {
+size = strtosz_suffix(value, postfix, default_suffix);
+if (size 0 || *postfix) {
qerror_report(QERR_INVALID_PARAMETER_VALUE, name, a size);
+error_printf_unless_qmp(You may use k, M, G or T suffixes for
+kilobytes, megabytes, gigabytes and terabytes.\n);
return -1;
}
+*ret = size;
return 0;
}
@@ -289,7 +268,7 @@ int set_option_parameter(QEMUOptionParameter *list, const
char *name,
break;
case OPT_SIZE:
-if (parse_option_size(name, value, list-value.n) == -1)
+if (parse_option_size(name, value, 'B', list-value.n) == -1)
return -1;
break;
@@ -589,7 +568,7 @@ static int qemu_opt_parse(QemuOpt *opt)
case QEMU_OPT_NUMBER:
return parse_option_number(opt-name, opt-str, opt-value.uint);
case QEMU_OPT_SIZE:
-return parse_option_size(opt-name, opt-str, opt-value.uint);
+return parse_option_size(opt-name, opt-str, 'M', opt-value.uint);
default:
abort();
}
--
1.7.7.6
[Qemu-devel] [PATCH 09/12] cmdline: reindent numa_add
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
vl.c | 72 +-
1 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/vl.c b/vl.c
index ce55468..d9a9cac 100644
--- a/vl.c
+++ b/vl.c
@@ -950,49 +950,49 @@ static void numa_add(const char *optarg)
int nodenr;
optarg = get_opt_name(option, 128, optarg, ',') + 1;
-if (!strcmp(option, node)) {
-if (get_param_value(option, 128, nodeid, optarg) == 0) {
-nodenr = nb_numa_nodes;
-} else {
-nodenr = strtoull(option, NULL, 10);
-}
+if (strcmp(option, node)) {
+return;
+}
+if (get_param_value(option, 128, nodeid, optarg) == 0) {
+nodenr = nb_numa_nodes;
+} else {
+nodenr = strtoull(option, NULL, 10);
+}
-if (get_param_value(option, 128, mem, optarg) == 0) {
-node_mem[nodenr] = 0;
-} else {
-int64_t sval;
-sval = strtosz(option, endptr);
-if (sval 0 || *endptr) {
-fprintf(stderr, qemu: invalid numa mem size: %s\n, optarg);
-exit(1);
-}
-node_mem[nodenr] = sval;
+if (get_param_value(option, 128, mem, optarg) == 0) {
+node_mem[nodenr] = 0;
+} else {
+int64_t sval;
+sval = strtosz(option, endptr);
+if (sval 0 || *endptr) {
+fprintf(stderr, qemu: invalid numa mem size: %s\n, optarg);
+exit(1);
}
-if (get_param_value(option, 128, cpus, optarg) == 0) {
-node_cpumask[nodenr] = 0;
+node_mem[nodenr] = sval;
+}
+if (get_param_value(option, 128, cpus, optarg) == 0) {
+node_cpumask[nodenr] = 0;
+} else {
+value = strtoull(option, endptr, 10);
+if (value = 64) {
+value = 63;
+fprintf(stderr, only 64 CPUs in NUMA mode supported.\n);
} else {
-value = strtoull(option, endptr, 10);
-if (value = 64) {
-value = 63;
-fprintf(stderr, only 64 CPUs in NUMA mode supported.\n);
-} else {
-if (*endptr == '-') {
-endvalue = strtoull(endptr+1, endptr, 10);
-if (endvalue = 63) {
-endvalue = 62;
-fprintf(stderr,
-only 63 CPUs in NUMA mode supported.\n);
-}
-value = (2ULL endvalue) - (1ULL value);
-} else {
-value = 1ULL value;
+if (*endptr == '-') {
+endvalue = strtoull(endptr+1, endptr, 10);
+if (endvalue = 63) {
+endvalue = 62;
+fprintf(stderr,
+only 63 CPUs in NUMA mode supported.\n);
}
+value = (2ULL endvalue) - (1ULL value);
+} else {
+value = 1ULL value;
}
-node_cpumask[nodenr] = value;
}
-nb_numa_nodes++;
+node_cpumask[nodenr] = value;
}
-return;
+nb_numa_nodes++;
}
static int smp_init_func(QemuOpts *opts, void *opaque)
--
1.7.7.6
Re: [Qemu-devel] help with helper functions
On 19 March 2012 22:34, João Corrêa joao.l...@gmail.com wrote:
I'm trying to use some helper functions to instrument translated code, but
I'm getting some segfaults while doing it. Here are some code I've placed:
target-i386/helper.h
DEF_HELPER_1(foo, void, tl)
target-i386/op_helper.c
#ifdef TARGET_X86_64
void foo(target_ulong t0){
Should be
HELPER(foo)(target_ulong t0) {
}
target-i386/translate.c
static inline void gen_jmp_im(target_ulong pc){
#ifdef TARGET_X86_64
printf(test2\n);
gen_foo(pc);
should be gen_helper_foo().
But your main problem here is that gen_helper_*() take TCGv
types (TCG values), not immediate constants. You need to emit
TCG code to load 'pc' into a TCG temporary first.
If you configure --enable-debug then it ought to put in some
extra typechecking code which will make this fail compilation.
-- PMM
[Qemu-devel] [PATCH 10/12] cmdline: convert -numa to QemuOpts
This requires some special casing to skip the fake node option and
to handle the automatic -numa node syntax. Besides this, the option
parsing maps easily to QemuOpts.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
qemu-config.c | 22 ++
vl.c | 50 +-
2 files changed, 47 insertions(+), 25 deletions(-)
diff --git a/qemu-config.c b/qemu-config.c
index c1a4642..f5cf56b 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -630,6 +630,27 @@ QemuOptsList qemu_smp_opts = {
},
};
+QemuOptsList qemu_numa_opts = {
+.name = numa,
+.head = QTAILQ_HEAD_INITIALIZER(qemu_numa_opts.head),
+.desc = {
+{
+.name = nodeid,
+.type = QEMU_OPT_NUMBER,
+.help = Numeric identifier for the node,
+}, {
+.name = mem,
+.type = QEMU_OPT_SIZE,
+.help = Amount of memory for this node,
+}, {
+.name = cpus,
+.type = QEMU_OPT_STRING,
+.help = Identifier or range of identifiers for CPUs in this node,
+},
+{ /*End of list */ }
+},
+};
+
QemuOptsList qemu_boot_opts = {
.name = boot-opts,
.head = QTAILQ_HEAD_INITIALIZER(qemu_boot_opts.head),
@@ -670,6 +691,7 @@ static QemuOptsList *vm_config_groups[32] = {
qemu_option_rom_opts,
qemu_machine_opts,
qemu_smp_opts,
+qemu_numa_opts,
qemu_boot_opts,
qemu_iscsi_opts,
NULL,
diff --git a/vl.c b/vl.c
index d9a9cac..b485f4c 100644
--- a/vl.c
+++ b/vl.c
@@ -942,41 +942,29 @@ char *get_boot_devices_list(uint32_t *size)
return list;
}
-static void numa_add(const char *optarg)
+static int numa_add(QemuOpts *opts, void *opaque)
{
-char option[128];
+const char *option;
char *endptr;
unsigned long long value, endvalue;
int nodenr;
-optarg = get_opt_name(option, 128, optarg, ',') + 1;
-if (strcmp(option, node)) {
-return;
-}
-if (get_param_value(option, 128, nodeid, optarg) == 0) {
-nodenr = nb_numa_nodes;
-} else {
-nodenr = strtoull(option, NULL, 10);
+nodenr = qemu_opt_get_number(opts, nodeid, nb_numa_nodes);
+if (nodenr = MAX_NODES) {
+fprintf(stderr, only %d NUMA nodes supported.\n, MAX_NODES);
+return 1;
}
-if (get_param_value(option, 128, mem, optarg) == 0) {
-node_mem[nodenr] = 0;
-} else {
-int64_t sval;
-sval = strtosz(option, endptr);
-if (sval 0 || *endptr) {
-fprintf(stderr, qemu: invalid numa mem size: %s\n, optarg);
-exit(1);
-}
-node_mem[nodenr] = sval;
-}
-if (get_param_value(option, 128, cpus, optarg) == 0) {
-node_cpumask[nodenr] = 0;
-} else {
+node_mem[nodenr] = qemu_opt_get_size(opts, mem, 0);
+node_cpumask[nodenr] = 0;
+
+option = qemu_opt_get(opts, cpus);
+if (option) {
value = strtoull(option, endptr, 10);
if (value = 64) {
value = 63;
fprintf(stderr, only 64 CPUs in NUMA mode supported.\n);
+return 1;
} else {
if (*endptr == '-') {
endvalue = strtoull(endptr+1, endptr, 10);
@@ -984,6 +972,7 @@ static void numa_add(const char *optarg)
endvalue = 62;
fprintf(stderr,
only 63 CPUs in NUMA mode supported.\n);
+return 1;
}
value = (2ULL endvalue) - (1ULL value);
} else {
@@ -993,6 +982,7 @@ static void numa_add(const char *optarg)
node_cpumask[nodenr] = value;
}
nb_numa_nodes++;
+return 0;
}
static int smp_init_func(QemuOpts *opts, void *opaque)
@@ -2493,7 +2483,13 @@ int main(int argc, char **argv, char **envp)
fprintf(stderr, qemu: too many NUMA nodes\n);
exit(1);
}
-numa_add(optarg);
+if (strcmp(optarg, node) == 0) {
+qemu_opts_create(qemu_find_opts(numa), NULL, 0);
+} else if (memcmp(optarg, node,, 5) == 0) {
+qemu_opts_parse(qemu_find_opts(numa), optarg + 5, 0);
+} else {
+fprintf(stderr, qemu: expected 'node', -numa ignored\n);
+}
break;
case QEMU_OPTION_display:
display_type = select_display(optarg);
@@ -3234,6 +3230,10 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
+if (qemu_opts_foreach(qemu_find_opts(numa), numa_add, NULL, 1) != 0) {
+exit(1);
+}
+
/*
* Get the default machine options from the machine if it is not already
* specified either by the configuration file or by the command line.
--
1.7.7.6
[Qemu-devel] [Bug 932487] Re: win32: git rev 59f971d crashes when accessing disk (coroutine issue)
coroutine issue again, when booting tinycore_3.3.iso: C:\msys\home\User\qemu\i386-softmmugdb --args qemu-system-i386.exe -L ..\pc-bios -cdrom tinycore_3.3.iso GNU gdb (GDB) 7.3 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as mingw32. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe... done. (gdb) r Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L .. \\pc-bios -cdrom tinycore_3.3.iso [New Thread 10072.0x2318] [New Thread 10072.0x2050] [New Thread 10072.0x29fc] *** stack smashing detected ***: terminated Program received signal SIGILL, Illegal instruction. [Switching to Thread 10072.0x29fc] 0x00634a4a in fail.isra.0 () (gdb) bt #0 0x00634a4a in fail.isra.0 () #1 0x00634ab2 in __stack_chk_fail () #2 0xa6782315 in ?? () #3 0x0bda in ?? () #4 0x0001 in ?? () #5 0x0044b9b9 in qemu_coroutine_switch (from_=0x22f848, to_=0x7c92e920, action=0) at coroutine-win32.c:50 #6 0x000cef9f in ?? () #7 0x0022f848 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) http://www.mail-archive.com/qemu-devel@nongnu.org/msg103426.html may refer to this too. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/932487 Title: win32: git rev 59f971d crashes when accessing disk (coroutine issue) Status in QEMU: Confirmed Bug description: Host: XP SP3 / Vista SP2 configure commandline: ./configure --target-list=i386-softmmu --audio-drv-list=sdl --audio-card-list=ac97,sb16,adlib --disable- linux-aio --disable-vnc-thread --disable-vnc-jpeg --extra-cflags=-O0 -pipe gcc -v: Using built-in specs. Target: mingw32 Configured with: ../gcc-4.3.3/configure --prefix=/mingw --build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ --with-bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls --disable-win32-registry --enable-libgomp --disable-werror --enable-threads --disable-symvers --enable-cxx-flags='-fno-function-sections -fno-data-sections' --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --with-pkgversion='4.3.3-tdm-1 mingw32' Thread model: win32 gcc version 4.3.3 (4.3.3-tdm-1 mingw32) gdb output: C:\msys\home\User\qemu\i386-softmmugdb --args qemu-system-i386.exe -L ..\pc-bios -hda xp.vmdk GNU gdb (GDB) 7.3 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as mingw32. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe... done. (gdb) r Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L ..\\pc-bios -hda xp.vmdk [New Thread 2472.0x8e0] [New Thread 2472.0xdc4] [New Thread 2472.0x8f0] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 2472.0x8f0] 0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll (gdb) bt #0 0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll #1 0x0044774c in qemu_coroutine_switch (from_=0x19593fc, to_=0xdcee9a8, action=COROUTINE_YIELD) at coroutine-win32.c:48 #2 0x004db18d in coroutine_swap (from=0x1e00, to=0xdcee9a8) at qemu-coroutine.c:31 #3 0x00411618 in bdrv_rw_co (bs=optimized out, sector_num=optimized out, buf=0x214 @, nb_sectors=1, is_write=false) at block.c:1335 #4 0x00486e39 in ide_sector_read (s=0x1bbdaa0) at C:/msys/home/User/qemu/hw/ide/core.c:480 #5 0x0054e71f in memory_region_iorange_write (iorange=0x1bbcf60, offset=7, width=1, data=32) at C:/msys/home/User/qemu/memory.c:431 #6 0x005494e0 in ioport_writeb_thunk (opaque=0x1bbcf60, addr=7680, data=32) at C:/msys/home/User/qemu/ioport.c:211 #7 0x005496cf in ioport_write (data=optimized out, address=optimized out, index=optimized out) at C:/msys/home/User/qemu/ioport.c:82 #8 cpu_outb (addr=2147340288, val=0 '\000') at C:/msys/home/User/qemu/ioport.c:274 #9 0x022c0397 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/932487/+subscriptions
Re: [Qemu-devel] How many floppy can a computer install ? Thank you very much!
On 03/20/2012 10:34 AM, Zhi Hui Li wrote: Hi,Zhi Hui I am not very sure,but I think it is 2. -- Best Regards, Cao,Bing Bu
[Qemu-devel] [Bug 959992] [NEW] segfault in apic_report_irq_delivered when booting tinycore_3.3.iso
Public bug reported:
it git head (33cf629) sometimes it segfaults in
apic_report_irq_delivered() and backtrace is looping in
apic_update_irq(#3-#4)
Log:
C:\msys\home\User\qemu\i386-softmmugdb --args qemu-system-i386.exe -L
..\pc-bios -cdrom tinycore_3.3.iso
GNU gdb (GDB) 7.3
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as mingw32.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe...
done.
(gdb) r
Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L
..\\pc-bios -cdrom tinycore_3.3.iso
[New Thread 9012.0x2348]
[New Thread 9012.0x2860]
[New Thread 9012.0x2b64]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 9012.0x2b64]
0x0053cde8 in apic_report_irq_delivered (delivered=0)
at C:/msys/home/User/qemu/hw/apic_common.c:110
110 {
(gdb) bt
#0 0x0053cde8 in apic_report_irq_delivered (delivered=0)
at C:/msys/home/User/qemu/hw/apic_common.c:110
#1 0x0053b9eb in apic_set_irq (s=0x1d7aff8, vector_num=optimized out,
trigger_mode=0) at C:/msys/home/User/qemu/hw/apic.c:390
#2 0x0053b990 in apic_update_irq (s=0x1d7aff8)
at C:/msys/home/User/qemu/hw/apic.c:376
#3 apic_update_irq (s=0x1d7aff8) at C:/msys/home/User/qemu/hw/apic.c:367
#4 0x0053b990 in apic_update_irq (s=0x1d7aff8)
at C:/msys/home/User/qemu/hw/apic.c:376
#5 apic_update_irq (s=0x1d7aff8) at C:/msys/home/User/qemu/hw/apic.c:367
#6 0x0053b990 in apic_update_irq (s=0x1d7aff8)
at C:/msys/home/User/qemu/hw/apic.c:376
#7 apic_update_irq (s=0x1d7aff8) at C:/msys/home/User/qemu/hw/apic.c:367
...
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/959992
Title:
segfault in apic_report_irq_delivered when booting tinycore_3.3.iso
Status in QEMU:
New
Bug description:
it git head (33cf629) sometimes it segfaults in
apic_report_irq_delivered() and backtrace is looping in
apic_update_irq(#3-#4)
Log:
C:\msys\home\User\qemu\i386-softmmugdb --args qemu-system-i386.exe -L
..\pc-bios -cdrom tinycore_3.3.iso
GNU gdb (GDB) 7.3
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as mingw32.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from
C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe...
done.
(gdb) r
Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L
..\\pc-bios -cdrom tinycore_3.3.iso
[New Thread 9012.0x2348]
[New Thread 9012.0x2860]
[New Thread 9012.0x2b64]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 9012.0x2b64]
0x0053cde8 in apic_report_irq_delivered (delivered=0)
at C:/msys/home/User/qemu/hw/apic_common.c:110
110 {
(gdb) bt
#0 0x0053cde8 in apic_report_irq_delivered (delivered=0)
at C:/msys/home/User/qemu/hw/apic_common.c:110
#1 0x0053b9eb in apic_set_irq (s=0x1d7aff8, vector_num=optimized out,
trigger_mode=0) at C:/msys/home/User/qemu/hw/apic.c:390
#2 0x0053b990 in apic_update_irq (s=0x1d7aff8)
at C:/msys/home/User/qemu/hw/apic.c:376
#3 apic_update_irq (s=0x1d7aff8) at C:/msys/home/User/qemu/hw/apic.c:367
#4 0x0053b990 in apic_update_irq (s=0x1d7aff8)
at C:/msys/home/User/qemu/hw/apic.c:376
#5 apic_update_irq (s=0x1d7aff8) at C:/msys/home/User/qemu/hw/apic.c:367
#6 0x0053b990 in apic_update_irq (s=0x1d7aff8)
at C:/msys/home/User/qemu/hw/apic.c:376
#7 apic_update_irq (s=0x1d7aff8) at C:/msys/home/User/qemu/hw/apic.c:367
...
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/959992/+subscriptions
[Qemu-devel] [PATCH 03/12] cmdline: implement -m with QemuOpts
This becomes -machine ram_size.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
qemu-config.c |4
vl.c | 41 -
2 files changed, 16 insertions(+), 29 deletions(-)
diff --git a/qemu-config.c b/qemu-config.c
index be84a03..6569acd 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -582,6 +582,10 @@ static QemuOptsList qemu_machine_opts = {
.name = dtb,
.type = QEMU_OPT_STRING,
.help = Linux kernel device tree file,
+}, {
+.name = ram_size,
+.type = QEMU_OPT_SIZE,
+.help = RAM size,
},
{ /* End of list */ }
},
diff --git a/vl.c b/vl.c
index fd394c8..70c22dc 100644
--- a/vl.c
+++ b/vl.c
@@ -2650,20 +2650,7 @@ int main(int argc, char **argv, char **envp)
exit(0);
break;
case QEMU_OPTION_m: {
-int64_t value;
-char *end;
-
-value = strtosz(optarg, end);
-if (value 0 || *end) {
-fprintf(stderr, qemu: invalid ram size: %s\n, optarg);
-exit(1);
-}
-
-if (value != (uint64_t)(ram_addr_t)value) {
-fprintf(stderr, qemu: ram size too large\n);
-exit(1);
-}
-ram_size = value;
+qemu_opts_set(qemu_find_opts(machine), 0, ram_size,
optarg);
break;
}
case QEMU_OPTION_mempath:
@@ -3325,26 +3312,14 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
-/* init the memory */
-if (ram_size == 0) {
-ram_size = DEFAULT_RAM_SIZE * 1024 * 1024;
-}
-
-configure_accelerator();
-
-qemu_init_cpu_loop();
-if (qemu_init_main_loop()) {
-fprintf(stderr, qemu_init_main_loop failed\n);
-exit(1);
-}
-
machine_opts = qemu_opts_find(qemu_find_opts(machine), 0);
+kernel_filename = initrd_filename = kernel_cmdline = NULL;
+ram_size = DEFAULT_RAM_SIZE * 1024 * 1024;
if (machine_opts) {
+ram_size = qemu_opt_get_size(machine_opts, ram_size, ram_size);
kernel_filename = qemu_opt_get(machine_opts, kernel);
initrd_filename = qemu_opt_get(machine_opts, initrd);
kernel_cmdline = qemu_opt_get(machine_opts, append);
-} else {
-kernel_filename = initrd_filename = kernel_cmdline = NULL;
}
if (!kernel_cmdline) {
@@ -3368,6 +3343,14 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
+configure_accelerator();
+
+qemu_init_cpu_loop();
+if (qemu_init_main_loop()) {
+fprintf(stderr, qemu_init_main_loop failed\n);
+exit(1);
+}
+
os_set_line_buffering();
if (init_timer_alarm() 0) {
--
1.7.7.6
Re: [Qemu-devel] [PATCH] readconfig: add emulation of /dev/fd/ to platforms that that lacks this API
None. No platforms that I care about. On Tue, Mar 20, 2012 at 3:43 AM, Anthony Liguori anth...@codemonkey.ws wrote: On 03/03/2012 01:49 AM, Ronnie Sahlberg wrote: Please find a patch to -readconfig. On many platforms -readconfig /dev/fd/n can be used to read from an already opened and inherited filedescriptorn. On platforms that do not natively provide /dev/fd/n What platforms don't provide /dev/fd/n where fd passing makes sense? Regards, Anthony Liguori add emulation of this by checking if the ofiginal fopen(path) failed, then IF the path starts with /dev/fd/ then try to read the descriptorvalue and fdopen() it. It means that we can use -readconfig /dev/fd/n on all platforms. On those that provide a /dev/fd we just open that file. On those that do not we emulate it. regards ronnie sahlberg
[Qemu-devel] [PATCH 04/12] cmdline: implement -S with QemuOpts
This becomes -machine autostart.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
qemu-config.c |4
vl.c |3 ++-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/qemu-config.c b/qemu-config.c
index 6569acd..3a313de 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -559,6 +559,10 @@ static QemuOptsList qemu_machine_opts = {
.type = QEMU_OPT_STRING,
.help = accelerator list,
}, {
+.name = autostart,
+.type = QEMU_OPT_BOOL,
+.help = start machine immediately,
+}, {
.name = kernel_irqchip,
.type = QEMU_OPT_BOOL,
.help = use KVM in-kernel irqchip,
diff --git a/vl.c b/vl.c
index 70c22dc..52a0ea6 100644
--- a/vl.c
+++ b/vl.c
@@ -2683,7 +2683,7 @@ int main(int argc, char **argv, char **envp)
singlestep = 1;
break;
case QEMU_OPTION_S:
-autostart = 0;
+qemu_opts_set(qemu_find_opts(machine), 0, autostart,
off);
break;
case QEMU_OPTION_k:
keyboard_layout = optarg;
@@ -3316,6 +3316,7 @@ int main(int argc, char **argv, char **envp)
kernel_filename = initrd_filename = kernel_cmdline = NULL;
ram_size = DEFAULT_RAM_SIZE * 1024 * 1024;
if (machine_opts) {
+autostart = qemu_opt_get_bool(machine_opts, autostart, true);
ram_size = qemu_opt_get_size(machine_opts, ram_size, ram_size);
kernel_filename = qemu_opt_get(machine_opts, kernel);
initrd_filename = qemu_opt_get(machine_opts, initrd);
--
1.7.7.6
[Qemu-devel] [PATCH 08/12] cmdline: convert -smp to QemuOpts
This introduces a new option group, but it is mostly trivial.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
qemu-config.c | 31 +
vl.c | 61 +---
2 files changed, 58 insertions(+), 34 deletions(-)
diff --git a/qemu-config.c b/qemu-config.c
index 8f0923e..c1a4642 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -600,6 +600,36 @@ static QemuOptsList qemu_machine_opts = {
},
};
+QemuOptsList qemu_smp_opts = {
+.name = smp,
+.head = QTAILQ_HEAD_INITIALIZER(qemu_smp_opts.head),
+.implied_opt_name = cpus,
+.desc = {
+{
+.name = cpus,
+.type = QEMU_OPT_NUMBER,
+.help = Number of CPUs,
+}, {
+.name = sockets,
+.type = QEMU_OPT_NUMBER,
+.help = Number of sockets,
+}, {
+.name = cores,
+.type = QEMU_OPT_NUMBER,
+.help = Number of cores per socket,
+}, {
+.name = threads,
+.type = QEMU_OPT_NUMBER,
+.help = Number of simultaneous threads per core,
+}, {
+.name = maxcpus,
+.type = QEMU_OPT_NUMBER,
+.help = Maximum number of pluggable CPUs,
+},
+{ /*End of list */ }
+},
+};
+
QemuOptsList qemu_boot_opts = {
.name = boot-opts,
.head = QTAILQ_HEAD_INITIALIZER(qemu_boot_opts.head),
@@ -639,6 +669,7 @@ static QemuOptsList *vm_config_groups[32] = {
qemu_trace_opts,
qemu_option_rom_opts,
qemu_machine_opts,
+qemu_smp_opts,
qemu_boot_opts,
qemu_iscsi_opts,
NULL,
diff --git a/vl.c b/vl.c
index 1fc5044..ce55468 100644
--- a/vl.c
+++ b/vl.c
@@ -995,26 +995,15 @@ static void numa_add(const char *optarg)
return;
}
-static void smp_parse(const char *optarg)
+static int smp_init_func(QemuOpts *opts, void *opaque)
{
int smp, sockets = 0, threads = 0, cores = 0;
-char *endptr;
-char option[128];
-smp = strtoul(optarg, endptr, 10);
-if (endptr != optarg) {
-if (*endptr == ',') {
-endptr++;
-}
-}
-if (get_param_value(option, 128, sockets, endptr) != 0)
-sockets = strtoull(option, NULL, 10);
-if (get_param_value(option, 128, cores, endptr) != 0)
-cores = strtoull(option, NULL, 10);
-if (get_param_value(option, 128, threads, endptr) != 0)
-threads = strtoull(option, NULL, 10);
-if (get_param_value(option, 128, maxcpus, endptr) != 0)
-max_cpus = strtoull(option, NULL, 10);
+smp = qemu_opt_get_number(opts, cpus, 0);
+sockets = qemu_opt_get_number(opts, sockets, 0);
+cores = qemu_opt_get_number(opts, cores, 0);
+threads = qemu_opt_get_number(opts, threads, 0);
+max_cpus = qemu_opt_get_number(opts, maxcpus, 0);
/* compute missing values, prefer sockets over cores over threads */
if (smp == 0 || sockets == 0) {
@@ -1035,8 +1024,22 @@ static void smp_parse(const char *optarg)
smp_cpus = smp;
smp_cores = cores 0 ? cores : 1;
smp_threads = threads 0 ? threads : 1;
-if (max_cpus == 0)
+if (max_cpus == 0) {
max_cpus = smp_cpus;
+}
+if (smp_cpus 1) {
+fprintf(stderr, Invalid number of CPUs\n);
+return 1;
+}
+if (max_cpus smp_cpus) {
+fprintf(stderr, maxcpus must be equal to or greater than cpus\n);
+return 1;
+}
+if (max_cpus 255) {
+fprintf(stderr, Unsupported number of maxcpus\n);
+return 1;
+}
+return 0;
}
/***/
@@ -2967,20 +2970,7 @@ int main(int argc, char **argv, char **envp)
}
break;
case QEMU_OPTION_smp:
-smp_parse(optarg);
-if (smp_cpus 1) {
-fprintf(stderr, Invalid number of CPUs\n);
-exit(1);
-}
-if (max_cpus smp_cpus) {
-fprintf(stderr, maxcpus must be equal to or greater than
-smp\n);
-exit(1);
-}
-if (max_cpus 255) {
-fprintf(stderr, Unsupported number of maxcpus\n);
-exit(1);
-}
+qemu_opts_parse(qemu_find_opts(smp), optarg, 1);
break;
case QEMU_OPTION_vnc:
#ifdef CONFIG_VNC
@@ -3230,9 +3220,12 @@ int main(int argc, char **argv, char **envp)
* Default to max_cpus = smp_cpus, in case the user doesn't
* specify a max_cpus value.
*/
-if (!max_cpus)
+if (qemu_opts_foreach(qemu_find_opts(smp), smp_init_func, NULL, 1) != 0)
{
+exit(1);
+}
+if (!max_cpus) {
max_cpus = smp_cpus;
-
+}
machine-max_cpus = machine-max_cpus ?: 1; /* Default to UP */
if (smp_cpus machine-max_cpus) {
fprintf(stderr, Number
[Qemu-devel] KVM call agenda for Tuesday 20th
Hi Please send in any agenda items you are interested in covering. Cheers, Juan.
[Qemu-devel] [PATCH 01/12] vga: disable default VGA if appropriate -device is used
This is a partial revert of commits a369da5 (vga: improve VGA logic,
committed 2012-01-22) and c5bd4f3 (vga: fix -nodefaults -device VGA,
2012-01-24) which broke command-line option parsing in different ways.
Since commit a369da5 it has become impossible to specify a VGA device
entirely with QemuOpts-enabled options, i.e. without needing an explicit
-vga none.
In addition, until commit c5bd4f3 -nodefaults would not disable the device
you specified with the legacy -vga option, independent of the order.
Since commit c5bd4f3 QEMU -nodefaults will override a previous -vga
option.
I did not reintroduce machine-no_vga. Boards can simply ignore the
vga_interface_type variable, and most will indeed do so.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
vl.c | 25 -
1 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/vl.c b/vl.c
index 65f11f2..fd394c8 100644
--- a/vl.c
+++ b/vl.c
@@ -272,6 +272,7 @@ static int default_monitor = 1;
static int default_floppy = 1;
static int default_cdrom = 1;
static int default_sdcard = 1;
+static int default_vga = 1;
static struct {
const char *driver;
@@ -287,6 +288,12 @@ static struct {
{ .driver = virtio-serial-pci,.flag = default_virtcon },
{ .driver = virtio-serial-s390, .flag = default_virtcon },
{ .driver = virtio-serial,.flag = default_virtcon },
+{ .driver = VGA, .flag = default_vga },
+{ .driver = isa-vga, .flag = default_vga },
+{ .driver = cirrus-vga, .flag = default_vga },
+{ .driver = isa-cirrus-vga, .flag = default_vga },
+{ .driver = vmware-svga, .flag = default_vga },
+{ .driver = qxl-vga, .flag = default_vga },
};
static void res_free(void)
@@ -2269,7 +2276,7 @@ int main(int argc, char **argv, char **envp)
const char *loadvm = NULL;
QEMUMachine *machine;
const char *cpu_model;
-const char *vga_model = NULL;
+const char *vga_model = none;
const char *pid_file = NULL;
const char *incoming = NULL;
#ifdef CONFIG_VNC
@@ -2699,6 +2706,7 @@ int main(int argc, char **argv, char **envp)
break;
case QEMU_OPTION_vga:
vga_model = optarg;
+default_vga = 0;
break;
case QEMU_OPTION_g:
{
@@ -3107,7 +3115,7 @@ int main(int argc, char **argv, char **envp)
default_floppy = 0;
default_cdrom = 0;
default_sdcard = 0;
-vga_model = none;
+default_vga = 0;
break;
case QEMU_OPTION_xen_domid:
if (!(xen_available())) {
@@ -3468,14 +3476,13 @@ int main(int argc, char **argv, char **envp)
module_call_init(MODULE_INIT_QOM);
-/* must be after qdev registration but before machine init */
-if (vga_model) {
-select_vgahw(vga_model);
-} else if (cirrus_vga_available()) {
-select_vgahw(cirrus);
-} else {
-select_vgahw(none);
+/* This must be after qdev registration but before machine init.
+ * If no default VGA is requested, the default is none.
+ */
+if (default_vga cirrus_vga_available()) {
+vga_model = cirrus;
}
+select_vgahw(vga_model);
if (qemu_opts_foreach(qemu_find_opts(device), device_help_func, NULL, 0)
!= 0)
exit(0);
--
1.7.7.6
Re: [Qemu-devel] [PATCH 12/12] cmdline: convert -no-shutdown and -no-reboot to QemuOpts
On 20 March 2012 08:01, Paolo Bonzini pbonz...@redhat.com wrote: They are also moved inside -machine. So why no_reboot and no_shutdown but autostart rather than no_autostart? -- PMM
Re: [Qemu-devel] [PATCH v2 0/7] vdi: convert to coroutines
Am 19.03.2012 18:07, schrieb Paolo Bonzini: This squashes in the fix for GCC's uninitialized variables false positive. Paolo Bonzini (7): vdi: basic conversion to coroutines vdi: move end-of-I/O handling at the end vdi: merge aio_read_cb and aio_write_cb into callers vdi: move aiocb fields to locals vdi: leave bounce buffering to block layer vdi: do not create useless iovecs vdi: change goto to loop block/vdi.c | 421 +++ 1 files changed, 108 insertions(+), 313 deletions(-) Thanks, updated the patches in the block branch. Kevin
[Qemu-devel] [PATCH 07/12] cmdline: make -M a simple alias for -machine type
machine_parse is still being called from the -M handler. Remove this,
and just call machine_parse based on the -machine type value.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
vl.c | 27 ++-
1 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/vl.c b/vl.c
index 3b9ff31..1fc5044 100644
--- a/vl.c
+++ b/vl.c
@@ -2274,7 +2274,7 @@ int main(int argc, char **argv, char **envp)
int optind;
const char *optarg;
const char *loadvm = NULL;
-QEMUMachine *machine;
+QEMUMachine *machine = NULL;
const char *cpu_model;
const char *vga_model = none;
const char *pid_file = NULL;
@@ -2317,7 +2317,6 @@ int main(int argc, char **argv, char **envp)
os_setup_early_signal_handling();
module_call_init(MODULE_INIT_MACHINE);
-machine = find_default_machine();
cpu_model = NULL;
ram_size = 0;
snapshot = 0;
@@ -2384,7 +2383,7 @@ int main(int argc, char **argv, char **envp)
}
switch(popt-index) {
case QEMU_OPTION_M:
-machine = machine_parse(optarg);
+qemu_opts_set(qemu_find_opts(machine), 0, type, optarg);
break;
case QEMU_OPTION_cpu:
/* hw initialization will check this */
@@ -2954,10 +2953,6 @@ int main(int argc, char **argv, char **envp)
fprintf(stderr, parse error: %s\n, optarg);
exit(1);
}
-optarg = qemu_opt_get(opts, type);
-if (optarg) {
-machine = machine_parse(optarg);
-}
break;
case QEMU_OPTION_usb:
usb_enabled = 1;
@@ -3218,11 +3213,19 @@ int main(int argc, char **argv, char **envp)
data_dir = CONFIG_QEMU_DATADIR;
}
-if (machine == NULL) {
-fprintf(stderr, No machine found.\n);
-exit(1);
+machine_opts = qemu_opts_find(qemu_find_opts(machine), 0);
+if (machine_opts) {
+optarg = qemu_opt_get(machine_opts, type);
+if (optarg) {
+machine = machine_parse(optarg);
+}
+}
+if (!machine) {
+machine = find_default_machine();
}
+current_machine = machine;
+
/*
* Default to max_cpus = smp_cpus, in case the user doesn't
* specify a max_cpus value.
@@ -3312,7 +3315,7 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
-machine_opts = qemu_opts_find(qemu_find_opts(machine), 0);
+/* Initialize machine options */
bios_name = NULL;
kernel_filename = initrd_filename = kernel_cmdline = NULL;
ram_size = DEFAULT_RAM_SIZE * 1024 * 1024;
@@ -3493,8 +3496,6 @@ int main(int argc, char **argv, char **envp)
set_numa_modes();
-current_machine = machine;
-
/* init USB devices */
if (usb_enabled) {
if (foreach_device_config(DEV_USB, usb_parse) 0)
--
1.7.7.6
Re: [Qemu-devel] [PATCH 12/12] cmdline: convert -no-shutdown and -no-reboot to QemuOpts
Il 20/03/2012 10:04, Peter Maydell ha scritto: They are also moved inside -machine. So why no_reboot and no_shutdown but autostart rather than no_autostart? Because. :) Seriously, perhaps we want two enum options on_reboot/on_shutdown with items reboot/stop/quit? Paolo
[Qemu-devel] [PATCH 11/12] cmdline: implement -nodefaults with qemuopts
This becomes -machine default_devices.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
qemu-config.c |4
vl.c | 40 ++--
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/qemu-config.c b/qemu-config.c
index f5cf56b..6e97ff6 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -560,6 +560,10 @@ static QemuOptsList qemu_machine_opts = {
.type = QEMU_OPT_STRING,
.help = accelerator list,
}, {
+.name = default_devices,
+.type = QEMU_OPT_BOOL,
+.help = create default devices,
+}, {
.name = autostart,
.type = QEMU_OPT_BOOL,
.help = start machine immediately,
diff --git a/vl.c b/vl.c
index b485f4c..aa324ed 100644
--- a/vl.c
+++ b/vl.c
@@ -3075,15 +3075,7 @@ int main(int argc, char **argv, char **envp)
incoming = optarg;
break;
case QEMU_OPTION_nodefaults:
-default_serial = 0;
-default_parallel = 0;
-default_virtcon = 0;
-default_monitor = 0;
-default_net = 0;
-default_floppy = 0;
-default_cdrom = 0;
-default_sdcard = 0;
-default_vga = 0;
+qemu_opts_set(qemu_find_opts(machine), 0, default_devices,
off);
break;
case QEMU_OPTION_xen_domid:
if (!(xen_available())) {
@@ -3243,26 +3235,30 @@ int main(int argc, char **argv, char **envp)
machine-default_machine_opts, 0);
}
-qemu_opts_foreach(qemu_find_opts(device), default_driver_check, NULL, 0);
-qemu_opts_foreach(qemu_find_opts(global), default_driver_check, NULL, 0);
+if (qemu_opt_get_bool(machine_opts, default_devices, true)) {
+qemu_opts_foreach(qemu_find_opts(device), default_driver_check,
NULL, 0);
+qemu_opts_foreach(qemu_find_opts(global), default_driver_check,
NULL, 0);
+
+default_serial = !machine-no_serial;
+default_parallel = !machine-no_parallel;
+default_virtcon = machine-use_virtcon;
+default_floppy = !machine-no_floppy;
+default_cdrom = !machine-no_cdrom;
+default_sdcard = !machine-no_sdcard;
-if (machine-no_serial) {
+/* No need for machine-no_vga. Boards can simply ignore the
+ * vga_interface_type variable (most will, indeed).
+ */
+} else {
default_serial = 0;
-}
-if (machine-no_parallel) {
default_parallel = 0;
-}
-if (!machine-use_virtcon) {
default_virtcon = 0;
-}
-if (machine-no_floppy) {
+default_monitor = 0;
+default_net = 0;
default_floppy = 0;
-}
-if (machine-no_cdrom) {
default_cdrom = 0;
-}
-if (machine-no_sdcard) {
default_sdcard = 0;
+default_vga = 0;
}
if (display_type == DT_NOGRAPHIC) {
--
1.7.7.6
[Qemu-devel] [Bug 932487] Re: win32: git rev 59f971d crashes when accessing disk (coroutine issue)
Please try a newer compiler. gcc-4.6.2 compiles thread local storage correctly, gcc-4.3.3 obviously doesn't. If you can confirm that newer compilers fix this bug, I'd like to close this ticket. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/932487 Title: win32: git rev 59f971d crashes when accessing disk (coroutine issue) Status in QEMU: Confirmed Bug description: Host: XP SP3 / Vista SP2 configure commandline: ./configure --target-list=i386-softmmu --audio-drv-list=sdl --audio-card-list=ac97,sb16,adlib --disable- linux-aio --disable-vnc-thread --disable-vnc-jpeg --extra-cflags=-O0 -pipe gcc -v: Using built-in specs. Target: mingw32 Configured with: ../gcc-4.3.3/configure --prefix=/mingw --build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ --with-bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls --disable-win32-registry --enable-libgomp --disable-werror --enable-threads --disable-symvers --enable-cxx-flags='-fno-function-sections -fno-data-sections' --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --with-pkgversion='4.3.3-tdm-1 mingw32' Thread model: win32 gcc version 4.3.3 (4.3.3-tdm-1 mingw32) gdb output: C:\msys\home\User\qemu\i386-softmmugdb --args qemu-system-i386.exe -L ..\pc-bios -hda xp.vmdk GNU gdb (GDB) 7.3 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as mingw32. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe... done. (gdb) r Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L ..\\pc-bios -hda xp.vmdk [New Thread 2472.0x8e0] [New Thread 2472.0xdc4] [New Thread 2472.0x8f0] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 2472.0x8f0] 0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll (gdb) bt #0 0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll #1 0x0044774c in qemu_coroutine_switch (from_=0x19593fc, to_=0xdcee9a8, action=COROUTINE_YIELD) at coroutine-win32.c:48 #2 0x004db18d in coroutine_swap (from=0x1e00, to=0xdcee9a8) at qemu-coroutine.c:31 #3 0x00411618 in bdrv_rw_co (bs=optimized out, sector_num=optimized out, buf=0x214 @, nb_sectors=1, is_write=false) at block.c:1335 #4 0x00486e39 in ide_sector_read (s=0x1bbdaa0) at C:/msys/home/User/qemu/hw/ide/core.c:480 #5 0x0054e71f in memory_region_iorange_write (iorange=0x1bbcf60, offset=7, width=1, data=32) at C:/msys/home/User/qemu/memory.c:431 #6 0x005494e0 in ioport_writeb_thunk (opaque=0x1bbcf60, addr=7680, data=32) at C:/msys/home/User/qemu/ioport.c:211 #7 0x005496cf in ioport_write (data=optimized out, address=optimized out, index=optimized out) at C:/msys/home/User/qemu/ioport.c:82 #8 cpu_outb (addr=2147340288, val=0 '\000') at C:/msys/home/User/qemu/ioport.c:274 #9 0x022c0397 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/932487/+subscriptions
Re: [Qemu-devel] [PATCH 10/12] trace: [tracetool] Automatically establish available backends and formats
2012/3/13 Lluís Vilanova vilan...@ac.upc.edu: Adds decorators to establish which backend and/or format each routine is meant to process. With this, tables enumerating format and backend routines can be eliminated and part of the usage message can be computed in a more generic way. Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu Signed-off-by: Harsh Prateek Bora ha...@linux.vnet.ibm.com --- Makefile.objs | 6 - Makefile.target | 3 scripts/tracetool.py | 320 -- 3 files changed, 211 insertions(+), 118 deletions(-) I find the decorators are overkill and we miss the chance to use more straightforward approaches that Python supports. The decorators build structures behind the scenes instead of using classes in an open coded way. I think this makes it more difficult for people to modify the code - they will need to dig in to what exactly the decorators do - what they do is pretty similar to what you get from a class. I've tried out an alternative approach which works very nicely for formats. For backends it's not a perfect fit because it creates instances when we don't really need them, but I think it's still an overall cleaner approach: https://github.com/stefanha/qemu/commit/3500eb43f80f3c9200107aa0ca19a1b57300ef8a What do you think? Stefan
Re: [Qemu-devel] [PATCH 1/6] arm: move neon_tbl to neon_helper.c
On Mon, Mar 19, 2012 at 11:10 PM, Peter Maydell
peter.mayd...@linaro.org wrote:
On 19 March 2012 21:56, Blue Swirl blauwir...@gmail.com wrote:
-DEF_HELPER_4(neon_tbl, i32, i32, i32, i32, i32)
+DEF_HELPER_5(neon_tbl, i32, env, i32, i32, i32, i32)
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -6340,7 +6340,7 @@ static int disas_neon_data_insn(CPUARMState *
env, DisasContext *s, uint32_t ins
tmp2 = neon_load_reg(rm, 0);
tmp4 = tcg_const_i32(rn);
tmp5 = tcg_const_i32(n);
- gen_helper_neon_tbl(tmp2, tmp2, tmp, tmp4, tmp5);
+ gen_helper_neon_tbl(cpu_env, tmp2, tmp2, tmp, tmp4, tmp5);
tcg_temp_free_i32(tmp);
if (insn (1 6)) {
tmp = neon_load_reg(rd, 1);
@@ -6349,7 +6349,7 @@ static int disas_neon_data_insn(CPUARMState *
env, DisasContext *s, uint32_t ins
tcg_gen_movi_i32(tmp, 0);
}
tmp3 = neon_load_reg(rm, 1);
- gen_helper_neon_tbl(tmp3, tmp3, tmp, tmp4, tmp5);
+ gen_helper_neon_tbl(cpu_env, tmp3, tmp3, tmp, tmp4, tmp5);
tcg_temp_free_i32(tmp5);
tcg_temp_free_i32(tmp4);
neon_store_reg(rd, 0, tmp2);
...shouldn't these be
gen_helper_neon_tbl(tmp3, cpu_env, tmp3, tmp, tmp4, tmp5);
Indeed. Compiling with --enable-debug doesn't work.
Laurent
Re: [Qemu-devel] [PATCH 00/12] Rewrite tracetool using python
2012/3/13 Lluís Vilanova vilan...@ac.upc.edu: The first patch in the series (by Harsh Prateek) is a rewrite of the tracetool shell script in python, which is easier to handle given the current complexity of the script. The following patches (by Lluís Vilanova) add a series of random code cleanups and generalizations. Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu --- NOTE: This series contains the first 11 patches from Harsh's v5 series, which are the ones required for the language conversion. Version History: v6: - Rebase on cb72b758 from master. - Revive documentation whitespace deletions. - Split off this series the patches regarding the new simpletrace trace format. v5: - trace/simple.c: Introduced new struct TraceRecordHeader for log header consistency - Addressed Stefan's review comments for scripts/simpletrace.py v4: - Addressed Stefan's review comments for tracetool, trace/simple.* - Adressed Fast producer, Slow consumer problem - Isolated tracetool python conversion patch from simpletrace v2 changes. - Included improvements and fixes from Lluis Vilanova TODO: Update simpletrace.py for simpletrace v2 log format. v3: - Added support for LTTng ust trace backend in tracetool.py v2: - Updated tracetool.py to support nop, stderr, dtrace backend v1: - Working protoype with tracetool.py converted only for simpletrace backend Harsh Prateek Bora (1): Converting tracetool.sh to tracetool.py Lluís Vilanova (11): trace: [tracetool] Remove unused 'sizestr' attribute in 'Event' trace: [tracetool] Do not rebuild event list in backend code trace: [tracetool] Simplify event line parsing trace: [tracetool] Do not precompute the event number trace: [tracetool] Add support for event properties trace: [tracetool] Process the disable event property trace: [tracetool] Rewrite event argument parsing trace: [tracetool] Make format-specific code optional and with access to events trace: [tracetool] Automatically establish available backends and formats trace: Provide a per-event status define for conditional compilation trace: [tracetool] Add error-reporting functions Makefile.objs | 6 Makefile.target | 13 + configure | 7 - scripts/tracetool | 648 -- scripts/tracetool.py | 588 + 5 files changed, 602 insertions(+), 660 deletions(-) delete mode 100755 scripts/tracetool create mode 100755 scripts/tracetool.py Looks very close. I diffed the tracetool output for all backends and verified that there is no semantic difference. The only real point I want to reach agreement with you on is how to consolidate formats/backends. I left a reply on that patch because I prefer an alternative to the decorators approach. Stefan
Re: [Qemu-devel] [PATCH 12/12] trace: [tracetool] Add error-reporting functions
On Tue, Mar 13, 2012 at 09:03:43PM +0100, Lluís Vilanova wrote: @@ -514,8 +521,9 @@ def main(): try: opts, args = getopt.getopt(sys.argv[1:], , long_options) except getopt.GetoptError, err: -# print help information and exit: -print str(err) # will print something like option -a not recognized +# print help information and exit +# will print something like option -a not recognized +error_write(str(err)+\n) Please use whitespace in expressions: error_write(str(err) + \n)
Re: [Qemu-devel] [PATCHv4 04/11] consolidate qemu_iovec_memset{, _skip}() into single function and use existing iov_memset()
On Tue, Mar 20, 2012 at 12:04:36AM +0400, Michael Tokarev wrote: I don't have bandwidth for non-trivial cosmetic stuff at the moment, sorry. What's bandwidth in this context? Time. My review queue is 120 patches at the moment. I'm tackling those which are blocked on me and which fix bugs/add features first. Initially I thought that just making 2 or 3 functions which were inconsistent with each other to be a very easy task. But the patchset grew to 11 patches and 5 versions, because pbonzini said it is insufficient. Now you're saying it is too much. I spent *much* more than any sane amount of time on this, rediffing and rewriting, on a *trivial* thing, and now what? If you can't plan even the most simple and low-level interface to be consistent, please at least let someone who is STILL willing to make it consistent to do that. It is not cosmetic. And if the code will grow this way further (and it does!), it will be a very big ball of mud, unmaintainable. I'm not blocking this series. If others are happy with this series then please merge. Stefan
Re: [Qemu-devel] [PATCH] block: add the support to drain throttled requests
HI, Kevin,
We hope that I/O throttling can be shipped without known issue in QEMU
1.1, so if you are available, can you give this patch some love?
On Tue, Mar 13, 2012 at 9:53 AM, zwu.ker...@gmail.com wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
[ Iterate until all block devices have processed all requests,
add comments. - Paolo ]
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
block.c | 24 ++--
1 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/block.c b/block.c
index 52ffe14..52dabd0 100644
--- a/block.c
+++ b/block.c
@@ -858,12 +858,32 @@ void bdrv_close_all(void)
*
* This function does not flush data to disk, use bdrv_flush_all() for that
* after calling this function.
- */
+ *
+ * Note that completion of an asynchronous I/O operation can trigger any
+ * number of other I/O operations on other devices---for example a coroutine
+ * can be arbitrarily complex and a constant flow of I/O to multiple devices
+ * can come until the coroutine is complete. Because of this, it is not
+ * possible to drain a single device's I/O queue.
+*/
void bdrv_drain_all(void)
{
BlockDriverState *bs;
+ bool busy;
- qemu_aio_flush();
+ do {
+ busy = false;
+ qemu_aio_flush();
+
+ /* FIXME: We do not have timer support here, so this is effectively
+ * a busy wait.
+ */
+ QTAILQ_FOREACH(bs, bdrv_states, list) {
+ if (!qemu_co_queue_empty(bs-throttled_reqs)) {
+ qemu_co_queue_restart_all(bs-throttled_reqs);
+ busy = true;
+ }
+ }
+ } while (busy);
/* If requests are still pending there is a bug somewhere */
QTAILQ_FOREACH(bs, bdrv_states, list) {
--
1.7.6
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH] block: add the support to drain throttled requests
Il 20/03/2012 10:40, Zhi Yong Wu ha scritto: HI, Kevin, We hope that I/O throttling can be shipped without known issue in QEMU 1.1, so if you are available, can you give this patch some love? I'm sorry to say this, but I think I/O throttling is impossible to save. As it is implemented now, it just cannot work in the presence of synchronous I/O, except at the cost of busy waiting with the global mutex taken. See the message from Stefan yesterday. Unfortunately I don't have any solution for this, except perhaps disabling throttling around synchronous I/O. Paolo
Re: [Qemu-devel] [Bug 932487] Re: win32: git rev 59f971d crashes when accessing disk (coroutine issue)
2012/3/20 Stefan Weil 932...@bugs.launchpad.net: Please try a newer compiler. gcc-4.6.2 compiles thread local storage correctly, gcc-4.3.3 obviously doesn't. If you can confirm that newer compilers fix this bug, I'd like to close this ticket. I'm using gcc-4.6.2 now. -- You received this bug notification because you are subscribed to the bug report. https://bugs.launchpad.net/bugs/932487 Title: win32: git rev 59f971d crashes when accessing disk (coroutine issue) Status in QEMU: Confirmed Bug description: Host: XP SP3 / Vista SP2 configure commandline: ./configure --target-list=i386-softmmu --audio-drv-list=sdl --audio-card-list=ac97,sb16,adlib --disable- linux-aio --disable-vnc-thread --disable-vnc-jpeg --extra-cflags=-O0 -pipe gcc -v: Using built-in specs. Target: mingw32 Configured with: ../gcc-4.3.3/configure --prefix=/mingw --build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ --with-bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls --disable-win32-registry --enable-libgomp --disable-werror --enable-threads --disable-symvers --enable-cxx-flags='-fno-function-sections -fno-data-sections' --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --with-pkgversion='4.3.3-tdm-1 mingw32' Thread model: win32 gcc version 4.3.3 (4.3.3-tdm-1 mingw32) gdb output: C:\msys\home\User\qemu\i386-softmmugdb --args qemu-system-i386.exe -L ..\pc-bios -hda xp.vmdk GNU gdb (GDB) 7.3 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as mingw32. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe... done. (gdb) r Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L ..\\pc-bios -hda xp.vmdk [New Thread 2472.0x8e0] [New Thread 2472.0xdc4] [New Thread 2472.0x8f0] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 2472.0x8f0] 0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll (gdb) bt #0 0x7c81071e in SwitchToFiber () from C:\WINDOWS\system32\kernel32.dll #1 0x0044774c in qemu_coroutine_switch (from_=0x19593fc, to_=0xdcee9a8, action=COROUTINE_YIELD) at coroutine-win32.c:48 #2 0x004db18d in coroutine_swap (from=0x1e00, to=0xdcee9a8) at qemu-coroutine.c:31 #3 0x00411618 in bdrv_rw_co (bs=optimized out, sector_num=optimized out, buf=0x214 @, nb_sectors=1, is_write=false) at block.c:1335 #4 0x00486e39 in ide_sector_read (s=0x1bbdaa0) at C:/msys/home/User/qemu/hw/ide/core.c:480 #5 0x0054e71f in memory_region_iorange_write (iorange=0x1bbcf60, offset=7, width=1, data=32) at C:/msys/home/User/qemu/memory.c:431 #6 0x005494e0 in ioport_writeb_thunk (opaque=0x1bbcf60, addr=7680, data=32) at C:/msys/home/User/qemu/ioport.c:211 #7 0x005496cf in ioport_write (data=optimized out, address=optimized out, index=optimized out) at C:/msys/home/User/qemu/ioport.c:82 #8 cpu_outb (addr=2147340288, val=0 '\000') at C:/msys/home/User/qemu/ioport.c:274 #9 0x022c0397 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/932487/+subscriptions -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/932487 Title: win32: git rev 59f971d crashes when accessing disk (coroutine issue) Status in QEMU: Confirmed Bug description: Host: XP SP3 / Vista SP2 configure commandline: ./configure --target-list=i386-softmmu --audio-drv-list=sdl --audio-card-list=ac97,sb16,adlib --disable- linux-aio --disable-vnc-thread --disable-vnc-jpeg --extra-cflags=-O0 -pipe gcc -v: Using built-in specs. Target: mingw32 Configured with: ../gcc-4.3.3/configure --prefix=/mingw --build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ --with-bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls --disable-win32-registry --enable-libgomp --disable-werror --enable-threads --disable-symvers --enable-cxx-flags='-fno-function-sections -fno-data-sections' --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --with-pkgversion='4.3.3-tdm-1 mingw32' Thread model: win32 gcc version 4.3.3 (4.3.3-tdm-1 mingw32) gdb output: C:\msys\home\User\qemu\i386-softmmugdb --args qemu-system-i386.exe -L ..\pc-bios -hda xp.vmdk GNU gdb (GDB) 7.3 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+:
[Qemu-devel] [PATCH 0/6] fix w32 sockets
The w32 main loop has been mostly broken by the introduction of the glib main loop. glib's g_poll does not use sockets on w32, so we need a separate approach. Patch 1 is a simple cleanup that is needed later in the series. Patch 2 and patch 3 completely separate the way the main loop waits on POSIX and w32 systems, and drop glib source handling from the w32 main loop. Patch 4 fixes a longstanding bug in how sockets are handled, also simplifying the code in the process. On top of this simplification, patch 5 starts using g_poll in the w32 main loop and patch 6 adds back glib source handling. I didn't test this in the conditions explained in bug 916720, but I tested both a TCP monitor and an stdio monitor and both work (under Wine that is). Stefan, can you please take care of shepherding the patches in (pinging etc.)? Paolo Bonzini (6): slirp: use socket_set_nonblock main loop: use msec-based timeout in glib_select_fill main-loop: disable fd_set-based glib integration under w32 main-loop: interrupt wait when data arrives on a socket main-loop: replace WaitForMultipleObjects with g_poll main-loop: integrate glib sources for w32 main-loop.c | 147 +++--- main-loop.h |1 + oslib-win32.c|3 + slirp/misc.c | 46 + slirp/tcp_subr.c |4 +- 5 files changed, 92 insertions(+), 109 deletions(-) -- 1.7.7.6
[Qemu-devel] [PATCH 5/6] main-loop: replace WaitForMultipleObjects with g_poll
On w32, glib implements g_poll using WaitForMultipleObjects
or MsgWaitForMultipleObjects. This means that we can simplify
our code by switching to g_poll, and at the same time prepare for
adding back glib sources.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
main-loop.c | 40 +---
1 files changed, 17 insertions(+), 23 deletions(-)
diff --git a/main-loop.c b/main-loop.c
index 7364074..4d02568 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -220,9 +220,9 @@ int main_loop_init(void)
static fd_set rfds, wfds, xfds;
static int nfds;
+static GPollFD poll_fds[1024 * 2]; /* this is probably overkill */
#ifndef _WIN32
-static GPollFD poll_fds[1024 * 2]; /* this is probably overkill */
static int n_poll_fds;
static int max_priority;
@@ -351,6 +351,7 @@ void qemu_del_polling_cb(PollingFunc *func, void *opaque)
/* Wait objects support */
typedef struct WaitObjects {
int num;
+int revents[MAXIMUM_WAIT_OBJECTS + 1];
HANDLE events[MAXIMUM_WAIT_OBJECTS + 1];
WaitObjectFunc *func[MAXIMUM_WAIT_OBJECTS + 1];
void *opaque[MAXIMUM_WAIT_OBJECTS + 1];
@@ -367,6 +368,7 @@ int qemu_add_wait_object(HANDLE handle, WaitObjectFunc
*func, void *opaque)
w-events[w-num] = handle;
w-func[w-num] = func;
w-opaque[w-num] = opaque;
+w-revents[w-num] = 0;
w-num++;
return 0;
}
@@ -385,6 +387,7 @@ void qemu_del_wait_object(HANDLE handle, WaitObjectFunc
*func, void *opaque)
w-events[i] = w-events[i + 1];
w-func[i] = w-func[i + 1];
w-opaque[i] = w-opaque[i + 1];
+w-revents[i] = w-revents[i + 1];
}
}
if (found) {
@@ -400,9 +403,8 @@ void qemu_fd_register(int fd)
static int os_host_main_loop_wait(int timeout)
{
-int ret, ret2, i;
+int ret, i;
PollingEntry *pe;
-int err;
WaitObjects *w = wait_objects;
static struct timeval tv0;
@@ -422,33 +424,25 @@ static int os_host_main_loop_wait(int timeout)
}
}
+for (i = 0; i w-num; i++) {
+poll_fds[i].fd = (DWORD) w-events[i];
+poll_fds[i].events = G_IO_IN;
+}
+
qemu_mutex_unlock_iothread();
-ret = WaitForMultipleObjects(w-num, w-events, FALSE, timeout);
+ret = g_poll(poll_fds, w-num, timeout);
qemu_mutex_lock_iothread();
-if (WAIT_OBJECT_0 + 0 = ret ret = WAIT_OBJECT_0 + w-num - 1) {
-if (w-func[ret - WAIT_OBJECT_0]) {
-w-func[ret - WAIT_OBJECT_0](w-opaque[ret - WAIT_OBJECT_0]);
+if (ret 0) {
+for (i = 0; i w-num; i++) {
+w-revents[i] = poll_fds[i].revents;
}
-
-/* Check for additional signaled events */
-for (i = (ret - WAIT_OBJECT_0 + 1); i w-num; i++) {
-/* Check if event is signaled */
-ret2 = WaitForSingleObject(w-events[i], 0);
-if (ret2 == WAIT_OBJECT_0) {
-if (w-func[i]) {
-w-func[i](w-opaque[i]);
-}
-} else if (ret2 != WAIT_TIMEOUT) {
-err = GetLastError();
-fprintf(stderr, WaitForSingleObject error %d %d\n, i, err);
+for (i = 0; i w-num; i++) {
+if (w-revents[i] w-func[i]) {
+w-func[i](w-opaque[i]);
}
}
-} else if (ret != WAIT_TIMEOUT) {
-err = GetLastError();
-fprintf(stderr, WaitForMultipleObjects error %d %d\n, ret, err);
}
-
/* If an edge-triggered socket event occurred, select will return a
* positive result on the next iteration. We do not need to do anything
* here.
--
1.7.7.6
[Qemu-devel] [PATCH 4/6] main-loop: interrupt wait when data arrives on a socket
Right now, the main loop is not interrupted when data arrives on a
socket. To fix this, register each socket to interrupt the main loop
with WSAEventSelect. This does not replace select, it only communicates
a change in socket state that requires a select call.
Since the interrupt fires only once per recv call, or only once
after a send call returns EWOULDBLOCK we can activate it on all events
unconditionally. If QEMU is momentarily uninterested on some condition,
the main loop will not busy wait. Instead, it may get one extra wakeup,
but then it will ignore the condition until progress occurs and/or
qemu_set_fd_handler is called to set a callback. At this point the
condition will be tested via select and the callback will be invoked
even if it is still disabled on the event.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
main-loop.c | 69
main-loop.h |1 +
oslib-win32.c |3 ++
3 files changed, 48 insertions(+), 25 deletions(-)
diff --git a/main-loop.c b/main-loop.c
index dc6bdb5..7364074 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -392,10 +392,18 @@ void qemu_del_wait_object(HANDLE handle, WaitObjectFunc
*func, void *opaque)
}
}
+void qemu_fd_register(int fd)
+{
+WSAEventSelect(fd, qemu_event_handle, FD_READ | FD_ACCEPT | FD_CLOSE |
+ FD_CONNECT | FD_WRITE | FD_OOB);
+}
+
static int os_host_main_loop_wait(int timeout)
{
int ret, ret2, i;
PollingEntry *pe;
+int err;
+WaitObjects *w = wait_objects;
static struct timeval tv0;
/* XXX: need to suppress polling by better using win32 events */
@@ -403,38 +411,49 @@ static int os_host_main_loop_wait(int timeout)
for (pe = first_polling_entry; pe != NULL; pe = pe-next) {
ret |= pe-func(pe-opaque);
}
-if (ret == 0) {
-int err;
-WaitObjects *w = wait_objects;
+if (ret != 0) {
+return ret;
+}
-qemu_mutex_unlock_iothread();
-ret = WaitForMultipleObjects(w-num, w-events, FALSE, timeout);
-qemu_mutex_lock_iothread();
-if (WAIT_OBJECT_0 + 0 = ret ret = WAIT_OBJECT_0 + w-num - 1) {
-if (w-func[ret - WAIT_OBJECT_0]) {
-w-func[ret - WAIT_OBJECT_0](w-opaque[ret - WAIT_OBJECT_0]);
-}
+if (nfds = 0) {
+ret = select(nfds + 1, rfds, wfds, xfds, tv0);
+if (ret != 0) {
+timeout = 0;
+}
+}
-/* Check for additional signaled events */
-for (i = (ret - WAIT_OBJECT_0 + 1); i w-num; i++) {
-/* Check if event is signaled */
-ret2 = WaitForSingleObject(w-events[i], 0);
-if (ret2 == WAIT_OBJECT_0) {
-if (w-func[i]) {
-w-func[i](w-opaque[i]);
-}
-} else if (ret2 != WAIT_TIMEOUT) {
-err = GetLastError();
-fprintf(stderr, WaitForSingleObject error %d %d\n, i,
err);
+qemu_mutex_unlock_iothread();
+ret = WaitForMultipleObjects(w-num, w-events, FALSE, timeout);
+qemu_mutex_lock_iothread();
+if (WAIT_OBJECT_0 + 0 = ret ret = WAIT_OBJECT_0 + w-num - 1) {
+if (w-func[ret - WAIT_OBJECT_0]) {
+w-func[ret - WAIT_OBJECT_0](w-opaque[ret - WAIT_OBJECT_0]);
+}
+
+/* Check for additional signaled events */
+for (i = (ret - WAIT_OBJECT_0 + 1); i w-num; i++) {
+/* Check if event is signaled */
+ret2 = WaitForSingleObject(w-events[i], 0);
+if (ret2 == WAIT_OBJECT_0) {
+if (w-func[i]) {
+w-func[i](w-opaque[i]);
}
+} else if (ret2 != WAIT_TIMEOUT) {
+err = GetLastError();
+fprintf(stderr, WaitForSingleObject error %d %d\n, i, err);
}
-} else if (ret != WAIT_TIMEOUT) {
-err = GetLastError();
-fprintf(stderr, WaitForMultipleObjects error %d %d\n, ret, err);
}
+} else if (ret != WAIT_TIMEOUT) {
+err = GetLastError();
+fprintf(stderr, WaitForMultipleObjects error %d %d\n, ret, err);
}
-ret = select(nfds + 1, rfds, wfds, xfds, tv0);
+
+/* If an edge-triggered socket event occurred, select will return a
+ * positive result on the next iteration. We do not need to do anything
+ * here.
+ */
+
return ret;
}
#endif
diff --git a/main-loop.h b/main-loop.h
index 4987041..e743aa0 100644
--- a/main-loop.h
+++ b/main-loop.h
@@ -359,6 +359,7 @@ void qemu_mutex_unlock_iothread(void);
/* internal interfaces */
+void qemu_fd_register(int fd);
void qemu_iohandler_fill(int *pnfds, fd_set *readfds, fd_set *writefds, fd_set
*xfds);
void qemu_iohandler_poll(fd_set *readfds, fd_set *writefds, fd_set *xfds, int
rc);
diff --git a/oslib-win32.c b/oslib-win32.c
index ce3021e..ffbc6d0 100644
--- a/oslib-win32.c
+++
[Qemu-devel] [PATCH 1/6] slirp: use socket_set_nonblock
Cc: Jan Kiszka jan.kis...@siemens.de
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
slirp/misc.c | 46 +-
slirp/tcp_subr.c |4 ++--
2 files changed, 3 insertions(+), 47 deletions(-)
diff --git a/slirp/misc.c b/slirp/misc.c
index 0308a62..0bee864 100644
--- a/slirp/misc.c
+++ b/slirp/misc.c
@@ -215,7 +215,7 @@ fork_exec(struct socket *so, const char *ex, int do_pty)
setsockopt(so-s, SOL_SOCKET, SO_REUSEADDR, (char *)opt,
sizeof(int));
opt = 1;
setsockopt(so-s, SOL_SOCKET, SO_OOBINLINE, (char *)opt,
sizeof(int));
- fd_nonblock(so-s);
+socket_set_nonblock(so-s);
/* Append the telnet options now */
if (so-so_m != NULL do_pty == 1) {
@@ -267,50 +267,6 @@ u_sleep(int usec)
select(0, fdset, fdset, fdset, t);
}
-/*
- * Set fd blocking and non-blocking
- */
-
-void
-fd_nonblock(int fd)
-{
-#ifdef FIONBIO
-#ifdef _WIN32
-unsigned long opt = 1;
-#else
-int opt = 1;
-#endif
-
- ioctlsocket(fd, FIONBIO, opt);
-#else
- int opt;
-
- opt = fcntl(fd, F_GETFL, 0);
- opt |= O_NONBLOCK;
- fcntl(fd, F_SETFL, opt);
-#endif
-}
-
-void
-fd_block(int fd)
-{
-#ifdef FIONBIO
-#ifdef _WIN32
-unsigned long opt = 0;
-#else
- int opt = 0;
-#endif
-
- ioctlsocket(fd, FIONBIO, opt);
-#else
- int opt;
-
- opt = fcntl(fd, F_GETFL, 0);
- opt = ~O_NONBLOCK;
- fcntl(fd, F_SETFL, opt);
-#endif
-}
-
void slirp_connection_info(Slirp *slirp, Monitor *mon)
{
const char * const tcpstates[] = {
diff --git a/slirp/tcp_subr.c b/slirp/tcp_subr.c
index 143a238..5a3d7c2 100644
--- a/slirp/tcp_subr.c
+++ b/slirp/tcp_subr.c
@@ -329,7 +329,7 @@ int tcp_fconnect(struct socket *so)
int opt, s=so-s;
struct sockaddr_in addr;
-fd_nonblock(s);
+socket_set_nonblock(s);
opt = 1;
setsockopt(s,SOL_SOCKET,SO_REUSEADDR,(char *)opt,sizeof(opt ));
opt = 1;
@@ -417,7 +417,7 @@ tcp_connect(struct socket *inso)
tcp_close(sototcpcb(so)); /* This will sofree() as well */
return;
}
- fd_nonblock(s);
+ socket_set_nonblock(s);
opt = 1;
setsockopt(s,SOL_SOCKET,SO_REUSEADDR,(char *)opt,sizeof(int));
opt = 1;
--
1.7.7.6
Re: [Qemu-devel] [PATCH] block: add the support to drain throttled requests
Am 20.03.2012 10:40, schrieb Zhi Yong Wu: HI, Kevin, We hope that I/O throttling can be shipped without known issue in QEMU 1.1, so if you are available, can you give this patch some love? Sorry, haven't had the time to follow the discussion closely. Are all review comments addressed now? Paolo? Kevin
Re: [Qemu-devel] [PATCH] Remove PCI class code from virtio balloon device
On Tue, Mar 20, 2012 at 12:42 AM, David Gibson da...@gibson.dropbear.id.au wrote: On Mon, Mar 19, 2012 at 11:33:10AM +, Stefan Hajnoczi wrote: On Mon, Mar 19, 2012 at 03:59:23PM +1100, David Gibson wrote: Currently the virtio balloon device, when using the virtio-pci interface advertises itself with PCI class code MEMORY_RAM. This is wrong; the balloon is vaguely related to memory, but is nothing like a PCI memory device in the meaning of the class code, and this code is not required or suggested by the virtio PCI specification. Worse, this patch causes problems on the pseries machine, because the firmware, seeing this class code, advertises the device as memory in the device tree, and then a guest kernel bug causes it to see this memory before the real system memory, leading to a crash in early boot. This patch fixes the problem by removing the bogus PCI class code on the balloon device. Cc: Michael S. Tsirkin m...@redhat.com Cc: Rusty Russell ru...@rustcorp.com.au Signed-off-by: David Gibson da...@gibson.dropbear.id.au --- hw/virtio-pci.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Since this is a guest-visible change we might need to be careful about how it's introduced. Do we need to keep the old class code for existing machine types? The new class code could be introduced only for 1.1 and later machine types if we want to be extra careful about introducing guest-visible changes. So as a general rule, I like to be very careful about user-visible changes. But in this case, I don't think we want to be too hesitant. In particular, it's not just a question of the machine type, but also of how the guest OS will deal with the PCI class code. The class code we were using was Just Plain Wrong. It was not suggetsed by the virtio spec, and it makes no sense. It happens that so far this caused problems only for a guest on a particular machine type, but there's no reason it couldn't cause (different) problems for guests on any machine type. More to the point, it seems reasonably unlikely for existing guests to rely on the broken behaviour: again, there's no reason they'd think they need to based on the spec, and the usual way of matching drivers to PCI devices is with the vendor/device IDs which are correct and not changed by this patch. So, unless we have a known example of an existing guest that would be broken by this change, I think we should implement it ASAP for all machine types. I agree that in practice the risk is low because working guests are probably not using the class code. On the other hand I don't see a downside to making this part of the 1.1 machine type, which is what users will run when they get this code change anyway. That way we can tell users that we never change the device model in a release with a straight face :). Anthony: I'm not sure how strict we are about a user-visible change like this? Stefan
Re: [Qemu-devel] [PATCH] block: add the support to drain throttled requests
Am 20.03.2012 10:47, schrieb Paolo Bonzini: Il 20/03/2012 10:40, Zhi Yong Wu ha scritto: HI, Kevin, We hope that I/O throttling can be shipped without known issue in QEMU 1.1, so if you are available, can you give this patch some love? I'm sorry to say this, but I think I/O throttling is impossible to save. As it is implemented now, it just cannot work in the presence of synchronous I/O, except at the cost of busy waiting with the global mutex taken. See the message from Stefan yesterday. qemu_aio_flush() is busy waiting with the global mutex taken anyway, so it doesn't change that much. Kevin
Re: [Qemu-devel] [PATCH 0/2 v3] kvm: notify host when guest panicked
At 03/19/2012 03:33 PM, Wen Congyang Wrote: At 03/08/2012 03:57 PM, Wen Congyang Wrote: We can know the guest is paniced when the guest runs on xen. But we do not have such feature on kvm. Another purpose of this feature is: management app(for example: libvirt) can do auto dump when the guest is crashed. If management app does not do auto dump, the guest's user can do dump by hand if he sees the guest is paniced. I touch the hypervisor instead of using virtio-serial, because 1. it is simple 2. the virtio-serial is an optional device, and the guest may not have such device. Changes from v2 to v3: 1. correct spelling Changes from v1 to v2: 1. split up host and guest-side changes 2. introduce new request flag to avoid changing return values. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Hi all: we neet this feature, but we don't decide how to implement it. We have two solution: 1. use vmcall 2. use virtio-serial. I will not change this patch set before we decide how to do it. Can we make a decision recent days? Anybody can decide which solution to use? Thanks Wen Congyang Thanks Wen Congyang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Qemu-devel] [PATCH 2/6] main loop: use msec-based timeout in glib_select_fill
The timeval-based timeout is not needed until we actually invoke select,
so compute it only then. Also group the two calls that modify the
timeout, glib_select_fill and os_host_main_loop_wait.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
main-loop.c | 22 ++
1 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/main-loop.c b/main-loop.c
index db23de0..a3fd993 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -224,11 +224,11 @@ static int n_poll_fds;
static int max_priority;
static void glib_select_fill(int *max_fd, fd_set *rfds, fd_set *wfds,
- fd_set *xfds, struct timeval *tv)
+ fd_set *xfds, int *cur_timeout)
{
GMainContext *context = g_main_context_default();
int i;
-int timeout = 0, cur_timeout;
+int timeout = 0;
g_main_context_prepare(context, max_priority);
@@ -253,10 +253,8 @@ static void glib_select_fill(int *max_fd, fd_set *rfds,
fd_set *wfds,
}
}
-cur_timeout = (tv-tv_sec * 1000) + ((tv-tv_usec + 500) / 1000);
-if (timeout = 0 timeout cur_timeout) {
-tv-tv_sec = timeout / 1000;
-tv-tv_usec = (timeout % 1000) * 1000;
+if (timeout = 0 timeout *cur_timeout) {
+*cur_timeout = timeout;
}
}
@@ -432,11 +430,6 @@ int main_loop_wait(int nonblocking)
qemu_bh_update_timeout(timeout);
}
-os_host_main_loop_wait(timeout);
-
-tv.tv_sec = timeout / 1000;
-tv.tv_usec = (timeout % 1000) * 1000;
-
/* poll any events */
/* XXX: separate device handlers from system ones */
nfds = -1;
@@ -448,7 +441,12 @@ int main_loop_wait(int nonblocking)
slirp_select_fill(nfds, rfds, wfds, xfds);
#endif
qemu_iohandler_fill(nfds, rfds, wfds, xfds);
-glib_select_fill(nfds, rfds, wfds, xfds, tv);
+
+glib_select_fill(nfds, rfds, wfds, xfds, timeout);
+os_host_main_loop_wait(timeout);
+
+tv.tv_sec = timeout / 1000;
+tv.tv_usec = (timeout % 1000) * 1000;
if (timeout 0) {
qemu_mutex_unlock_iothread();
--
1.7.7.6
Re: [Qemu-devel] [PATCH 0/6] ARM: AREG0 conversion
On Mon, Mar 19, 2012 at 10:55 PM, Blue Swirl blauwir...@gmail.com wrote: Convert ARM to AREG0 free operation. Survives simple tests. After fixing the issue about tbl helper usage, I could run some simple linux-user tests and boot a rather large Linux image. It looks like the kernel boot is about 5% slower. Laurent URL git://repo.or.cz/qemu/blueswirl.git http://repo.or.cz/r/qemu/blueswirl.git Blue Swirl (6): arm: move neon_tbl to neon_helper.c arm: move saturating arithmetic to helper.c arm: move other arithmetic to helper.c arm: move cpsr and banked register access to helper.c arm: move exception and wfi helpers to helper.c arm: move load and store helpers, switch to AREG0 free mode Makefile.target | 4 +- configure | 2 +- target-arm/helper.c | 388 +- target-arm/helper.h | 60 target-arm/neon_helper.c | 22 +++ target-arm/op_helper.c | 430 -- target-arm/translate.c | 148 7 files changed, 513 insertions(+), 541 deletions(-) delete mode 100644 target-arm/op_helper.c -- 1.7.9
Re: [Qemu-devel] [Bug 932487] Re: win32: git rev 59f971d crashes when accessing disk (coroutine issue)
Il 20/03/2012 10:35, Roy Tam ha scritto: 2012/3/20 Stefan Weil 932...@bugs.launchpad.net: Please try a newer compiler. gcc-4.6.2 compiles thread local storage correctly, gcc-4.3.3 obviously doesn't. If you can confirm that newer compilers fix this bug, I'd like to close this ticket. I'm using gcc-4.6.2 now. Please test this suggestion: Please try these modified configure option which adds the compiler flag needed for multithreading: --extra-cflags=-O0 -pipe -mthreads. For me, -mthreads solved the problem. Yes -mthreads switch does workaround the issue. But using -mthreads making resulting binaries depend on mingwm10.dll, which is not good. Is -D_MT enough instead of -mthreads? Paolo
[Qemu-devel] [Bug 916720] Re: select fails on windows because a non-socket fd is in the rfds set
Patches posted to the list. http://permalink.gmane.org/gmane.comp.emulators.qemu/142634 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/916720 Title: select fails on windows because a non-socket fd is in the rfds set Status in QEMU: New Bug description: The select call in file main_loop.c at line 460 fails on windows because a non-socket fd is in the rfds set. As a result, gdb remote connections will never be accepted by qemu. The select function returns with -1. WSAGetLastError returns code 10038 (WSAENOTSOCK). I start qemu as follows: qemu-system-arm -cpu cortex-m3 -M lm3s6965evb -nographic -monitor null -serial null -semihosting -kernel test1.elf -S -gdb tcp:127.0.0.1:2200 qemu is configure with: CFLAGS=-O4 -march=i686 configure --target-list=i386-softmmu arm-softmmu sparc-softmmu ppc-softmmu --prefix=/home/qemu/install --cc=mingw32-gcc --host-cc=mingw32-gcc --audio-drv-list=dsound sdl --audio-card-list=ac97 es1370 sb16 cs4231a adlib gus To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/916720/+subscriptions
[Qemu-devel] [PATCH 6/6] main-loop: integrate glib sources for w32
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
main-loop.c | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/main-loop.c b/main-loop.c
index 4d02568..7e163f9 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -221,11 +221,10 @@ int main_loop_init(void)
static fd_set rfds, wfds, xfds;
static int nfds;
static GPollFD poll_fds[1024 * 2]; /* this is probably overkill */
-
-#ifndef _WIN32
static int n_poll_fds;
static int max_priority;
+#ifndef _WIN32
static void glib_select_fill(int *max_fd, fd_set *rfds, fd_set *wfds,
fd_set *xfds, int *cur_timeout)
{
@@ -403,6 +402,7 @@ void qemu_fd_register(int fd)
static int os_host_main_loop_wait(int timeout)
{
+GMainContext *context = g_main_context_default();
int ret, i;
PollingEntry *pe;
WaitObjects *w = wait_objects;
@@ -424,17 +424,22 @@ static int os_host_main_loop_wait(int timeout)
}
}
+g_main_context_prepare(context, max_priority);
+n_poll_fds = g_main_context_query(context, max_priority, timeout,
+ poll_fds, ARRAY_SIZE(poll_fds));
+g_assert(n_poll_fds = ARRAY_SIZE(poll_fds));
+
for (i = 0; i w-num; i++) {
-poll_fds[i].fd = (DWORD) w-events[i];
-poll_fds[i].events = G_IO_IN;
+poll_fds[n_poll_fds + i].fd = (DWORD) w-events[i];
+poll_fds[n_poll_fds + i].events = G_IO_IN;
}
qemu_mutex_unlock_iothread();
-ret = g_poll(poll_fds, w-num, timeout);
+ret = g_poll(poll_fds, n_poll_fds + w-num, timeout);
qemu_mutex_lock_iothread();
if (ret 0) {
for (i = 0; i w-num; i++) {
-w-revents[i] = poll_fds[i].revents;
+w-revents[i] = poll_fds[n_poll_fds + i].revents;
}
for (i = 0; i w-num; i++) {
if (w-revents[i] w-func[i]) {
@@ -443,6 +448,10 @@ static int os_host_main_loop_wait(int timeout)
}
}
+if (g_main_context_check(context, max_priority, poll_fds, n_poll_fds)) {
+g_main_context_dispatch(context);
+}
+
/* If an edge-triggered socket event occurred, select will return a
* positive result on the next iteration. We do not need to do anything
* here.
--
1.7.7.6
[Qemu-devel] [PATCH 3/6] main-loop: disable fd_set-based glib integration under w32
Using select with glib pollfds is wrong under w32. Restrict
the code to the POSIX case.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
main-loop.c | 63 ++
1 files changed, 33 insertions(+), 30 deletions(-)
diff --git a/main-loop.c b/main-loop.c
index a3fd993..dc6bdb5 100644
--- a/main-loop.c
+++ b/main-loop.c
@@ -218,7 +218,10 @@ int main_loop_init(void)
return 0;
}
+static fd_set rfds, wfds, xfds;
+static int nfds;
+#ifndef _WIN32
static GPollFD poll_fds[1024 * 2]; /* this is probably overkill */
static int n_poll_fds;
static int max_priority;
@@ -286,7 +289,29 @@ static void glib_select_poll(fd_set *rfds, fd_set *wfds,
fd_set *xfds,
}
}
-#ifdef _WIN32
+static int os_host_main_loop_wait(int timeout)
+{
+struct timeval tv;
+int ret;
+
+glib_select_fill(nfds, rfds, wfds, xfds, timeout);
+
+if (timeout 0) {
+qemu_mutex_unlock_iothread();
+}
+
+tv.tv_sec = timeout / 1000;
+tv.tv_usec = (timeout % 1000) * 1000;
+ret = select(nfds + 1, rfds, wfds, xfds, tv);
+
+if (timeout 0) {
+qemu_mutex_lock_iothread();
+}
+
+glib_select_poll(rfds, wfds, xfds, (ret 0));
+return ret;
+}
+#else
/***/
/* Polling handling */
@@ -367,10 +392,11 @@ void qemu_del_wait_object(HANDLE handle, WaitObjectFunc
*func, void *opaque)
}
}
-static void os_host_main_loop_wait(int *timeout)
+static int os_host_main_loop_wait(int timeout)
{
int ret, ret2, i;
PollingEntry *pe;
+static struct timeval tv0;
/* XXX: need to suppress polling by better using win32 events */
ret = 0;
@@ -382,7 +408,7 @@ static void os_host_main_loop_wait(int *timeout)
WaitObjects *w = wait_objects;
qemu_mutex_unlock_iothread();
-ret = WaitForMultipleObjects(w-num, w-events, FALSE, *timeout);
+ret = WaitForMultipleObjects(w-num, w-events, FALSE, timeout);
qemu_mutex_lock_iothread();
if (WAIT_OBJECT_0 + 0 = ret ret = WAIT_OBJECT_0 + w-num - 1) {
if (w-func[ret - WAIT_OBJECT_0]) {
@@ -408,20 +434,14 @@ static void os_host_main_loop_wait(int *timeout)
}
}
-*timeout = 0;
-}
-#else
-static inline void os_host_main_loop_wait(int *timeout)
-{
+ret = select(nfds + 1, rfds, wfds, xfds, tv0);
+return ret;
}
#endif
int main_loop_wait(int nonblocking)
{
-fd_set rfds, wfds, xfds;
-int ret, nfds;
-struct timeval tv;
-int timeout;
+int ret, timeout;
if (nonblocking) {
timeout = 0;
@@ -441,24 +461,7 @@ int main_loop_wait(int nonblocking)
slirp_select_fill(nfds, rfds, wfds, xfds);
#endif
qemu_iohandler_fill(nfds, rfds, wfds, xfds);
-
-glib_select_fill(nfds, rfds, wfds, xfds, timeout);
-os_host_main_loop_wait(timeout);
-
-tv.tv_sec = timeout / 1000;
-tv.tv_usec = (timeout % 1000) * 1000;
-
-if (timeout 0) {
-qemu_mutex_unlock_iothread();
-}
-
-ret = select(nfds + 1, rfds, wfds, xfds, tv);
-
-if (timeout 0) {
-qemu_mutex_lock_iothread();
-}
-
-glib_select_poll(rfds, wfds, xfds, (ret 0));
+ret = os_host_main_loop_wait(timeout);
qemu_iohandler_poll(rfds, wfds, xfds, ret);
#ifdef CONFIG_SLIRP
slirp_select_poll(rfds, wfds, xfds, (ret 0));
--
1.7.7.6
Re: [Qemu-devel] Build broken -- qemu-ga: add guest-network-get-interfaces command
On 18.03.2012 02:09, Brad Smith wrote: Michal, http://git.qemu.org/?p=qemu.git;a=commit;h=3424fc9f16a1e7d1c48eb6d605eb0ca63e199ec2 This broke the build. Un-break the tree. Can you please be more specific? It works for me so I don't have a clue what are you referring to. I mean, what compiler do you use, what errors are thrown, etc. Michal
Re: [Qemu-devel] [PATCH] Remove PCI class code from virtio balloon device
On Tue, Mar 20, 2012 at 09:54:20AM +, Stefan Hajnoczi wrote: On Tue, Mar 20, 2012 at 12:42 AM, David Gibson da...@gibson.dropbear.id.au wrote: On Mon, Mar 19, 2012 at 11:33:10AM +, Stefan Hajnoczi wrote: On Mon, Mar 19, 2012 at 03:59:23PM +1100, David Gibson wrote: Currently the virtio balloon device, when using the virtio-pci interface advertises itself with PCI class code MEMORY_RAM. This is wrong; the balloon is vaguely related to memory, but is nothing like a PCI memory device in the meaning of the class code, and this code is not required or suggested by the virtio PCI specification. Worse, this patch causes problems on the pseries machine, because the firmware, seeing this class code, advertises the device as memory in the device tree, and then a guest kernel bug causes it to see this memory before the real system memory, leading to a crash in early boot. This patch fixes the problem by removing the bogus PCI class code on the balloon device. Cc: Michael S. Tsirkin m...@redhat.com Cc: Rusty Russell ru...@rustcorp.com.au Signed-off-by: David Gibson da...@gibson.dropbear.id.au --- hw/virtio-pci.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Since this is a guest-visible change we might need to be careful about how it's introduced. Do we need to keep the old class code for existing machine types? The new class code could be introduced only for 1.1 and later machine types if we want to be extra careful about introducing guest-visible changes. So as a general rule, I like to be very careful about user-visible changes. But in this case, I don't think we want to be too hesitant. In particular, it's not just a question of the machine type, but also of how the guest OS will deal with the PCI class code. The class code we were using was Just Plain Wrong. It was not suggetsed by the virtio spec, and it makes no sense. It happens that so far this caused problems only for a guest on a particular machine type, but there's no reason it couldn't cause (different) problems for guests on any machine type. More to the point, it seems reasonably unlikely for existing guests to rely on the broken behaviour: again, there's no reason they'd think they need to based on the spec, and the usual way of matching drivers to PCI devices is with the vendor/device IDs which are correct and not changed by this patch. So, unless we have a known example of an existing guest that would be broken by this change, I think we should implement it ASAP for all machine types. I agree that in practice the risk is low because working guests are probably not using the class code. On the other hand I don't see a downside to making this part of the 1.1 machine type, Well.. there's the fact that I can't what mechanism we would use to make this per-machine... which is what users will run when they get this code change anyway. That way we can tell users that we never change the device model in a release with a straight face :). Anthony: I'm not sure how strict we are about a user-visible change like this? Stefan -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Re: [Qemu-devel] [PATCH 8/9] vl: add -query-capabilities
On Tue, Mar 20, 2012 at 08:49:11AM +0100, Gerd Hoffmann wrote: On 03/19/12 16:09, Anthony Liguori wrote: This dumps the results of query-version, query-commands, and query-config-capabilities into a single JSON object on stdout. I think libvirt needs a query-devices too. Currently we get capability like info in the following areas: * List of CPUs: $QEMU -cpu ? * List of machine types: $QEMU -M ? * List of devices properties: $QEMU -device ? \ -device pci-assign,? \ -device virtio-blk-pci,? \ -device virtio-net-pci,? \ -device scsi-disk,? As well as 80 odd other pieces of information[1] via -help, but lets not get side tracked by those right now. What is proposed so far is a good start, we can iteratively build on. If we can get the above commands into JSON format too, that'd be nice so that we can have one parser to rule them all. Regards, Daniel [1] See the comments in the enum here for details of what we get from -help http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_capabilities.h;hb=HEAD -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PATCH] Remove PCI class code from virtio balloon device
On Tue, Mar 20, 2012 at 11:42:06AM +1100, David Gibson wrote: On Mon, Mar 19, 2012 at 11:33:10AM +, Stefan Hajnoczi wrote: On Mon, Mar 19, 2012 at 03:59:23PM +1100, David Gibson wrote: Currently the virtio balloon device, when using the virtio-pci interface advertises itself with PCI class code MEMORY_RAM. This is wrong; the balloon is vaguely related to memory, but is nothing like a PCI memory device in the meaning of the class code, and this code is not required or suggested by the virtio PCI specification. Worse, this patch causes problems on the pseries machine, because the firmware, seeing this class code, advertises the device as memory in the device tree, and then a guest kernel bug causes it to see this memory before the real system memory, leading to a crash in early boot. This patch fixes the problem by removing the bogus PCI class code on the balloon device. Cc: Michael S. Tsirkin m...@redhat.com Cc: Rusty Russell ru...@rustcorp.com.au Signed-off-by: David Gibson da...@gibson.dropbear.id.au --- hw/virtio-pci.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Since this is a guest-visible change we might need to be careful about how it's introduced. Do we need to keep the old class code for existing machine types? The new class code could be introduced only for 1.1 and later machine types if we want to be extra careful about introducing guest-visible changes. So as a general rule, I like to be very careful about user-visible changes. But in this case, I don't think we want to be too hesitant. In particular, it's not just a question of the machine type, but also of how the guest OS will deal with the PCI class code. The class code we were using was Just Plain Wrong. It was not suggetsed by the virtio spec, and it makes no sense. It happens that so far this caused problems only for a guest on a particular machine type, but there's no reason it couldn't cause (different) problems for guests on any machine type. More to the point, it seems reasonably unlikely for existing guests to rely on the broken behaviour: again, there's no reason they'd think they need to based on the spec, and the usual way of matching drivers to PCI devices is with the vendor/device IDs which are correct and not changed by this patch. So, unless we have a known example of an existing guest that would be broken by this change, I think we should implement it ASAP for all machine types. Talked with windows driver guys. It seems their driver does not check the class code, but one thing that will happen if this is changed across migration, is that on bus rescan, windows will detect a change and driver will get re-installed. For the baloon, this will give all memory back to guest, which seems undesirable. So I think keeping the old class for old machine types is the prudent thing to do. I also removed Cc qemu-trivial - it's a short but non-trivial patch. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au| minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Re: [Qemu-devel] [Bug 959852] [NEW] Build fails: osx 10.7, deprecated CoreAudio APIs
Am 20.03.2012 02:13, schrieb Hans Simer: Public bug reported: Virtual audio driver for darwin is using deprecated APIs. [...] ○ → make . . . CCaudio/noaudio.o CCaudio/wavaudio.o CCaudio/mixeng.o CCaudio/coreaudio.o audio/coreaudio.c: In function ‘isPlaying’: audio/coreaudio.c:152: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) audio/coreaudio.c: In function ‘coreaudio_init_out’: audio/coreaudio.c:310: warning: ‘AudioHardwareGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:1270) audio/coreaudio.c:326: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) audio/coreaudio.c:353: warning: ‘AudioDeviceSetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2675) audio/coreaudio.c:370: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) audio/coreaudio.c:386: warning: ‘AudioDeviceGetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2640) audio/coreaudio.c:403: warning: ‘AudioDeviceSetProperty’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2675) audio/coreaudio.c:419: warning: ‘AudioDeviceAddIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2419) audio/coreaudio.c:431: warning: ‘AudioDeviceRemoveIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2433) audio/coreaudio.c: In function ‘coreaudio_fini_out’: audio/coreaudio.c:456: warning: ‘AudioDeviceRemoveIOProc’ is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2433) CCaudio/wavcapture.o This is not a build failure, just warnings. If you want these fixed, please investigate what non-deprecated API can be used instead and prepare a patch that works both on older and on your version. 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 v4 1/2] qemu-socket: change inet_connect() to to support nonblock socket
On 03/19/2012 04:11 PM, Amos Kong wrote:
Change inet_connect(const char *str, int socktype) to
inet_connect(const char *str, bool block, int *sock_err),
socktype is unused, block is used to assign if set socket
to block/nonblock, sock_err is used to restore socket error.
It is more common to call the parameter blocking/nonblocking.
You removed socktype (I noticed it was not implemented) , can you keep the same
API but fix the implementation ?
I don't like the use of sock_err.
How about adding a function set_socket_error that will set the errno and for
win32 you can use SetLastError,
you will be able to read the error using socket_error function.
Cheers,
Orit
Connect's successful for nonblock socket when following errors are returned:
-EINPROGRESS or -EWOULDBLOCK
-WSAEALREADY or -WSAEINVAL (win32)
Also change the wrap function inet_connect_opts(QemuOpts *opts)
to inet_connect_opts(QemuOpts *opts, int *sock_err).
Add a bool entry(block) for dummy_opts to tag block type.
Change nbd, vnc to use new interface.
Signed-off-by: Amos Kong ak...@redhat.com
---
nbd.c |2 +-
qemu-char.c|2 +-
qemu-sockets.c | 73
qemu_socket.h |4 ++-
ui/vnc.c |2 +-
5 files changed, 62 insertions(+), 21 deletions(-)
diff --git a/nbd.c b/nbd.c
index 567e94e..ad4de06 100644
--- a/nbd.c
+++ b/nbd.c
@@ -146,7 +146,7 @@ int tcp_socket_outgoing(const char *address, uint16_t
port)
int tcp_socket_outgoing_spec(const char *address_and_port)
{
-return inet_connect(address_and_port, SOCK_STREAM);
+return inet_connect(address_and_port, true, NULL);
}
int tcp_socket_incoming(const char *address, uint16_t port)
diff --git a/qemu-char.c b/qemu-char.c
index bb9e3f5..d3543ea 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -2443,7 +2443,7 @@ static CharDriverState *qemu_chr_open_socket(QemuOpts
*opts)
if (is_listen) {
fd = inet_listen_opts(opts, 0);
} else {
-fd = inet_connect_opts(opts);
+fd = inet_connect_opts(opts, NULL);
}
}
if (fd 0) {
diff --git a/qemu-sockets.c b/qemu-sockets.c
index 6bcb8e3..8ed45f8 100644
--- a/qemu-sockets.c
+++ b/qemu-sockets.c
@@ -51,6 +51,9 @@ static QemuOptsList dummy_opts = {
},{
.name = ipv6,
.type = QEMU_OPT_BOOL,
+},{
+.name = block,
+.type = QEMU_OPT_BOOL,
},
{ /* end if list */ }
},
@@ -194,14 +197,15 @@ listen:
return slisten;
}
-int inet_connect_opts(QemuOpts *opts)
+int inet_connect_opts(QemuOpts *opts, int *sock_err)
{
struct addrinfo ai,*res,*e;
const char *addr;
const char *port;
char uaddr[INET6_ADDRSTRLEN+1];
char uport[33];
-int sock,rc;
+int sock, rc, err;
+bool block;
memset(ai,0, sizeof(ai));
ai.ai_flags = AI_CANONNAME | AI_ADDRCONFIG;
@@ -210,9 +214,11 @@ int inet_connect_opts(QemuOpts *opts)
addr = qemu_opt_get(opts, host);
port = qemu_opt_get(opts, port);
+block = qemu_opt_get_bool(opts, block, 0);
if (addr == NULL || port == NULL) {
fprintf(stderr, inet_connect: host and/or port not specified\n);
-return -1;
+err = -EINVAL;
+goto err;
}
if (qemu_opt_get_bool(opts, ipv4, 0))
@@ -224,7 +230,8 @@ int inet_connect_opts(QemuOpts *opts)
if (0 != (rc = getaddrinfo(addr, port, ai, res))) {
fprintf(stderr,getaddrinfo(%s,%s): %s\n, addr, port,
gai_strerror(rc));
- return -1;
+err = -EINVAL;
+goto err;
}
for (e = res; e != NULL; e = e-ai_next) {
@@ -241,21 +248,52 @@ int inet_connect_opts(QemuOpts *opts)
continue;
}
setsockopt(sock,SOL_SOCKET,SO_REUSEADDR,(void*)on,sizeof(on));
-
+if (!block) {
+socket_set_nonblock(sock);
+}
/* connect to peer */
-if (connect(sock,e-ai_addr,e-ai_addrlen) 0) {
-if (NULL == e-ai_next)
-fprintf(stderr, %s: connect(%s,%s,%s,%s): %s\n,
__FUNCTION__,
-inet_strfamily(e-ai_family),
-e-ai_canonname, uaddr, uport, strerror(errno));
-closesocket(sock);
-continue;
+do {
+err = 0;
+if (connect(sock, e-ai_addr, e-ai_addrlen) 0) {
+err = -socket_error();
+if (block) {
+break;
+}
+}
+} while (err == -EINTR);
+
+if (err = 0) {
+goto success;
+} else if (!block (err == -EINPROGRESS || err == -EWOULDBLOCK)) {
+goto success;
+#ifdef _WIN32
+} else if (!block (sock_err == -WSAEALREADY ||
+ sock_err == -WSAEINVAL)) {
[Qemu-devel] [PATCH] spice: fix 32bit build
New 32bit warnings sneaked in, this time in
ui/spice-display.c, fix them.
This gets annonying, /me sets up a ubuntu buildbot
slave for 32bit spice testbuilds.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
roms/seabios |2 +-
ui/spice-display.c | 12 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/roms/seabios b/roms/seabios
index 2e8bd61..80d11e8 16
--- a/roms/seabios
+++ b/roms/seabios
@@ -1 +1 @@
-Subproject commit 2e8bd611ce4e1e36b5a80c9ca6e256e23802f095
+Subproject commit 80d11e8577bf03e98f2eb1b0cb3a281ab2879c9e
diff --git a/ui/spice-display.c b/ui/spice-display.c
index 28d6d4a..6d7563f 100644
--- a/ui/spice-display.c
+++ b/ui/spice-display.c
@@ -80,8 +80,8 @@ void qemu_spice_add_memslot(SimpleSpiceDisplay *ssd,
QXLDevMemSlot *memslot,
if (async != QXL_SYNC) {
spice_qxl_add_memslot_async(ssd-qxl, memslot,
-(uint64_t)qxl_cookie_new(QXL_COOKIE_TYPE_IO,
- QXL_IO_MEMSLOT_ADD_ASYNC));
+(uintptr_t)qxl_cookie_new(QXL_COOKIE_TYPE_IO,
+ QXL_IO_MEMSLOT_ADD_ASYNC));
} else {
ssd-worker-add_memslot(ssd-worker, memslot);
}
@@ -100,8 +100,8 @@ void qemu_spice_create_primary_surface(SimpleSpiceDisplay
*ssd, uint32_t id,
trace_qemu_spice_create_primary_surface(ssd-qxl.id, id, surface, async);
if (async != QXL_SYNC) {
spice_qxl_create_primary_surface_async(ssd-qxl, id, surface,
-(uint64_t)qxl_cookie_new(QXL_COOKIE_TYPE_IO,
- QXL_IO_CREATE_PRIMARY_ASYNC));
+(uintptr_t)qxl_cookie_new(QXL_COOKIE_TYPE_IO,
+ QXL_IO_CREATE_PRIMARY_ASYNC));
} else {
ssd-worker-create_primary_surface(ssd-worker, id, surface);
}
@@ -113,8 +113,8 @@ void qemu_spice_destroy_primary_surface(SimpleSpiceDisplay
*ssd,
trace_qemu_spice_destroy_primary_surface(ssd-qxl.id, id, async);
if (async != QXL_SYNC) {
spice_qxl_destroy_primary_surface_async(ssd-qxl, id,
-(uint64_t)qxl_cookie_new(QXL_COOKIE_TYPE_IO,
- QXL_IO_DESTROY_PRIMARY_ASYNC));
+(uintptr_t)qxl_cookie_new(QXL_COOKIE_TYPE_IO,
+ QXL_IO_DESTROY_PRIMARY_ASYNC));
} else {
ssd-worker-destroy_primary_surface(ssd-worker, id);
}
--
1.7.1
Re: [Qemu-devel] [PATCH] spice: fix 32bit build
On 20 March 2012 11:26, Gerd Hoffmann kra...@redhat.com wrote: New 32bit warnings sneaked in, this time in ui/spice-display.c, fix them. This gets annonying, /me sets up a ubuntu buildbot slave for 32bit spice testbuilds. Signed-off-by: Gerd Hoffmann kra...@redhat.com --- roms/seabios | 2 +- ui/spice-display.c | 12 ++-- What's the roms/seabios change doing here? Also, isn't the ui/spice-display.c patch the same as this one from me from a couple of weeks back? http://patchwork.ozlabs.org/patch/145269/ -- PMM
Re: [Qemu-devel] [PATCH] block: add the support to drain throttled requests
On Tue, Mar 20, 2012 at 10:58:10AM +0100, Kevin Wolf wrote:
Am 20.03.2012 10:47, schrieb Paolo Bonzini:
Il 20/03/2012 10:40, Zhi Yong Wu ha scritto:
HI, Kevin,
We hope that I/O throttling can be shipped without known issue in QEMU
1.1, so if you are available, can you give this patch some love?
I'm sorry to say this, but I think I/O throttling is impossible to save.
As it is implemented now, it just cannot work in the presence of
synchronous I/O, except at the cost of busy waiting with the global
mutex taken. See the message from Stefan yesterday.
qemu_aio_flush() is busy waiting with the global mutex taken anyway, so
it doesn't change that much.
Yesterday I only posted an analysis of the bug but here are some
thoughts on how to move forward. Throttling itself is not the problem.
We've known that synchronous operations in the vcpu thread are a problem
long before throttling. This is just another reason to convert device
emulation to use asynchronous interfaces.
Here is the list of device models that perform synchronous block I/O:
hw/fdc.c
hw/ide/atapi.c
hw/ide/core.c
hw/nand.c
hw/onenand.c
hw/pflash_cfi01.c
hw/pflash_cfi02.c
hw/sd.c
Zhi Hui Li is working on hw/fdc.c and recently sent a patch.
I think it's too close to QEMU 1.1 to convert all the remaining devices
and test them properly before the soft-freeze. But it's probably
possible to convert IDE before the soft-freeze.
In the meantime we could add this to bdrv_rw_co():
if (bs-io_limits_enabled) {
fprintf(stderr, Disabling I/O throttling on '%s' due
to synchronous I/O\n, bdrv_get_device_name(bs));
bdrv_io_limits_disable(bs);
}
It's not pretty but tells the user there is an issue and avoids
deadlocking.
Stefan
Re: [Qemu-devel] [PATCH 0/2] linux-user: Support prctl PR_GET/SET_NAME
Ping^3 (past the six-week mark now...) -- PMM On 8 March 2012 14:20, Peter Maydell peter.mayd...@linaro.org wrote: Ping^2 ? -- PMM On 22 February 2012 22:55, Peter Maydell peter.mayd...@linaro.org wrote: Ping? On 3 February 2012 13:53, Peter Maydell peter.mayd...@linaro.org wrote: These patches add support for the prctl options PR_GET_NAME and PR_SET_NAME. In particular, perl 5.14 will use PR_SET_NAME if you change the value of $0, which means that adduser will fail if run under qemu with a sufficiently modern perl. Patch one is just indentation cleanup, the meat is patch 2. The only other prctl options which take pointer arguments are all architecture specific, so there didn't seem much point in adding them (they all work like PR_GET_PDEATHSIG in that they pass an int* to be filled in); we'd have to actually emulate them if we cared about them. Peter Maydell (2): linux-user/syscall.c: Fix indentation in prctl handling linux-user: Add support for prctl PR_GET_NAME and PR_SET_NAME linux-user/syscall.c | 53 - 1 files changed, 39 insertions(+), 14 deletions(-)
Re: [Qemu-devel] [PATCH 23/36] arm: save always 32 fpu registers
On 19 March 2012 22:57, Juan Quintela quint...@redhat.com wrote: This way, we fix a bug (we were overwritten the 16 first registers on load), and we don't need to check for ARM_FEATUR_VPF3, we always send the 32 registers. This commit message is out of date -- the overwriting bug was fixed in commit 15180256 last year. Possibly the patch should be dropped from your series? (If not, ARM_FEATURE_VFP3.) -- PMM
[Qemu-devel] ARM QOM conversion / class hierarchy
(I can't find the relevant patches in the mailing list at this point. I'm talking about this tree from Andreas: http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/qom-cpu-arm ) So in an IRC discussion yesterday we didn't seem to make much headway on what the right class hierarchy is here. There seem to be two basic options: (1) subclass per CPU type This is what Andreas' tree does at the moment, so there's an ARMCPU which is a subclass of CPUState, and then a lot of subclasses of that, one per CPU (arm926, arm1026, cortex-a8, cortex-a9, etc). Mostly these subclasses just arrange for different reset values for various registers, setting feature bits, etc. (2) no subclasses for CPU types This approach would just have a single ARMCPU, and then -cpu foo is syntactic sugar for setting a lot of qom properties. Option two looks kind of nice, but I'm not sure whether it would actually work. I think you could do 95% of what you need for a different CPU that way (lots of properties for value of ID_MMFR1, value of ID_MMFR2, reset value of SCTLR, etc etc, plus properties for all our existing ARM_FEATURE_*, and some new ones where we're currently keying off which CPU is this? rather than using a feature bit, or just failing to distinguish things which aren't really common to all CPUs). But I'm not sure how you'd handle the genuinely implementation specific cp15 registers (eg cp15 crn=15). We could have a property which says is this a 926/1026/1176/A8/A9/... (or equivalently, key off the relevant fields of the main ID register) but it doesn't seem very OO-like to have one class whose behaviour changes based on an integer that's basically defining an ad-hoc sub-type... Regardless, it seems to me that we ought to be doing this the same way for all our target CPUs. I don't know whether mips/x86/ etc have any preference one way or the other. -- PMM
Re: [Qemu-devel] [PATCH] spice: fix 32bit build
Hi, What's the roms/seabios change doing here? Just a missing git submodule update and the diff from that sneaking in. Also, isn't the ui/spice-display.c patch the same as this one from me from a couple of weeks back? http://patchwork.ozlabs.org/patch/145269/ It is. Picked that one up instead. /me is confused, I through I had that one already and we just got new warnings, sorry. cheers, Gerd
Re: [Qemu-devel] [PATCH] spice: fix 32bit build
On 20 March 2012 12:13, Gerd Hoffmann kra...@redhat.com wrote: Also, isn't the ui/spice-display.c patch the same as this one from me from a couple of weeks back? http://patchwork.ozlabs.org/patch/145269/ It is. Picked that one up instead. /me is confused, I through I had that one already and we just got new warnings, sorry. No problem. (I was under the impression that had been committed already as well for some reason...) -- PMM
Re: [Qemu-devel] [RFC/RFA PATCH] qapi: detect extra members inside structs
On Mon, 19 Mar 2012 19:49:46 -0500 Anthony Liguori anth...@codemonkey.ws wrote: On 03/19/2012 06:45 PM, Michael Roth wrote: So IMO, returning arguments actually seems easier for both clients and the server, and is more resilient to downstream changes. It does require a more formal specification of the protocol though. Basically: an option/field may not be supported in older/future versions of QEMU, so it is up to the client to check in advance by referencing the QAPI schema for their qemu version or programatically via get_schema(command) The complexity of writing a client using get_schema() is close to staggering :-/ I'm not sure, I mean, take libvirt, you need to marshall up the arguments anyway and put them into a QMP payload, so in that case the client developer is aware of the schema that they're coding against, and also understand the QAPI schema specification, and if the schema is nested then so is the client version of that schema. So, conceptually at least, it seems like it wouldn't be that big a jump to maintain an internal representation of their schema to programatically check against the specification they were coding against, it's just the part where they then need to bake it into the client implementation that's a bit heavy-handed. So let's work through a few examples. Today, you have to maintain a list of commands returned from query-commands and check for set membership: if 'query-netdev2' in commands: qmp.query_netdev2(foo) else: qmp.query_netdev() Pretty simple. If we have a schema representation, we'll need to be able to check for arguments. Aren't we going to have the schema representation anyway? Or if we go for the way above we are not going to have it?
Re: [Qemu-devel] [PATCH v4 0/7] RTC: New logic to emulate RTC
Il 19/03/2012 07:13, Zhang, Yang Z ha scritto:
Current RTC emulation uses periodic timer(2 timers per second) to
update RTC clock. And it will stop CPU staying at deep C-state for
long period. Our experience shows the Pkg C6 residency reduced 6%
when running 64 idle guest. The following patch stop the two periodic
timer and only updating RTC clock when guest try to read it.
I attach a patch that fixes some problems with divider reset and in
general simplifies the logic. Even with the patch, however, I still see
failures in my test case unfortunately. Probably there are rounding
errors somewhere.
Also (minor change) you need to use rtc_clock instead of host_clock.
I'm afraid that we're hitting a wall. :( The problem I have is that the
logic in your patch is very complex and, without understanding it well,
I'm afraid we'll never be able to fix it completely (while the old
inefficient one is buggy but it _can_ be fixed).
By the way in general the SET bit and the divider should be handled in
the same way, because both stop the updates. That is, in general there
should be a function like
static inline bool rtc_running(RTCState *s)
{
return (!(s-cmos_data[RTC_REG_B] REG_B_SET)
(s-cmos_data[RTC_REG_A] 0x70) == 0x20);
}
that is used instead of testing REG_B_SET. I pushed some work along
these lines at git://github.com/bonzini/qemu.git (branch rtc-intel), but
it does not really improve the situation with respect to rounding errors
so the bug must be elsewhere.
Paolo
From 198afe37adb532738a55dd32ef8bd533c2493c65 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini pbonz...@redhat.com
Date: Tue, 20 Mar 2012 12:21:00 +0100
Subject: [PATCH] fixes
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
hw/mc146818rtc.c | 34 --
1 files changed, 16 insertions(+), 18 deletions(-)
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 22a9f40..f94ddbb 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -123,8 +123,6 @@ static void rtc_set_cmos(RTCState *s);
static inline int rtc_from_bcd(RTCState *s, int a);
static uint64_t get_next_alarm(RTCState *s);
-static int32_t divider_reset;
-
static uint64_t get_guest_rtc_us(RTCState *s)
{
int64_t host_usec, offset_usec, guest_usec;
@@ -489,7 +487,8 @@ static void rtc_update_timer2(void *opaque)
RTCState *s = opaque;
int32_t alarm_fired;
-if (!(s-cmos_data[RTC_REG_B] REG_B_SET)) {
+if (!(s-cmos_data[RTC_REG_B] REG_B_SET)
+(s-cmos_data[RTC_REG_A] 0x70) == 0x20) {
s-cmos_data[RTC_REG_C] |= REG_C_UF;
if (check_alarm(s)) {
s-cmos_data[RTC_REG_C] |= REG_C_AF;
@@ -561,16 +560,16 @@ static void cmos_ioport_write(void *opaque, uint32_t addr, uint32_t data)
case RTC_REG_A:
/* when the divider reset is removed, the first update cycle
* begins one-half second later*/
-if (((s-cmos_data[RTC_REG_A] 0x60) == 0x60)
-((data 0x70) 4) = 2) {
-divider_reset = 1;
-if (!(s-cmos_data[RTC_REG_B] REG_B_SET)) {
-rtc_calibrate_time(s);
-rtc_set_offset(s, 50);
-s-cmos_data[RTC_REG_A] = ~REG_A_UIP;
-check_update_timer(s);
-divider_reset = 0;
-}
+if ((data 0x60) == 0x60
+(s-cmos_data[RTC_REG_A] 0x70) = 0x20) {
+rtc_calibrate_time(s);
+rtc_set_cmos(s);
+s-cmos_data[RTC_REG_A] = ~REG_A_UIP;
+ } else if ((s-cmos_data[RTC_REG_A] 0x60) == 0x60
+ (data 0x70) = 0x20) {
+rtc_set_time(s);
+rtc_set_offset(s, 50);
+check_update_timer(s);
}
/* UIP bit is read only */
s-cmos_data[RTC_REG_A] = (data ~REG_A_UIP) |
@@ -591,11 +590,7 @@ static void cmos_ioport_write(void *opaque, uint32_t addr, uint32_t data)
/* if disabling set mode, update the time */
if (s-cmos_data[RTC_REG_B] REG_B_SET) {
rtc_set_time(s);
-if (divider_reset == 1) {
-rtc_set_offset(s, 50);
-s-cmos_data[RTC_REG_A] = ~REG_A_UIP;
-divider_reset = 0;
-} else {
+if (((s-cmos_data[RTC_REG_A] 0x70) 4) = 2) {
rtc_set_offset(s, 0);
}
}
@@ -709,6 +704,9 @@ static int update_in_progress(RTCState *s)
if (s-cmos_data[RTC_REG_B] REG_B_SET) {
return 0;
}
+if ((s-cmos_data[RTC_REG_A] 0x60) == 0x60) {
+return 0;
+}
guest_usec = get_guest_rtc_us(s);
/* UIP bit will be set at last 244us of every second. */
if ((guest_usec % USEC_PER_SEC) = (USEC_PER_SEC - 244)) {
--
1.7.7.6
Re: [Qemu-devel] [PATCH 23/36] arm: save always 32 fpu registers
Peter Maydell peter.mayd...@linaro.org wrote: On 19 March 2012 22:57, Juan Quintela quint...@redhat.com wrote: This way, we fix a bug (we were overwritten the 16 first registers on load), and we don't need to check for ARM_FEATUR_VPF3, we always send the 32 registers. This commit message is out of date -- the overwriting bug was fixed in commit 15180256 last year. Possibly the patch should be dropped from your series? (If not, ARM_FEATURE_VFP3.) Reason for the change is not to have to write partial arrays. Current code is doing if ARM_FEATURE_VFP send first 16 registers if (ARM_FEATURE_VFP3 send second 16 registers I change it to: if ARM_FEATURE_VFP send 32 registers Notice that: a- there is always 32 registers b- makes the migration format the same for VFP and VFP3 c- we are already incompatible with previous versions, so this is not a problem. Normally, the less different options that we have on the migration format, the easy to make sense of it. It was not related to the bug that we used to have in this area. Later, Juan.
[Qemu-devel] [PATCH] kvm: allow arbitrarily sized mmio ioeventfd
We use a 2 byte ioeventfd for virtio memory,
add support for this.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
hw/ivshmem.c |8
kvm-all.c| 15 ---
kvm-stub.c |2 +-
kvm.h|3 ++-
4 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/hw/ivshmem.c b/hw/ivshmem.c
index 5ebf840..f02530c 100644
--- a/hw/ivshmem.c
+++ b/hw/ivshmem.c
@@ -354,8 +354,8 @@ static void close_guest_eventfds(IVShmemState *s, int posn)
guest_curr_max = s-peers[posn].nb_eventfds;
for (i = 0; i guest_curr_max; i++) {
-kvm_set_ioeventfd_mmio_long(s-peers[posn].eventfds[i],
-s-mmio_addr + DOORBELL, (posn 16) | i, 0);
+kvm_set_ioeventfd_mmio(s-peers[posn].eventfds[i],
+s-mmio_addr + DOORBELL, (posn 16) | i, 0, 4);
close(s-peers[posn].eventfds[i]);
}
@@ -500,8 +500,8 @@ static void ivshmem_read(void *opaque, const uint8_t * buf,
int flags)
}
if (ivshmem_has_feature(s, IVSHMEM_IOEVENTFD)) {
-if (kvm_set_ioeventfd_mmio_long(incoming_fd, s-mmio_addr + DOORBELL,
-(incoming_posn 16) | guest_max_eventfd, 1) 0) {
+if (kvm_set_ioeventfd_mmio(incoming_fd, s-mmio_addr + DOORBELL,
+(incoming_posn 16) | guest_max_eventfd, 1, 4) 0) {
fprintf(stderr, ivshmem: ioeventfd not available\n);
}
}
diff --git a/kvm-all.c b/kvm-all.c
index 42e5e23..bcf0dbe 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -744,10 +744,10 @@ static void kvm_mem_ioeventfd_add(MemoryRegionSection
*section,
{
int r;
-assert(match_data section-size == 4);
+assert(match_data section-size = 8);
-r = kvm_set_ioeventfd_mmio_long(fd, section-offset_within_address_space,
-data, true);
+r = kvm_set_ioeventfd_mmio(fd, section-offset_within_address_space,
+ data, true, section-size);
if (r 0) {
abort();
}
@@ -758,8 +758,8 @@ static void kvm_mem_ioeventfd_del(MemoryRegionSection
*section,
{
int r;
-r = kvm_set_ioeventfd_mmio_long(fd, section-offset_within_address_space,
-data, false);
+r = kvm_set_ioeventfd_mmio(fd, section-offset_within_address_space,
+ data, false, section-size);
if (r 0) {
abort();
}
@@ -1639,14 +1639,15 @@ int kvm_set_signal_mask(CPUArchState *env, const
sigset_t *sigset)
return r;
}
-int kvm_set_ioeventfd_mmio_long(int fd, uint32_t addr, uint32_t val, bool
assign)
+int kvm_set_ioeventfd_mmio(int fd, uint32_t addr, uint32_t val, bool assign,
+ uint32_t size)
{
int ret;
struct kvm_ioeventfd iofd;
iofd.datamatch = val;
iofd.addr = addr;
-iofd.len = 4;
+iofd.len = size;
iofd.flags = KVM_IOEVENTFD_FLAG_DATAMATCH;
iofd.fd = fd;
diff --git a/kvm-stub.c b/kvm-stub.c
index 69a1228..0d426db 100644
--- a/kvm-stub.c
+++ b/kvm-stub.c
@@ -120,7 +120,7 @@ int kvm_set_ioeventfd_pio_word(int fd, uint16_t addr,
uint16_t val, bool assign)
return -ENOSYS;
}
-int kvm_set_ioeventfd_mmio_long(int fd, uint32_t adr, uint32_t val, bool
assign)
+int kvm_set_ioeventfd_mmio(int fd, uint32_t adr, uint32_t val, bool assign,
uint32_t len)
{
return -ENOSYS;
}
diff --git a/kvm.h b/kvm.h
index 330f17b..9bdbdb0 100644
--- a/kvm.h
+++ b/kvm.h
@@ -210,7 +210,8 @@ int kvm_physical_memory_addr_from_host(KVMState *s, void
*ram_addr,
#endif
#endif
-int kvm_set_ioeventfd_mmio_long(int fd, uint32_t adr, uint32_t val, bool
assign);
+int kvm_set_ioeventfd_mmio(int fd, uint32_t adr, uint32_t val, bool assign,
+ uint32_t size);
int kvm_set_ioeventfd_pio_word(int fd, uint16_t adr, uint16_t val, bool
assign);
#endif
--
1.7.9.111.gf3fb0
Re: [Qemu-devel] [PATCH] spice: fix 32bit build
20.03.2012 15:26, Gerd Hoffmann wrote: New 32bit warnings sneaked in, this time in ui/spice-display.c, fix them. This gets annonying, /me sets up a ubuntu buildbot slave for 32bit spice testbuilds. Um, is it worth to watch/fix? Note that spice does not work on 32bits anyway, qemu segfaults at startup... http://bugs.debian.org/640139 (the bug was still valid when 1.0 was released). Thanks, /mjt
Re: [Qemu-devel] [PATCH 2/2] Expose tsc deadline timer cpuid to guest
Rik van Riel wrote: On 03/09/2012 01:27 PM, Liu, Jinsong wrote: As for 'tsc deadline' feature exposing, my patch (as attached) just obey qemu general cpuid exposing method, and also satisfied your target I think. One question. Why is TSC_DEADLINE not exposed in the cpuid allowed feature bits in do_cpuid_ent() in arch/x86/kvm/x86.c ? /* cpuid 1.ecx */ const u32 kvm_supported_word4_x86_features = F(XMM3) | F(PCLMULQDQ) | 0 /* DTES64, MONITOR */ | 0 /* DS-CPL, VMX, SMX, EST */ | 0 /* TM2 */ | F(SSSE3) | 0 /* CNXT-ID */ | 0 /* Reserved */ | F(FMA) | F(CX16) | 0 /* xTPR Update, PDCM */ | 0 /* Reserved, DCA */ | F(XMM4_1) | F(XMM4_2) | F(X2APIC) | F(MOVBE) | F(POPCNT) | 0 /* Reserved*/ | F(AES) | F(XSAVE) | 0 /* OSXSAVE */ | F(AVX) | F(F16C) | F(RDRAND); Would it make sense to expose F(TSC_DEADLINE) above? Or is there something truly special about tsc deadline that means it should be different from everything else? Because the feature depends on KVM_CREATE_IRQCHIP, which we cannot guarantee will be called, we expose it via a KVM_CAP_TSC_DEADLINE_TIMER and not KVM_GET_SUPPORTED_CPUID. Refer changeset 4d25a066b69fb749a39d0d4c610689dd765a0b0e. BTW, your question remind me qemu-kvm side patch, and I update it a little (would be sent out later). Thanks, Jinsong
Re: [Qemu-devel] [PATCH] spice: fix 32bit build
On Tue, Mar 20, 2012 at 04:45:26PM +0400, Michael Tokarev wrote: 20.03.2012 15:26, Gerd Hoffmann wrote: New 32bit warnings sneaked in, this time in ui/spice-display.c, fix them. This gets annonying, /me sets up a ubuntu buildbot slave for 32bit spice testbuilds. Um, is it worth to watch/fix? Note that spice does not work on 32bits anyway, qemu segfaults at startup... http://bugs.debian.org/640139 (the bug was still valid when 1.0 was released). Hmm, my bad - I only tested with Xspice, that doesn't go through the slots. So at least it means most of it works fine for 32 bit. I'll try to fix this part. Thanks for the link. Thanks, /mjt
Re: [Qemu-devel] [PATCH V2 2/3] exynos4210: add exynos4210 GPIO implementation
On 15 March 2012 07:35, Igor Mitsyanko i.mitsya...@samsung.com wrote:
Now that we have GPIO emulation for exynos4210 SoC we can use it to
properly hook up IRQ line to lan9215 controller on SMDK board.
+#elif EXYNOS4210_GPIO_DEBUG == 1
+#define DPRINT_L1(fmt, args...) \
+ do {fprintf(stderr, QEMU GPIO: fmt, ## args); } while (0)
Space after the closing quote in these macros (this patch and
others), please.
+
+ DPRINT_L1(Input pin GPIO%s_PIN%u %s by external device\n,
+ g-ports[group_num].name, pin, (level ? set : cleared));
+ /* Set new value on corresponding gpio pin */
+ (level) ? (g-ports[group_num].dat |= (1 pin)) :
+ (g-ports[group_num].dat = ~(1 pin));
Don't use ?: like this please, just write it out as an if statement.
+static void exynos4_gpio_write(void *opaque, target_phys_addr_t off,
+ uint64_t value, unsigned size)
+{
I find these read and write functions quite hard to read. I'm
wondering if it would work better to split them up into smaller
memory regions which get registered at the right addresses, rather
than effectively doing the decode into different subsections based
on address and g-part here?
+ Exynos4GpioState *g = (Exynos4GpioState *)opaque;
+ unsigned int port_end, extint_con_start, extint_con_end;
+ unsigned int extint_flt_start, extint_flt_end;
+ unsigned int extint_mask_start, extint_mask_end;
+ unsigned int extint_pend_start, extint_pend_end;
+ unsigned int etcp_start_addr, etcp_start_idx, extint_pri_end;
+ unsigned idx;
+
+ DPRINT_L2(GPIO%u write off 0x%x = %u(0x%x)\n, g-part,
+ (uint32_t)off, (uint32_t)value, (uint32_t)value);
+
+ switch (g-part) {
+ case GPIO_PART2X:
+ port_end = GPIO2_XPORT_END;
+ extint_con_start = GPIO2_WKPINT_CON_START;
+ extint_con_end = GPIO2_WKPINT_CON_END;
+ extint_flt_start = GPIO2_WKPINT_FLT_START;
+ extint_flt_end = GPIO2_WKPINT_FLT_END;
+ extint_mask_start = GPIO2_WKPINT_MASK_START;
+ extint_mask_end = GPIO2_WKPINT_MASK_END;
+ extint_pend_start = GPIO2_WKPINT_PEND_START;
+ extint_pend_end = GPIO2_WKPINT_PEND_END;
+ etcp_start_addr = etcp_start_idx = extint_pri_end = 0;
+ break;
+ case GPIO_PART1: default:
+ port_end = GPIO_NORM_PORT_END;
+ extint_con_start = GPIO_EXTINT_CON_START;
+ extint_con_end = GPIO1_EXTINT_CON_END;
+ extint_flt_start = GPIO_EXTINT_FLT_START;
+ extint_flt_end = GPIO1_EXTINT_FLT_END;
+ extint_mask_start = GPIO_EXTINT_MASK_START;
+ extint_mask_end = GPIO1_EXTINT_MASK_END;
+ extint_pend_start = GPIO_EXTINT_PEND_START;
+ extint_pend_end = GPIO1_EXTINT_PEND_END;
+ etcp_start_addr = GPIO1_ETCPORT_START;
+ etcp_start_idx = GPIO1_NORM_PORT_NUM;
+ extint_pri_end = GPIO1_EXTINT_FIXPRI_END;
+ break;
+ case GPIO_PART2:
+ port_end = GPIO_NORM_PORT_END;
+ extint_con_start = GPIO_EXTINT_CON_START;
+ extint_con_end = GPIO2_EXTINT_CON_END;
+ extint_flt_start = GPIO_EXTINT_FLT_START;
+ extint_flt_end = GPIO2_EXTINT_FLT_END;
+ extint_mask_start = GPIO_EXTINT_MASK_START;
+ extint_mask_end = GPIO2_EXTINT_MASK_END;
+ extint_pend_start = GPIO_EXTINT_PEND_START;
+ extint_pend_end = GPIO2_EXTINT_PEND_END;
+ etcp_start_addr = GPIO2_ETCPORT_START;
+ etcp_start_idx = GPIO2_NORM_PORT_NUM;
+ extint_pri_end = GPIO2_EXTINT_FIXPRI_END;
+ break;
+ case GPIO_PART3:
+ if (off GPIO3_NORM_PORT_END) {
+ idx = DIV_BY_PORTGR_SIZE(off);
+ exynos4_gpio_portgr_write(g, idx, MOD_PORTGR_SIZE(off), value);
+ } else {
+ DPRINT_ERROR(GPIO3 bad write off 0x%x = %u(0x%x)\n,
+ (uint32_t)off, (uint32_t)value, (uint32_t)value);
+ }
+ return;
+ }
+
+ if (off port_end) {
+ idx = DIV_BY_PORTGR_SIZE(off);
+ exynos4_gpio_portgr_write(g, idx, MOD_PORTGR_SIZE(off), value);
+ } else if (off = extint_mask_start off extint_mask_end) {
+ idx = (off - extint_mask_start) 2;
+ DPRINT_L1(GPIO%u EXTINT%u_MASK register write = %u(0x%x)\n,
g-part,
+ g-port_ints[idx].int_line_num, (uint32_t)value,
(uint32_t)value);
+ g-port_ints[idx].mask = value;
+ } else if (off = extint_pend_start off extint_pend_end) {
+ idx = (off - extint_pend_start) 2;
+ DPRINT_L1(GPIO%u EXTINT%u_PEND register write = %u(0x%x)\n,
g-part,
+ g-port_ints[idx].int_line_num, (uint32_t)value,
(uint32_t)value);
+ if (g-part == GPIO_PART2X) {
+ unsigned i, irq_n;
+ Exynos4Gpio2XState *g2 = EXYNOS4210_GPIO2X(g);
+ for (i = 0; i GPIO_MAX_PIN_IN_PORT; i++) {
+ if ((g-port_ints[idx].pend (1 i)) (value (1
i))) {
+
Re: [Qemu-devel] Build broken -- qemu-ga: add guest-network-get-interfaces command
On 20/03/12 6:14 AM, Michal Privoznik wrote: On 18.03.2012 02:09, Brad Smith wrote: Michal, http://git.qemu.org/?p=qemu.git;a=commit;h=3424fc9f16a1e7d1c48eb6d605eb0ca63e199ec2 This broke the build. Un-break the tree. Can you please be more specific? It works for me so I don't have a clue what are you referring to. I mean, what compiler do you use, what errors are thrown, etc. Michal The patch commited is full of Linux specific code. CCqga/commands-posix.o In file included from qga/commands-posix.c:29: /usr/include/arpa/inet.h:74: warning: 'struct in_addr' declared inside parameter list /usr/include/arpa/inet.h:74: warning: its scope is only this definition or declaration, which is probably not what you want /usr/include/arpa/inet.h:75: warning: 'struct in_addr' declared inside parameter list qga/commands-posix.c: In function 'bios_supports_mode': qga/commands-posix.c:587: error: 'environ' undeclared (first use in this function) qga/commands-posix.c:587: error: (Each undeclared identifier is reported only once qga/commands-posix.c:587: error: for each function it appears in.) qga/commands-posix.c: In function 'guest_suspend': qga/commands-posix.c:670: error: 'environ' undeclared (first use in this function) qga/commands-posix.c: In function 'qmp_guest_network_get_interfaces': qga/commands-posix.c:764: error: 'INET_ADDRSTRLEN' undeclared (first use in this function) qga/commands-posix.c:765: error: 'INET6_ADDRSTRLEN' undeclared (first use in this function) qga/commands-posix.c:789: error: 'SIOCGIFHWADDR' undeclared (first use in this function) qga/commands-posix.c:810: error: 'struct ifreq' has no member named 'ifr_hwaddr' qga/commands-posix.c:832: error: dereferencing pointer to incomplete type qga/commands-posix.c:846: error: dereferencing pointer to incomplete type qga/commands-posix.c:854: error: dereferencing pointer to incomplete type qga/commands-posix.c:868: error: dereferencing pointer to incomplete type qga/commands-posix.c:765: warning: unused variable 'addr6' qga/commands-posix.c:764: warning: unused variable 'addr4' gmake: *** [qga/commands-posix.o] Error 1 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [Qemu-devel] [PATCH 2/2] Expose tsc deadline timer cpuid to guest
On Tue, Mar 20, 2012 at 12:53:57PM +, Liu, Jinsong wrote:
Rik van Riel wrote:
On 03/09/2012 01:27 PM, Liu, Jinsong wrote:
As for 'tsc deadline' feature exposing, my patch (as attached) just
obey qemu general cpuid exposing method, and also satisfied your
target I think.
One question.
Why is TSC_DEADLINE not exposed in the cpuid allowed feature
bits in do_cpuid_ent() in arch/x86/kvm/x86.c ?
/* cpuid 1.ecx */
const u32 kvm_supported_word4_x86_features =
F(XMM3) | F(PCLMULQDQ) | 0 /* DTES64, MONITOR */ |
0 /* DS-CPL, VMX, SMX, EST */ |
0 /* TM2 */ | F(SSSE3) | 0 /* CNXT-ID */ | 0 /*
Reserved */ |
F(FMA) | F(CX16) | 0 /* xTPR Update, PDCM */ |
0 /* Reserved, DCA */ | F(XMM4_1) |
F(XMM4_2) | F(X2APIC) | F(MOVBE) | F(POPCNT) |
0 /* Reserved*/ | F(AES) | F(XSAVE) | 0 /* OSXSAVE
*/ | F(AVX) |
F(F16C) | F(RDRAND);
Would it make sense to expose F(TSC_DEADLINE) above?
Or is there something truly special about tsc deadline
that means it should be different from everything else?
Because the feature depends on KVM_CREATE_IRQCHIP, which we cannot guarantee
will be called, we expose it via a KVM_CAP_TSC_DEADLINE_TIMER and not
KVM_GET_SUPPORTED_CPUID.
We have many other features that depend on proper support from userspace
otherwise they wouldn't work, but are listed on GET_SUPPORTED_CPUID,
don't we? Why is TSC-deadline special?
GET_SUPPORTED_CPUID just means KVM supports it as long as userspace
supports it too and enables it, it doesn't mean CPUID bit that will be
enabled by default[1].
Refer changeset 4d25a066b69fb749a39d0d4c610689dd765a0b0e.
That changeset was necessary because the kernel was doing this on
update_cpu
if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL
best-function == 0x1) {
best-ecx |= bit(X86_FEATURE_TSC_DEADLINE_TIMER);
And that was really wrong, because it enabled the bit unconditionally.
But I don't understand why KVM_CAP_TSC_DEADLINE_TIMER was created if we
already have KVM_GET_SUPPORTED_CPUID to tell userspace which bits are
supported by KVM.
[1] From Documentation/virtual/kvm/api.txt:
KVM_GET_SUPPORTED_CPUID
[...]
This ioctl returns x86 cpuid features which are supported by both the
hardware and kvm. Userspace can use the information returned by this
ioctl to construct cpuid information (for KVM_SET_CPUID2) that is
consistent with hardware, kernel, and userspace capabilities, and with
^^
user requirements (for example, the user may wish to constrain cpuid to
emulate older hardware, or for feature consistency across a cluster).
--
Eduardo
[Qemu-devel] [PATCH] tracetool dtrace disabled-events fix
If there are disabled entries in the trace-events file then
linetod_nop() is called if the backend is dtrace, it's currently
not present.
Signed-off-by: Lee Essen lee.es...@nowonline.co.uk
--
diff --git a/scripts/tracetool b/scripts/tracetool
index 65bd0a1..d5e5591 100755
--- a/scripts/tracetool
+++ b/scripts/tracetool
@@ -161,6 +161,12 @@ linetoc_nop()
return
}
+linetod_nop()
+{
+# Used when disabled events are processed
+return
+}
+
linetoc_end_nop()
{
return
Re: [Qemu-devel] [PATCH] spice: fix 32bit build
On 20 March 2012 12:45, Michael Tokarev m...@tls.msk.ru wrote: Um, is it worth to watch/fix? Note that spice does not work on 32bits anyway, qemu segfaults at startup... I've had conflicting answers about this -- the Spice FAQ says it doesn't work on 32 bits but in this message: http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg00944.html Gerd said it should work on 32 bit systems now. (If it is now OK on 32 bits it would be nice to get the FAQ fixed...) -- PMM
Re: [Qemu-devel] KVM call agenda for Tuesday 20th
Juan Quintela quint...@redhat.com wrote: Hi Please send in any agenda items you are interested in covering. As there are no topics, call is cancelled. Happy hacking, Juan.
Re: [Qemu-devel] [PATCH 23/36] arm: save always 32 fpu registers
On 20 March 2012 12:27, Juan Quintela quint...@redhat.com wrote: Peter Maydell peter.mayd...@linaro.org wrote: This commit message is out of date -- the overwriting bug was fixed in commit 15180256 last year. Possibly the patch should be dropped from your series? (If not, ARM_FEATURE_VFP3.) Reason for the change is not to have to write partial arrays. Normally, the less different options that we have on the migration format, the easy to make sense of it. It was not related to the bug that we used to have in this area. OK, so you just need to fix the commit message. thanks -- PMM
Re: [Qemu-devel] [PATCH v2 0/2] qapi: fix double free in QMP OV cleanup, add test case
On Tue, 20 Mar 2012 11:22:47 +0100 Laszlo Ersek ler...@redhat.com wrote: v1-v2: added Paolo's test case as second patch in the series. Also tried to come up with a better subject for 1/2. Applied to the qmp branch, thanks. Laszlo Ersek (1): qapi: fix double free in qmp_output_visitor_cleanup() Paolo Bonzini (1): qapi: add struct-errors test case to test-qmp-output-visitor qapi-schema-test.json |2 +- qapi/qmp-output-visitor.c |8 +--- test-qmp-output-visitor.c | 20 3 files changed, 26 insertions(+), 4 deletions(-)
[Qemu-devel] [PATCH v3] qapi: add c_fun to escape function names
Signed-off-by: Federico Simoncelli fsimo...@redhat.com
---
scripts/qapi-commands.py | 14 +++---
scripts/qapi-types.py|4 ++--
scripts/qapi-visit.py|4 ++--
scripts/qapi.py |5 -
4 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/scripts/qapi-commands.py b/scripts/qapi-commands.py
index 3aabf61..30a24d2 100644
--- a/scripts/qapi-commands.py
+++ b/scripts/qapi-commands.py
@@ -42,7 +42,7 @@ def generate_command_decl(name, args, ret_type):
return mcgen('''
%(ret_type)s qmp_%(name)s(%(args)sError **errp);
''',
- ret_type=c_type(ret_type), name=c_var(name),
args=arglist).strip()
+ ret_type=c_type(ret_type), name=c_fun(name),
args=arglist).strip()
def gen_sync_call(name, args, ret_type, indent=0):
ret =
@@ -59,7 +59,7 @@ def gen_sync_call(name, args, ret_type, indent=0):
%(retval)sqmp_%(name)s(%(args)serrp);
''',
-name=c_var(name), args=arglist, retval=retval).rstrip()
+name=c_fun(name), args=arglist, retval=retval).rstrip()
if ret_type:
ret += \n + mcgen(
if (!error_is_set(errp)) {
@@ -74,7 +74,7 @@ if (!error_is_set(errp)) {
def gen_marshal_output_call(name, ret_type):
if not ret_type:
return
-return qmp_marshal_output_%s(retval, ret, errp); % c_var(name)
+return qmp_marshal_output_%s(retval, ret, errp); % c_fun(name)
def gen_visitor_output_containers_decl(ret_type):
ret =
@@ -198,16 +198,16 @@ static void qmp_marshal_output_%(c_name)s(%(c_ret_type)s
ret_in, QObject **ret_o
qapi_dealloc_visitor_cleanup(md);
}
''',
-c_ret_type=c_type(ret_type), c_name=c_var(name),
+c_ret_type=c_type(ret_type), c_name=c_fun(name),
visitor=type_visitor(ret_type))
return ret
def gen_marshal_input_decl(name, args, ret_type, middle_mode):
if middle_mode:
-return 'int qmp_marshal_input_%s(Monitor *mon, const QDict *qdict,
QObject **ret)' % c_var(name)
+return 'int qmp_marshal_input_%s(Monitor *mon, const QDict *qdict,
QObject **ret)' % c_fun(name)
else:
-return 'static void qmp_marshal_input_%s(QDict *args, QObject **ret,
Error **errp)' % c_var(name)
+return 'static void qmp_marshal_input_%s(QDict *args, QObject **ret,
Error **errp)' % c_fun(name)
@@ -298,7 +298,7 @@ def gen_registry(commands):
registry += mcgen('''
qmp_register_command(%(name)s, qmp_marshal_input_%(c_name)s);
''',
- name=cmd['command'], c_name=c_var(cmd['command']))
+ name=cmd['command'], c_name=c_fun(cmd['command']))
pop_indent()
ret = mcgen('''
static void qmp_init_marshal(void)
diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
index 727fb77..4a734f5 100644
--- a/scripts/qapi-types.py
+++ b/scripts/qapi-types.py
@@ -100,7 +100,7 @@ typedef enum %(name)s
%(abbrev)s_%(value)s = %(i)d,
''',
abbrev=de_camel_case(name).upper(),
- value=c_var(value).upper(),
+ value=c_fun(value).upper(),
i=i)
i += 1
@@ -126,7 +126,7 @@ struct %(name)s
%(c_type)s %(c_name)s;
''',
c_type=c_type(typeinfo[key]),
- c_name=c_var(key))
+ c_name=c_fun(key))
ret += mcgen('''
};
diff --git a/scripts/qapi-visit.py b/scripts/qapi-visit.py
index 54117d4..78c947c 100644
--- a/scripts/qapi-visit.py
+++ b/scripts/qapi-visit.py
@@ -129,9 +129,9 @@ void visit_type_%(name)s(Visitor *m, %(name)s ** obj, const
char *name, Error **
break;
''',
abbrev = de_camel_case(name).upper(),
-enum = de_camel_case(key).upper(),
+enum = c_fun(de_camel_case(key)).upper(),
c_type=members[key],
-c_name=c_var(key))
+c_name=c_fun(key))
ret += mcgen('''
default:
diff --git a/scripts/qapi.py b/scripts/qapi.py
index 6e05469..e062336 100644
--- a/scripts/qapi.py
+++ b/scripts/qapi.py
@@ -131,7 +131,10 @@ def camel_case(name):
return new_name
def c_var(name):
-return '_'.join(name.split('-')).lstrip(*)
+return name.replace('-', '_').lstrip(*)
+
+def c_fun(name):
+return c_var(name).replace('.', '_')
def c_list_type(name):
return '%sList' % name
--
1.7.1
Re: [Qemu-devel] [PATCH] use bdrv_aio functions in fdc.c
On Mon, Mar 19, 2012 at 05:17:15PM +0800, Li Zhi Hui wrote:
@@ -1196,107 +1322,108 @@ static int fdctrl_transfer_handler (void *opaque,
int nchan,
return 0;
}
cur_drv = get_cur_drv(fdctrl);
-if (fdctrl-data_dir == FD_DIR_SCANE || fdctrl-data_dir == FD_DIR_SCANL
||
-fdctrl-data_dir == FD_DIR_SCANH)
+if ((fdctrl-data_dir == FD_DIR_SCANE) ||
+(fdctrl-data_dir == FD_DIR_SCANL) ||
+(fdctrl-data_dir == FD_DIR_SCANH)) {
status2 = FD_SR2_SNS;
-if (dma_len fdctrl-data_len)
+}
+if (dma_len fdctrl-data_len) {
dma_len = fdctrl-data_len;
+}
if (cur_drv-bs == NULL) {
-if (fdctrl-data_dir == FD_DIR_WRITE)
-fdctrl_stop_transfer(fdctrl, FD_SR0_ABNTERM | FD_SR0_SEEK, 0x00,
0x00);
-else
+if (fdctrl-data_dir == FD_DIR_WRITE) {
+fdctrl_stop_transfer(fdctrl,
+FD_SR0_ABNTERM | FD_SR0_SEEK, 0x00, 0x00);
+} else {
fdctrl_stop_transfer(fdctrl, FD_SR0_ABNTERM, 0x00, 0x00);
+}
len = 0;
goto transfer_error;
}
+
+if ((fdctrl-data_dir != FD_DIR_WRITE) (fdctrl-data_pos dma_len)) {
+fdc_sector_num = (dma_len + FD_SECTOR_LEN - 1) / FD_SECTOR_LEN;
+opaque_cb = g_malloc0(sizeof(FDC_opaque));
I think we can only have 1 I/O pending at a time. Therefore it's
probably not necessary to create a separate struct, we can just pass the
FDrive/FDCtrl.
+qiov = g_malloc0(sizeof(QEMUIOVector));
This is leaked. I think it can be a field in opaque_cb, there's no need
to allocate this separately on the heap.
+pfdc_string = g_malloc0(fdc_sector_num * FD_SECTOR_LEN);
Looks like this buffer is leaked. A block I/O buffer should be
allocated with qemu_blockalign() instead of g_malloc0() so that memory
alignment requirements for O_DIRECT image files are met.
Would it be possible to use the fifo[] buffer instead of allocating a
new buffer?
+
+qemu_iovec_init(qiov, 1);
+qiov-iov-iov_base = pfdc_string;
+qiov-iov-iov_len = fdc_sector_num * FD_SECTOR_LEN;
+qiov-niov = 1;
+qiov-size = fdc_sector_num * FD_SECTOR_LEN;
The easiest way to do this is:
iov.iov_base = fifo;
iov.iov_len = fdc_sector_num * FD_SECTOR_LEN;
qemu_iovec_init_external(qiov, iov, 1);
We shouldn't duplicate the qiov-size calculation - that's already
provided by qemu_iovec_init_external() or qemu_iovec_add().
+opaque_cb-fdctrl = fdctrl;
+opaque_cb-qiov = qiov;
+opaque_cb-nchan = nchan;
+opaque_cb-dma_len = dma_len;
+bdrv_aio_readv(cur_drv-bs, fd_sector(cur_drv),
+qiov, fdc_sector_num, fdctrl_read_DMA_cb, opaque_cb);
+return dma_len;
We are returning dma_len but the I/O has not yet happened. The guest
could see that the DMA controller register has updated before we've
actually transferred data. This seems risky.
Have you checked what hw/dma.c does after we return? The DMA operation
has not completed yet so I wonder if it will call
fdctrl_transfer_handler() again from DMA_run()?
Stefan
Re: [Qemu-devel] [PATCH 10/12] trace: [tracetool] Automatically establish available backends and formats
Stefan Hajnoczi writes: 2012/3/13 Lluís Vilanova vilan...@ac.upc.edu: Adds decorators to establish which backend and/or format each routine is meant to process. With this, tables enumerating format and backend routines can be eliminated and part of the usage message can be computed in a more generic way. Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu Signed-off-by: Harsh Prateek Bora ha...@linux.vnet.ibm.com --- Makefile.objs | 6 - Makefile.target | 3 scripts/tracetool.py | 320 -- 3 files changed, 211 insertions(+), 118 deletions(-) I find the decorators are overkill and we miss the chance to use more straightforward approaches that Python supports. The decorators build structures behind the scenes instead of using classes in an open coded way. I think this makes it more difficult for people to modify the code - they will need to dig in to what exactly the decorators do - what they do is pretty similar to what you get from a class. I've tried out an alternative approach which works very nicely for formats. For backends it's not a perfect fit because it creates instances when we don't really need them, but I think it's still an overall cleaner approach: https://github.com/stefanha/qemu/commit/3500eb43f80f3c9200107aa0ca19a1b57300ef8a What do you think? I don't like it: 1) Format and backend tables must be manually filled. 2) The base Backend class has empty methods for each possible format. 3) There is no control on format/backend compatibility. But I do like the idea of having a single per-backend class having methods for each possible format. The main reason for automatically establishing formats, backends and their compatibility is that the instrumentation patches add some extra formats and backends, which makes the process much more tedious if it's not automated. Whether you use decorators or classes is not that important. Auto-registration can be accomplished using metaclasses and special per-format/backend special attributes the metaclasses will look for (e.g. NAME to set the commandline-visible name of a format/backend.). Format/backend compatibility can be established by introspecting into the methods on each backend child class, matched against the NAMEs of the registered formats. But going this way does not sound to me like it will be much clearer than decorators. Do you agree? (I'll wait on solving this before fixing the rest of your concerns in this series). Do you still prefer classes over decorators? Lluis -- And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer. -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
Re: [Qemu-devel] [PATCH v4 1/7] RTC: Remove the logic to update time format when DM bit changed
On Mon, 19 Mar 2012, Zhang, Yang Z wrote:
Change DM(date mode) and 24/12 control bit don't affect the internal
registers. It only indicates what format is using for those registers. So we
don't need to update time format when it is modified.
That might be true, but if the user changes format, then issues a read
RTC_SECONDS, isn't he going to get the old format, unless we call
rtc_copy_date here?
Signed-off-by: Yang Zhang yang.z.zh...@intel.com
---
hw/mc146818rtc.c | 10 +-
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index a46fdfc..9b49cbc 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -252,15 +252,7 @@ static void cmos_ioport_write(void *opaque, uint32_t
addr, uint32_t data)
rtc_set_time(s);
}
}
-if (((s-cmos_data[RTC_REG_B] ^ data) (REG_B_DM | REG_B_24H))
-!(data REG_B_SET)) {
-/* If the time format has changed and not in set mode,
- update the registers immediately. */
-s-cmos_data[RTC_REG_B] = data;
-rtc_copy_date(s);
-} else {
-s-cmos_data[RTC_REG_B] = data;
-}
+s-cmos_data[RTC_REG_B] = data;
rtc_timer_update(s, qemu_get_clock_ns(rtc_clock));
break;
case RTC_REG_C:
--
1.7.1
Re: [Qemu-devel] ARM QOM conversion / class hierarchy
Option two looks kind of nice, but I'm not sure whether it would actually work. I think you could do 95% of what you need for a different CPU that way (lots of properties for value of ID_MMFR1, value of ID_MMFR2, reset value of SCTLR, etc etc, plus properties for all our existing ARM_FEATURE_*, and some new ones where we're currently keying off which CPU is this? rather than using a feature bit, or just failing to distinguish things which aren't really common to all CPUs). But I'm not sure how you'd handle the genuinely implementation specific cp15 registers (eg cp15 crn=15). We could have a property which says is this a 926/1026/1176/A8/A9/... (or equivalently, key off the relevant fields of the main ID register) but it doesn't seem very OO-like to have one class whose behaviour changes based on an integer that's basically defining an ad-hoc sub-type... IIUC the proper OO solution to this requires multiple inheritance, which we don't have. The problem with subtyping is we can use it for at most one characteristic. Everything else ends up being pushed into a common base class and controlled by feature bits (or equivalent). If we're going to use the class hierachy to implement functionality then there are other candidates. Given the primary purpose of QOM is [IMO] to handle interaction between devices, the external interface exposed by the core seems like a better candidate for subclassing. i.e. conventional ARM cores with IRQ and FIQ inputs[1] v.s. M profile devices where the core exception model is intimately tied to the interrupt controller. Paul [1] This still applies to things like the Cortex-A9. In practice ARM may sell you an SMP cluster, but logically it's still a couple of normal cores and an interrupt controller.
Re: [Qemu-devel] [PATCH 09/36] vmstate: introduce float32 arrays
On 19 March 2012 22:57, Juan Quintela quint...@redhat.com wrote:
+/* 32 bit float */
+
+typedef union {
+ float32 f;
+ uint32_t i;
+} VMStateFloat32;
+
+static int get_float32(QEMUFile *f, void *pv, size_t size)
+{
+ float32 *v = pv;
+ VMStateFloat32 u;
+ qemu_get_be32s(f, u.i);
+ *v = u.f;
+ return 0;
+}
+
+static void put_float32(QEMUFile *f, void *pv, size_t size)
+{
+ float32 *v = pv;
+ VMStateFloat32 u;
+ u.f = *v;
+ qemu_put_be32s(f, u.i);
+}
This conversion (float32-uint32_t) should be done via
float32_val() and make_float32().
-- PMM
Re: [Qemu-devel] [PATCH v4 2/7] RTC: Update the RTC clock only when reading it
On Mon, 19 Mar 2012, Zhang, Yang Z wrote:
There has no need to use two periodic timer to update RTC time. In this
patch, we only update it when guest reading it.
So the basic idea here is that we don't need to two periodic timers
because we are going to calculate the RTC guest time from QEMU's
host_clock.
I only have a couple of observations:
- shouldn't we use QEMU rtc_clock, rather than host_clock?
- it would be better to use shifts rather than divisions whenever
possible, they are much cheaper;
- rtc_calibrate_time seems to be the new functions that updates the
guest rtc time based on QEMU host_clock. Are you sure we are calling
it all the times we need to call it? Could we just call it at the
beginning of cmos_ioport_write and cmos_ioport_read?
Signed-off-by: Yang Zhang yang.z.zh...@intel.com
---
hw/mc146818rtc.c | 207
+-
1 files changed, 66 insertions(+), 141 deletions(-)
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 9b49cbc..82a5b8a 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -44,6 +44,9 @@
# define DPRINTF_C(format, ...) do { } while (0)
#endif
+#define USEC_PER_SEC100L
+#define NS_PER_USEC 1000L
+
#define RTC_REINJECT_ON_ACK_COUNT 20
#define RTC_SECONDS 0
@@ -85,6 +88,8 @@ typedef struct RTCState {
uint8_t cmos_data[128];
uint8_t cmos_index;
struct tm current_tm;
+int64_t offset_sec;
+int32_t offset_usec;
int32_t base_year;
qemu_irq irq;
qemu_irq sqw_irq;
@@ -92,21 +97,29 @@ typedef struct RTCState {
/* periodic timer */
QEMUTimer *periodic_timer;
int64_t next_periodic_time;
-/* second update */
-int64_t next_second_time;
uint16_t irq_reinject_on_ack_count;
uint32_t irq_coalesced;
uint32_t period;
QEMUTimer *coalesced_timer;
-QEMUTimer *second_timer;
-QEMUTimer *second_timer2;
Notifier clock_reset_notifier;
LostTickPolicy lost_tick_policy;
Notifier suspend_notifier;
} RTCState;
static void rtc_set_time(RTCState *s);
-static void rtc_copy_date(RTCState *s);
+static void rtc_calibrate_time(RTCState *s);
+static void rtc_set_cmos(RTCState *s);
+
+static uint64_t get_guest_rtc_us(RTCState *s)
+{
+int64_t host_usec, offset_usec, guest_usec;
+
+host_usec = qemu_get_clock_ns(host_clock) / NS_PER_USEC;
+offset_usec = s-offset_sec * USEC_PER_SEC + s-offset_usec;
+guest_usec = host_usec + offset_usec;
+
+return guest_usec;
+}
#ifdef TARGET_I386
static void rtc_coalesced_timer_update(RTCState *s)
@@ -207,6 +220,20 @@ static void rtc_periodic_timer(void *opaque)
}
}
+static void rtc_set_offset(RTCState *s)
+{
+struct tm *tm = s-current_tm;
+int64_t host_usec, guest_sec, guest_usec;
+
+host_usec = qemu_get_clock_ns(host_clock) / NS_PER_USEC;
+
+guest_sec = mktimegm(tm);
+guest_usec = guest_sec * USEC_PER_SEC;
+
+s-offset_sec = (guest_usec - host_usec) / USEC_PER_SEC;
+s-offset_usec = (guest_usec - host_usec) % USEC_PER_SEC;
+}
+
static void cmos_ioport_write(void *opaque, uint32_t addr, uint32_t data)
{
RTCState *s = opaque;
@@ -233,6 +260,7 @@ static void cmos_ioport_write(void *opaque, uint32_t
addr, u
int32_t data)
/* if in set mode, do not update the time */
if (!(s-cmos_data[RTC_REG_B] REG_B_SET)) {
rtc_set_time(s);
+rtc_set_offset(s);
}
break;
case RTC_REG_A:
@@ -243,6 +271,11 @@ static void cmos_ioport_write(void *opaque, uint32_t
addr,
uint32_t data)
break;
case RTC_REG_B:
if (data REG_B_SET) {
+/* update cmos to when the rtc was stopping */
+if (!(s-cmos_data[RTC_REG_B] REG_B_SET)) {
+rtc_calibrate_time(s);
+rtc_set_cmos(s);
+}
/* set mode: reset UIP mode */
s-cmos_data[RTC_REG_A] = ~REG_A_UIP;
data = ~REG_B_UIE;
@@ -250,6 +283,7 @@ static void cmos_ioport_write(void *opaque, uint32_t
addr, u
int32_t data)
/* if disabling set mode, update the time */
if (s-cmos_data[RTC_REG_B] REG_B_SET) {
rtc_set_time(s);
+rtc_set_offset(s);
}
}
s-cmos_data[RTC_REG_B] = data;
@@ -305,7 +339,7 @@ static void rtc_set_time(RTCState *s)
rtc_change_mon_event(tm);
}
-static void rtc_copy_date(RTCState *s)
+static void rtc_set_cmos(RTCState *s)
{
const
Re: [Qemu-devel] [PATCH v4 3/7] RTC: Add UIP(update in progress) check logic
On Mon, 19 Mar 2012, Zhang, Yang Z wrote:
The UIP(update in progress) is set when RTC is updating. And the update cycle
begins 244us later after UIP is set. And it is cleared when update end.
this patch seems good to me
Signed-off-by: Yang Zhang yang.z.zh...@intel.com
---
hw/mc146818rtc.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 82a5b8a..6ebb8f6 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -377,6 +377,21 @@ static void rtc_calibrate_time(RTCState *s)
s-current_tm = *ret;
}
+static int update_in_progress(RTCState *s)
+{
+int64_t guest_usec;
+
+if (s-cmos_data[RTC_REG_B] REG_B_SET) {
+return 0;
+}
+guest_usec = get_guest_rtc_us(s);
+/* UIP bit will be set at last 244us of every second. */
+if ((guest_usec % USEC_PER_SEC) = (USEC_PER_SEC - 244)) {
+return 1;
+}
+return 0;
+}
+
static uint32_t cmos_ioport_read(void *opaque, uint32_t addr)
{
RTCState *s = opaque;
@@ -402,6 +417,9 @@ static uint32_t cmos_ioport_read(void *opaque, uint32_t
addr)
break;
case RTC_REG_A:
ret = s-cmos_data[s-cmos_index];
+if (update_in_progress(s)) {
+ret |= REG_A_UIP;
+}
break;
case RTC_REG_C:
ret = s-cmos_data[s-cmos_index];
--
1.7.1
[Qemu-devel] [Bug 957622] Re: kvm -kernel with grub multiboot kernel dumps core or exits
** Description changed: I attempted to use kvm -kernel with a grub multiboot image, specifically grub-maverick-20100729.img at [1]. That file was built using [2] $ url=http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/download/head:/grubmaverick20100729-20100729071944-bevge631maio9jpl-2/grub-maverick-20100729.img; $ wget $url -O grub-maverick-20100729.img - $ qemu-kvm create -f qcow2 disk.img 1G + $ qemu-img create -f qcow2 disk.img 1G $ kvm -curses -kernel grub-maverick-20100729.img -drive file=disk.img,if=virtio This process works fine on oneiric and you will see a curses interface, and some output of grub looking for a image to boot. On my laptop (with kvm support), I saw: $ kvm -curses -kernel grub-maverick-20100729.img -drive file=disk.img,if=virtio; fread() failed $ echo $? 1 On a kvm guest (via openstack instance), it crashed differently: $ kvm -curses -kernel grub-maverick-20100729.img -drive file=disk.img,if=virtio Could not access KVM kernel module: No such file or directory failed to initialize KVM: No such file or directory Back to tcg accelerator. GLib-ERROR **: /build/buildd/glib2.0-2.31.20/./glib/gmem.c:165: failed to allocate 4293918720 bytes Trace/breakpoint trap (core dumped) - - Just for a test, I tried loading kvm-amd, got nested kvm virtualization, but the instance fails the same way. - + Just for a test, I tried loading kvm-amd, got nested kvm virtualization, + but the instance fails the same way. -- [1] http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/files/head:/loaders/ [2] http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/view/head:/mk-image-mb-loader ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: kvm (not installed) ProcVersionSignature: User Name 3.2.0-18.29-virtual 3.2.9 Uname: Linux 3.2.0-18-virtual x86_64 ApportVersion: 1.94.1-0ubuntu2 Architecture: amd64 CurrentDmesg: - [27230.320857] init: qemu-kvm pre-start process (8659) terminated with status 1 - [27230.361904] init: qemu-kvm post-stop process (8664) terminated with status 1 - [27249.426836] kvm[9021] trap int3 ip:7f44c2bbc13b sp:7fff447e1120 error:0 - [27263.380598] kvm[9283] trap int3 ip:7f3fba9f713b sp:7fff8b55d1a0 error:0 + [27230.320857] init: qemu-kvm pre-start process (8659) terminated with status 1 + [27230.361904] init: qemu-kvm post-stop process (8664) terminated with status 1 + [27249.426836] kvm[9021] trap int3 ip:7f44c2bbc13b sp:7fff447e1120 error:0 + [27263.380598] kvm[9283] trap int3 ip:7f3fba9f713b sp:7fff8b55d1a0 error:0 Date: Sat Mar 17 01:48:13 2012 Ec2AMI: ami- Ec2AMIManifest: FIXME Ec2AvailabilityZone: nova Ec2InstanceType: m1.small Ec2Kernel: unavailable Ec2Ramdisk: unavailable KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD Lsusb: - Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub - Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd + Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub + Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd MachineType: Bochs Bochs ProcEnviron: - TERM=screen - PATH=(custom, user) - LANG=en_US.UTF-8 - SHELL=/bin/bash + TERM=screen + PATH=(custom, user) + LANG=en_US.UTF-8 + SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-18-virtual root=LABEL=cloudimg-rootfs ro console=ttyS0 ProcModules: - acpiphp 24231 0 - Live 0x - floppy 70365 0 - Live 0x - psmouse 87603 0 - Live 0x - serio_raw 13211 0 - Live 0x - virtio_balloon 13108 0 - Live 0x + acpiphp 24231 0 - Live 0x + floppy 70365 0 - Live 0x + psmouse 87603 0 - Live 0x + serio_raw 13211 0 - Live 0x + virtio_balloon 13108 0 - Live 0x SourcePackage: qemu-kvm UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/01/2007 dmi.bios.vendor: Bochs dmi.bios.version: Bochs dmi.chassis.type: 1 dmi.chassis.vendor: Bochs dmi.modalias: dmi:bvnBochs:bvrBochs:bd01/01/2007:svnBochs:pnBochs:pvr:cvnBochs:ct1:cvr: dmi.product.name: Bochs dmi.sys.vendor: Bochs -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/957622 Title: kvm -kernel with grub multiboot kernel dumps core or exits Status in QEMU: Confirmed Status in “qemu-kvm” package in Ubuntu: In Progress Bug description: I attempted to use kvm -kernel with a grub multiboot image, specifically grub-maverick-20100729.img at [1]. That file was built using [2] $
Re: [Qemu-devel] [PATCH RFC] virtio-pci: add MMIO property
On 03/19/2012 08:57 PM, Michael S. Tsirkin wrote: Should be done via an extra BAR (with the same layout, perhaps extended) so compatibility is preserved. No, that would need guest changes to be of use. The point of this hack is to make things work for Linux guests where PIO does not work. It only works if all guest's PCI layer knows to deal with the bit flip correctly. I imagine it isn't true for at least the seabios virtio drivers. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] ARM QOM conversion / class hierarchy
On 20 March 2012 14:08, Paul Brook p...@codesourcery.com wrote: Option two looks kind of nice, but I'm not sure whether it would actually work. I think you could do 95% of what you need for a different CPU that way (lots of properties for value of ID_MMFR1, value of ID_MMFR2, reset value of SCTLR, etc etc, plus properties for all our existing ARM_FEATURE_*, and some new ones where we're currently keying off which CPU is this? rather than using a feature bit, or just failing to distinguish things which aren't really common to all CPUs). But I'm not sure how you'd handle the genuinely implementation specific cp15 registers (eg cp15 crn=15). We could have a property which says is this a 926/1026/1176/A8/A9/... (or equivalently, key off the relevant fields of the main ID register) but it doesn't seem very OO-like to have one class whose behaviour changes based on an integer that's basically defining an ad-hoc sub-type... IIUC the proper OO solution to this requires multiple inheritance, which we don't have. The problem with subtyping is we can use it for at most one characteristic. Everything else ends up being pushed into a common base class and controlled by feature bits (or equivalent). If we're going to use the class hierachy to implement functionality then there are other candidates. Given the primary purpose of QOM is [IMO] to handle interaction between devices, the external interface exposed by the core seems like a better candidate for subclassing. i.e. conventional ARM cores with IRQ and FIQ inputs[1] v.s. M profile devices where the core exception model is intimately tied to the interrupt controller. Yes, I think I'd agree there. So should we just have an init function that provides the implementation-specific cp15 registers based on the value provided in the QOM property for the main ID register? [1] This still applies to things like the Cortex-A9. In practice ARM may sell you an SMP cluster, but logically it's still a couple of normal cores and an interrupt controller. Yes, this should be implemented by object composition (ie QOM child objects inside a container). The lines blur rather with the A15, though, where for instance the generic timer hangs off cp15 but injects interrupts into the GIC, not directly into the core. (And even for the A9 the coupling is pretty close, for instance the BE8 byte-swapping, which you might think is a property of the core, doesn't apply to accesses to the private peripherals (timers, gic, etc).) -- PMM
Re: [Qemu-devel] [PATCH] fix multiboot loading if load_end_addr == 0 (fwd)
Quoting Scott Moser (smo...@ubuntu.com):
Re-sending to qemu-devel. I'd originally sent this to kvm mailing list.
-- Forwarded message --
Date: Sat, 17 Mar 2012 00:08:06
From: Scott Moser smo...@ubuntu.com
To: k...@vger.kernel.org
Subject: [PATCH] fix multiboot loading if load_end_addr == 0
The previous code did not treat the case where load_end_addr was 0
specially. The multiboot specification says the following:
* load_end_addr
Contains the physical address of the end of the data segment.
(load_end_addr - load_addr) specifies how much data to load. This
implies that the text and data segments must be consecutive in the
OS image; this is true for existing a.out executable formats. If
this field is zero, the boot loader assumes that the text and data
segments occupy the whole OS image file.
This was raised initially as launchpad bug
https://bugs.launchpad.net/qemu/+bug/957622
Tested-by: Serge Hallyn serge.hal...@canonical.com
diff --git a/hw/multiboot.c b/hw/multiboot.c
index b4484a3..b1e04c5 100644
--- a/hw/multiboot.c
+++ b/hw/multiboot.c
@@ -202,10 +202,16 @@ int load_multiboot(void *fw_cfg,
uint32_t mh_bss_end_addr = ldl_p(header+i+24);
mh_load_addr = ldl_p(header+i+16);
uint32_t mb_kernel_text_offset = i - (mh_header_addr - mh_load_addr);
-uint32_t mb_load_size = mh_load_end_addr - mh_load_addr;
-
+uint32_t mb_load_size = 0;
mh_entry_addr = ldl_p(header+i+28);
-mb_kernel_size = mh_bss_end_addr - mh_load_addr;
+
+if (mh_load_end_addr) {
+mb_kernel_size = mh_bss_end_addr - mh_load_addr;
+mb_load_size = mh_load_end_addr - mh_load_addr;
+} else {
+mb_kernel_size = kernel_file_size - mb_kernel_text_offset;
+mb_load_size = mb_kernel_size;
+}
/* Valid if mh_flags sets MULTIBOOT_HEADER_HAS_VBE.
uint32_t mh_mode_type = ldl_p(header+i+32);
[Qemu-devel] [PATCH] qemu-ga: Make guest-network-get-interfaces Linux only
Currently, the implementation of that command is full of
Linux specific code. Before any brave man will step into
and port it to other OSes, make this function Linux only.
Signed-off-by: Michal Privoznik mpriv...@redhat.com
---
qga/commands-posix.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 7b2be2f..89dde92 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -729,6 +729,7 @@ void qmp_guest_suspend_hybrid(Error **err)
guest_suspend(pm-suspend-hybrid, NULL, err);
}
+#if defined(__linux__)
static GuestNetworkInterfaceList *
guest_find_interface(GuestNetworkInterfaceList *head,
const char *name)
@@ -904,6 +905,16 @@ error:
return NULL;
}
+#else /* defined(linux) */
+
+GuestNetworkInterfaceList *qmp_guest_network_get_interfaces(Error **err)
+{
+error_set(err, QERR_UNSUPPORTED);
+return NULL;
+}
+
+#endif /* defined(linux) */
+
/* register init/cleanup routines for stateful command groups */
void ga_command_state_init(GAState *s, GACommandState *cs)
{
--
1.7.8.5
Re: [Qemu-devel] [PATCH] hw/vexpress.c: Add NOR flash model
On 20 March 2012 14:57, Liming Wang walimis...@gmail.com wrote:
Vexpress motherboard has two 2x16 NOR flash, but pflash_cfi01
doesn't support interleaving, so here only models two 1x32 flash.
Although it's not exactly modeled, it works fine for running linux.
Signed-off-by: Liming Wang walimis...@gmail.com
---
hw/vexpress.c | 19 +--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/hw/vexpress.c b/hw/vexpress.c
index b9aafec..921b01b 100644
--- a/hw/vexpress.c
+++ b/hw/vexpress.c
@@ -29,9 +29,13 @@
#include sysemu.h
#include boards.h
#include exec-memory.h
+#include flash.h
+#include blockdev.h
#define VEXPRESS_BOARD_ID 0x8e0
+#define VEXPRESS_FLASH_SIZE 0x0400
+
static struct arm_boot_info vexpress_binfo;
/* Address maps for peripherals:
@@ -355,6 +359,9 @@ static void vexpress_common_init(const VEDBoardInfo
*daughterboard,
MemoryRegion *vram = g_new(MemoryRegion, 1);
MemoryRegion *sram = g_new(MemoryRegion, 1);
const target_phys_addr_t *map = daughterboard-motherboard_map;
+ DriveInfo *dinfo = NULL;
+ uint32_t sector_len = 256 * 1024;
+ int i = 0;
daughterboard-init(daughterboard, ram_size, cpu_model, pic, proc_id);
@@ -405,9 +412,17 @@ static void vexpress_common_init(const VEDBoardInfo
*daughterboard,
sysbus_create_simple(pl111, map[VE_CLCD], pic[14]);
- /* VE_NORFLASH0: not modelled */
+ for(i = 0; i 2; i++) {
+ dinfo = drive_get(IF_PFLASH, 0, i);
+ if (dinfo) {
+ pflash_cfi01_register(((i == 0) ? map[VE_NORFLASH0] :
map[VE_NORFLASH1]), NULL,
+ ((i == 0) ? vexpress.flash0 :
vexpress:flash1),
+ VEXPRESS_FLASH_SIZE, dinfo-bdrv, sector_len,
+ VEXPRESS_FLASH_SIZE / sector_len, 4,
+ 0, 0x89, 0x89, 0x19, 0);
+ }
+ }
As it stands this will stick flash0 over the top of RAM at address
zero on the vexpress-a15, since there VE_NORFLASH0 is 0. I think
that was a mistake, and we should have it in line with the legacy
memory map, ie NORFLASH0 at 0x080 (and drop NORFLASH0ALIAS).
What's your use case for this? Do we need to/want to implement
the memory remapping so you can have flash at address 0 and
boot out of it?
-- PMM
[Qemu-devel] [Bug 957622] Re: kvm -kernel with grub multiboot kernel dumps core or exits
Thanks, Scott, the patch worked for me so I'll push it. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/957622 Title: kvm -kernel with grub multiboot kernel dumps core or exits Status in QEMU: Confirmed Status in “qemu-kvm” package in Ubuntu: Fix Released Bug description: I attempted to use kvm -kernel with a grub multiboot image, specifically grub-maverick-20100729.img at [1]. That file was built using [2] $ url=http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/download/head:/grubmaverick20100729-20100729071944-bevge631maio9jpl-2/grub-maverick-20100729.img; $ wget $url -O grub-maverick-20100729.img $ qemu-img create -f qcow2 disk.img 1G $ kvm -curses -kernel grub-maverick-20100729.img -drive file=disk.img,if=virtio This process works fine on oneiric and you will see a curses interface, and some output of grub looking for a image to boot. On my laptop (with kvm support), I saw: $ kvm -curses -kernel grub-maverick-20100729.img -drive file=disk.img,if=virtio; fread() failed $ echo $? 1 On a kvm guest (via openstack instance), it crashed differently: $ kvm -curses -kernel grub-maverick-20100729.img -drive file=disk.img,if=virtio Could not access KVM kernel module: No such file or directory failed to initialize KVM: No such file or directory Back to tcg accelerator. GLib-ERROR **: /build/buildd/glib2.0-2.31.20/./glib/gmem.c:165: failed to allocate 4293918720 bytes Trace/breakpoint trap (core dumped) Just for a test, I tried loading kvm-amd, got nested kvm virtualization, but the instance fails the same way. -- [1] http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/files/head:/loaders/ [2] http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/view/head:/mk-image-mb-loader ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: kvm (not installed) ProcVersionSignature: User Name 3.2.0-18.29-virtual 3.2.9 Uname: Linux 3.2.0-18-virtual x86_64 ApportVersion: 1.94.1-0ubuntu2 Architecture: amd64 CurrentDmesg: [27230.320857] init: qemu-kvm pre-start process (8659) terminated with status 1 [27230.361904] init: qemu-kvm post-stop process (8664) terminated with status 1 [27249.426836] kvm[9021] trap int3 ip:7f44c2bbc13b sp:7fff447e1120 error:0 [27263.380598] kvm[9283] trap int3 ip:7f3fba9f713b sp:7fff8b55d1a0 error:0 Date: Sat Mar 17 01:48:13 2012 Ec2AMI: ami- Ec2AMIManifest: FIXME Ec2AvailabilityZone: nova Ec2InstanceType: m1.small Ec2Kernel: unavailable Ec2Ramdisk: unavailable KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd MachineType: Bochs Bochs ProcEnviron: TERM=screen PATH=(custom, user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-18-virtual root=LABEL=cloudimg-rootfs ro console=ttyS0 ProcModules: acpiphp 24231 0 - Live 0x floppy 70365 0 - Live 0x psmouse 87603 0 - Live 0x serio_raw 13211 0 - Live 0x virtio_balloon 13108 0 - Live 0x SourcePackage: qemu-kvm UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/01/2007 dmi.bios.vendor: Bochs dmi.bios.version: Bochs dmi.chassis.type: 1 dmi.chassis.vendor: Bochs dmi.modalias: dmi:bvnBochs:bvrBochs:bd01/01/2007:svnBochs:pnBochs:pvr:cvnBochs:ct1:cvr: dmi.product.name: Bochs dmi.sys.vendor: Bochs To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/957622/+subscriptions
Re: [Qemu-devel] [PATCH 09/36] vmstate: introduce float32 arrays
Peter Maydell peter.mayd...@linaro.org wrote:
On 19 March 2012 22:57, Juan Quintela quint...@redhat.com wrote:
+/* 32 bit float */
+
+typedef union {
+ float32 f;
+ uint32_t i;
+} VMStateFloat32;
+
+static int get_float32(QEMUFile *f, void *pv, size_t size)
+{
+ float32 *v = pv;
+ VMStateFloat32 u;
+ qemu_get_be32s(f, u.i);
+ *v = u.f;
+ return 0;
+}
+
+static void put_float32(QEMUFile *f, void *pv, size_t size)
+{
+ float32 *v = pv;
+ VMStateFloat32 u;
+ u.f = *v;
+ qemu_put_be32s(f, u.i);
+}
This conversion (float32-uint32_t) should be done via
float32_val() and make_float32().
you are right. we can even simplify things with this. Thanks.
[Qemu-devel] [PATCH] softfloat: make USE_SOFTFLOAT_STRUCT_TYPES compile
This change makes it compile and return the same value than the #undef one.
Signed-off-by: Juan Quintela quint...@redhat.com
---
fpu/softfloat.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fpu/softfloat.c b/fpu/softfloat.c
index 81a7d1a..a1f4527 100644
--- a/fpu/softfloat.c
+++ b/fpu/softfloat.c
@@ -2219,7 +2219,7 @@ float32 float32_muladd(float32 a, float32 b, float32 c,
int flags STATUS_PARAM)
}
}
/* Zero plus something non-zero : just return the something */
-return c ^ (signflip 31);
+return make_float32(float32_val(c) ^ (signflip 31));
}
if (aExp == 0) {
@@ -3772,7 +3772,7 @@ float64 float64_muladd(float64 a, float64 b, float64 c,
int flags STATUS_PARAM)
}
}
/* Zero plus something non-zero : just return the something */
-return c ^ ((uint64_t)signflip 63);
+return make_float64(float64_val(c) ^ ((uint64_t)signflip 63));
}
if (aExp == 0) {
--
1.7.7.6
[Qemu-devel] [Bug 957622] Re: kvm -kernel with grub multiboot kernel dumps core or exits
This bug was fixed in the package qemu-kvm - 1.0+noroms-0ubuntu9 --- qemu-kvm (1.0+noroms-0ubuntu9) precise; urgency=low * debian/patches/multiboot-load-fix.diff: fix bug when loading multiboot images such as grub via -kernel parameter (LP: #957622) -- Scott Moser smo...@ubuntu.com Sun, 18 Mar 2012 19:34:28 -0400 ** Changed in: qemu-kvm (Ubuntu) Status: In Progress = Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/957622 Title: kvm -kernel with grub multiboot kernel dumps core or exits Status in QEMU: Confirmed Status in “qemu-kvm” package in Ubuntu: Fix Released Bug description: I attempted to use kvm -kernel with a grub multiboot image, specifically grub-maverick-20100729.img at [1]. That file was built using [2] $ url=http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/download/head:/grubmaverick20100729-20100729071944-bevge631maio9jpl-2/grub-maverick-20100729.img; $ wget $url -O grub-maverick-20100729.img $ qemu-img create -f qcow2 disk.img 1G $ kvm -curses -kernel grub-maverick-20100729.img -drive file=disk.img,if=virtio This process works fine on oneiric and you will see a curses interface, and some output of grub looking for a image to boot. On my laptop (with kvm support), I saw: $ kvm -curses -kernel grub-maverick-20100729.img -drive file=disk.img,if=virtio; fread() failed $ echo $? 1 On a kvm guest (via openstack instance), it crashed differently: $ kvm -curses -kernel grub-maverick-20100729.img -drive file=disk.img,if=virtio Could not access KVM kernel module: No such file or directory failed to initialize KVM: No such file or directory Back to tcg accelerator. GLib-ERROR **: /build/buildd/glib2.0-2.31.20/./glib/gmem.c:165: failed to allocate 4293918720 bytes Trace/breakpoint trap (core dumped) Just for a test, I tried loading kvm-amd, got nested kvm virtualization, but the instance fails the same way. -- [1] http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/files/head:/loaders/ [2] http://bazaar.launchpad.net/~ubuntu-on-ec2/vmbuilder/automated-ec2-builds/view/head:/mk-image-mb-loader ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: kvm (not installed) ProcVersionSignature: User Name 3.2.0-18.29-virtual 3.2.9 Uname: Linux 3.2.0-18-virtual x86_64 ApportVersion: 1.94.1-0ubuntu2 Architecture: amd64 CurrentDmesg: [27230.320857] init: qemu-kvm pre-start process (8659) terminated with status 1 [27230.361904] init: qemu-kvm post-stop process (8664) terminated with status 1 [27249.426836] kvm[9021] trap int3 ip:7f44c2bbc13b sp:7fff447e1120 error:0 [27263.380598] kvm[9283] trap int3 ip:7f3fba9f713b sp:7fff8b55d1a0 error:0 Date: Sat Mar 17 01:48:13 2012 Ec2AMI: ami- Ec2AMIManifest: FIXME Ec2AvailabilityZone: nova Ec2InstanceType: m1.small Ec2Kernel: unavailable Ec2Ramdisk: unavailable KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd MachineType: Bochs Bochs ProcEnviron: TERM=screen PATH=(custom, user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-18-virtual root=LABEL=cloudimg-rootfs ro console=ttyS0 ProcModules: acpiphp 24231 0 - Live 0x floppy 70365 0 - Live 0x psmouse 87603 0 - Live 0x serio_raw 13211 0 - Live 0x virtio_balloon 13108 0 - Live 0x SourcePackage: qemu-kvm UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/01/2007 dmi.bios.vendor: Bochs dmi.bios.version: Bochs dmi.chassis.type: 1 dmi.chassis.vendor: Bochs dmi.modalias: dmi:bvnBochs:bvrBochs:bd01/01/2007:svnBochs:pnBochs:pvr:cvnBochs:ct1:cvr: dmi.product.name: Bochs dmi.sys.vendor: Bochs To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/957622/+subscriptions
Re: [Qemu-devel] [PATCH] softfloat: make USE_SOFTFLOAT_STRUCT_TYPES compile
On 20 March 2012 15:24, Juan Quintela quint...@redhat.com wrote: This change makes it compile and return the same value than the #undef one. Signed-off-by: Juan Quintela quint...@redhat.com Oops, that would have been my fault when I put in the fused multiply accumulate support. Reviewed-by: Peter Maydell peter.mayd...@linaro.org -- PMM
Re: [Qemu-devel] [PATCH] softfloat: make USE_SOFTFLOAT_STRUCT_TYPES compile
Am 20.03.2012 16:24, schrieb Juan Quintela:
This change makes it compile and return the same value than the #undef one.
Signed-off-by: Juan Quintela quint...@redhat.com
Cool,
Acked-by: Andreas Färber afaer...@suse.de
Tested the default, non-struct version only.
Juan, would it make sense to add a configure option for this #define,
similar to --enable-debug-tcg?
Andreas
---
fpu/softfloat.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fpu/softfloat.c b/fpu/softfloat.c
index 81a7d1a..a1f4527 100644
--- a/fpu/softfloat.c
+++ b/fpu/softfloat.c
@@ -2219,7 +2219,7 @@ float32 float32_muladd(float32 a, float32 b, float32 c,
int flags STATUS_PARAM)
}
}
/* Zero plus something non-zero : just return the something */
-return c ^ (signflip 31);
+return make_float32(float32_val(c) ^ (signflip 31));
}
if (aExp == 0) {
@@ -3772,7 +3772,7 @@ float64 float64_muladd(float64 a, float64 b, float64 c,
int flags STATUS_PARAM)
}
}
/* Zero plus something non-zero : just return the something */
-return c ^ ((uint64_t)signflip 63);
+return make_float64(float64_val(c) ^ ((uint64_t)signflip 63));
}
if (aExp == 0) {
--
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] [RFC PATCH 08/10] qed: add bdrv_post_incoming_migration operation checking the image
On Tue, Mar 06, 2012 at 06:32:27PM +0100, Benoît Canet wrote:
@@ -1529,6 +1529,19 @@ static int
bdrv_qed_change_backing_file(BlockDriverState *bs,
return ret;
}
+static void bdrv_qed_check_if_needed(BlockDriverState *bs)
+{
+/* close the block device if the verification fail */
+if (check_image_if_needed(bs)) {
+bdrv_close(bs);
+}
We open the image for incoming migration while the VM is still running.
That means the metadata and header can still change before migration
switchover. So we need to drop everything we know about this image and
start from scratch.
qcow2 does it like this:
qcow2_close(bs);
memset(s, 0, sizeof(BDRVQcowState));
qcow2_open(bs, flags);
We should do something similar so that the QED header is re-read. This
probably means check_image_if_needed() doesn't need to be factored out
of qed_open().
(Note that the underlying file and BlockDriverState don't get reopened,
we're simply reinitializing the QED/QCOW2 image format layer here.)
Stefan
