Re: [Qemu-devel] [RFC] New thread for the VM migration
Juan Quintela writes: [...] > I have think a little bit about hotplug & migration, and haven't arraive > to a nice solution. > > - Disabling hotplug/unplug during migration: easy to do. But it is not > exactly user friendly (we are here). > > - Allowing hotplug during migration. Solutions: > * allow the transfer of hotplug events over the migration protocol > (make it even more complicated, but not too much. The big problem is > if the hotplug succeeds on the source but not the destination, ...) > * migrate the device list in stage 3: it fixes the hotplug problem > nicely, but it makes the interesting problem that after migrating > all the ram, we can find "interesting" problems like: disk not > readable, etc. Not funny. > * > > As far as I can see, if we sent the device list 1st, we can create the > full machine at destination, but hotplug is "interesting" to manage. > Sending the device list late, solve hotplug, but allows errors after > migrating all memory (also known as, why don't you told me *sooner*). I figure the errors relevant here happen in device backends (host parts) mostly. Maybe updating just backends is easier than full device hot plug. Configure backends before migrating memory, to catch errors. Reconfigure backends afterwards for hot plug[*]. Then build machine. You still get errors from frontends (device models) after migrating memory, but they should be rare. [...] [*] You could do it "in the middle" to catch errors as early as possible, but I doubt it's worth the trouble.
[Qemu-devel] [PATCH] USB: add usb network redirection support
This patch adds support for a usb-redir device, which takes a chardev as a communication channel to an actual usbdevice using the usbredir protocol. Compiling the usb-redir device requires usbredir-0.3 to be installed for the usbredir protocol parser, usbredir-0.3 also contains a server for redirecting usb traffic from an actual usb device. You can get the 0.3 release of usbredir here: http://people.fedoraproject.org/~jwrdegoede/usbredir-0.3.tar.bz2 (getting a more formal site for it is a WIP) Example usage: 1) Start usbredirserver for a usb device: sudo usbredirserver 045e:0772 2) Start qemu with usb2 support + a chardev talking to usbredirserver + a usb-redir device using this chardev: qemu ... \ -readconfig /home/hans/projects/qemu/docs/ich9-ehci-uhci.cfg \ -chardev socket,id=usbredirchardev,host=localhost,port=4000 \ -device usb-redir,chardev=usbredirchardev,id=usbredirdev --- Makefile.objs |1 + configure | 28 ++ usb-redir.c | 1214 + 3 files changed, 1243 insertions(+), 0 deletions(-) create mode 100644 usb-redir.c diff --git a/Makefile.objs b/Makefile.objs index cea15e4..ad69fbc 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -205,6 +205,7 @@ hw-obj-$(CONFIG_HPET) += hpet.o hw-obj-$(CONFIG_APPLESMC) += applesmc.o hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o ccid-card-passthru.o hw-obj-$(CONFIG_SMARTCARD_NSS) += ccid-card-emulated.o +hw-obj-$(CONFIG_USB_REDIR) += usb-redir.o # PPC devices hw-obj-$(CONFIG_OPENPIC) += openpic.o diff --git a/configure b/configure index 88159ac..843bbd8 100755 --- a/configure +++ b/configure @@ -177,6 +177,7 @@ spice="" rbd="" smartcard="" smartcard_nss="" +usb_redir="" opengl="" # parse CC options first @@ -743,6 +744,10 @@ for opt do ;; --enable-smartcard-nss) smartcard_nss="yes" ;; + --disable-usb-redir) usb_redir="no" + ;; + --enable-usb-redir) usb_redir="yes" + ;; *) echo "ERROR: unknown option $opt"; show_help="yes" ;; esac @@ -1018,6 +1023,8 @@ echo " --disable-smartcard disable smartcard support" echo " --enable-smartcard enable smartcard support" echo " --disable-smartcard-nss disable smartcard nss support" echo " --enable-smartcard-nss enable smartcard nss support" +echo " --disable-usb-redir disable usb network redirection support" +echo " --enable-usb-redir enable usb network redirection support" echo "" echo "NOTE: The object files are built at the place where configure is launched" exit 1 @@ -2371,6 +2378,22 @@ if test "$smartcard" = "no" ; then smartcard_nss="no" fi +# check for usbredirparser for usb network redirection support +if test "$usb_redir" != "no" ; then +if $pkg_config libusbredirparser >/dev/null 2>&1 ; then +usb_redir="yes" +usb_redir_cflags=$($pkg_config --cflags libusbredirparser 2>/dev/null) +usb_redir_libs=$($pkg_config --libs libusbredirparser 2>/dev/null) +QEMU_CFLAGS="$QEMU_CFLAGS $usb_redir_cflags" +LIBS="$LIBS $usb_redir_libs" +else +if test "$usb_redir" = "yes"; then +feature_not_found "usb-redir" +fi +usb_redir="no" +fi +fi + ## ## @@ -2617,6 +2640,7 @@ echo "spice support $spice" echo "rbd support $rbd" echo "xfsctl support$xfs" echo "nss used $smartcard_nss" +echo "usb net redir $usb_redir" echo "OpenGL support$opengl" if test $sdl_too_old = "yes"; then @@ -2910,6 +2934,10 @@ if test "$smartcard_nss" = "yes" ; then echo "CONFIG_SMARTCARD_NSS=y" >> $config_host_mak fi +if test "$usb_redir" = "yes" ; then + echo "CONFIG_USB_REDIR=y" >> $config_host_mak +fi + if test "$opengl" = "yes" ; then echo "CONFIG_OPENGL=y" >> $config_host_mak fi diff --git a/usb-redir.c b/usb-redir.c new file mode 100644 index 000..bb29ebd --- /dev/null +++ b/usb-redir.c @@ -0,0 +1,1214 @@ +/* + * USB redirector usb-guest + * + * Copyright (c) 2011 Red Hat, Inc. + * + * Red Hat Authors: + * Hans de Goede + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to deal + * in the Software without restriction, including without limitation the rights + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell + * copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR
Re: [Qemu-devel] [PATCH] USB: add usb network redirection support
Hi, Note that using this with devices where a lot of data is send to the device (ie a usb stick and writing to it a lot) may lead to increased latencies, due to the long missing flowcontrol support in chardev in one direction. For those interested, my personal tree contains Amit's flowcontrol patches ported to the latest qemu-git + a version of the usb-redir patch with flowcontrol support: http://cgit.freedesktop.org/~jwrdegoede/qemu/log/?h=usbredir Regards, Hans
[Qemu-devel] Possible leak in block/qcow.c
Hi, I noted that there are two cluster_data member in block/qcow.c, one in BDRVQcowState, the other in QCowAIOCB. The last one is used in qcow_aio_write_cb to hold buffer for encrypt the cluster before write but I cannot find any related qemu_free while I can find many place where BDRVQcowState::cluster_data is freed. It seems to me a leak but I don't understand why nobody reported this problem before (it should happen at every write so anybody using qcow encrypted should rapidly see this problem). Perhaps there is a sort of garbage collector I'm not aware? Frediano Ziglio
Re: [Qemu-devel] nested VMX + unrelated qemu bug
On 16.07.2011, at 18:26, Blue Swirl wrote:
> On Sat, Jul 16, 2011 at 10:53 AM, Alexander Graf wrote:
>>
>> On 14.07.2011, at 17:22, Bernhard M. Wiedemann wrote:
>>
>>> Hi,
>>>
>>> I tried nested VMX on Xeon E5630 and it worked really well with the Kernel
>>> from avi's git and 0.14.0
>>> (with modprobe kvm-intel nested=1)
>>>
>>>
>>> but in the process I found that qemu built from
>>> git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
>>> crashed when started with -m 3600 or more
>>> while booting into openSUSE-11.3 where 0.14.0 worked well (even with 5GB)
>>>
>>> ./x86_64-softmmu/qemu-system-x86_64 -drive
>>> file=opensuse-113-64.img,if=virtio,boot=on -m 3600 -serial stdio -vnc :9
>>> Could not open option rom 'extboot.bin': No such file or directory
>>> doing fast boot
>>> Creating device nodes with udev
>>> Trying manual resume from /dev/vda1
>>> Invoking userspace resume from /dev/vda1
>>> resume: libgcrypt version: 1.4.4
>>> Trying manual resume from /dev/vda1
>>> Invoking in-kernel resume from /dev/vda1
>>> Waiting for device /dev/vda2 to appear: ok
>>> fsck from util-linux-ng 2.17.2
>>> [/sbin/fsck.ext4 (1) -- /] fsck.ext4 -a /dev/vda2
>>> /dev/vda2: recovering journal
>>> /dev/vda2: clean, 62553/230608 files, 449938/922112 blocks
>>> fsck succeeded. Mounting root device read-write.
>>> Mounting root /dev/vda2
>>> mount -o rw,acl,user_xattr -t ext4 /dev/vda2 /root
>>>
>>> Bad ram offset 1009cc000
>>> Aborted
>>
>> Ah, the infamous memory map bug.
>>
>> Anthony, could you please pull the xen-next branch so this one finally gets
>> fixed? The following patch should resolve that issue:
>>
>> commit f221e5ac378feea71d9857ddaa40f829c511742f
>> Author: Stefano Stabellini
>> Date: Mon Jun 27 18:26:06 2011 +0100
>>
>>qemu_ram_ptr_length: take ram_addr_t as arguments
>>
>>qemu_ram_ptr_length should take ram_addr_t as argument rather than
>>target_phys_addr_t because is doing comparisons with RAMBlock addresses.
>>
>>cpu_physical_memory_map should create a ram_addr_t address to pass to
>>qemu_ram_ptr_length from PhysPageDesc phys_offset.
>>
>>Remove code after abort() in qemu_ram_ptr_length.
>>
>>
>> Otherwise, Blue - as you do have commit rights as well - Anthony seems to be
>> rather busy these days. Could you please jump in and commit the outstanding
>> pull requests from maintainers?
>
> The pull would break build:
> LINK alpha-softmmu/qemu-system-alpha
> ../xen_console.o: In function `con_init':
> /src/qemu/hw/xen_console.c:208: undefined reference to
> `xenstore_store_pv_console_info'
ARGH :(
...
I've squashed the following patch into the offending patch now and rebased
everything on current HEAD (same URL, I don't think it's worth it to respam the
ML with another almost identical pull request)
diff --git a/xen-stub.c b/xen-stub.c
index a4f35a1..efe2ab5 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -9,6 +9,10 @@
#include "qemu-common.h"
#include "hw/xen.h"
+void xenstore_store_pv_console_info(int i, CharDriverState *chr)
+{
+}
+
int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
{
return -1;
Alex
Re: [Qemu-devel] [Bug 811683] [NEW] 7400, 7410, 7450 cpus vector have wrong exception prefix at reset
On 18.07.2011, at 00:34, Andreas Färber wrote: > Hi, > > Am 16.07.2011 um 23:49 schrieb till: > >> I have a proprietary ROM implementing system calls that are executed via >> the 'SC' instruction. >> >> I use qemu-0.14.1, >> >> qemu-system-ppc -M prep -cpu $CPU -bios my_bios -kernel my_kernel >> >> That works fine on a 604 (CPU=0x00040103) - but does not on an emulated 7400 >> (CPU=0x000c0209) or 7450 (CPU=0x8201). I found that the emulator jumps >> to 0x0c00 instead of 0xfff00c00. >> Probably this is due to a wrong setting in target-ppc/translate_init.c: >> >> init_excp_604() correctly sets env->hreset_vector=0xfff0UL; >> >> but >> >> init_excp_7400() says env->hreset_vector=0xUL; >> >> which seems wrong. (the 7400 manual says a hard-reset jumps initializes the >> prefix to 0xfff0.) > > Do you have a link to a spec saying so? Should be trivial to change then. According to MPC7450UM.pdf: MSR Bit Settings Bit: 25 Name: IP Exception prefix. The setting of this bit specifies whether an exception vector offset is prepended with Fs or 0s. In the following description, n is the offset of the exception. 0 Exceptions are vectored to the physical address 0x000n_. 1 Exceptions are vectored to the physical address 0xFFFn_. [...] 9.9.1 Reset Inputs The MPC7450 has two reset inputs, described as follows: • HRESET (hard reset)—The HRESET signal is used for power-on reset sequences, or for situations in which the MPC7450 must go through the entire cold start sequence of internal hardware initialization. The MPC7450 will initiate burst transactions after power-on reset in 60x bus mode. • SRESET (soft reset)—The soft reset input provides warm reset capability. This input can be used to avoid forcing the MPC7450 to complete the cold start sequence. When either reset input negates, the processor attempts to fetch code from the system reset exception vector. The vector is located at offset 0x00100 from the exception prefix (MSR[IP]). > The MSR[IP] bit is set when HRESET negates. So the correct implementation would be to set hreset_vector to 0xfff0, but also set MSR_IP and clear hreset_vector when MSR_IP gets modified. I'll happily take patches :). Alex
[Qemu-devel] [PULL] v2: pending linux-user patches
The following changes since commit 89b9ba661bd2d6155308f895ec075d813f0e129b: Fix signal handling of SIG_IPI when io-thread is enabled (2011-07-16 19:43:00 +) are available in the git repository at: git://git.linaro.org/people/rikuvoipio/qemu.git linux-user-for-upstream Cédric VINCENT (4): arm-semi: Provide access to CLI arguments passed through the "-append" option linux-user: Add support for KD...LED ioctls linux-user: Add support for more VT ioctls linux-user: Add support for even more FB ioctls Peter Maydell (4): linux-user: Add syscall numbers from kernel 2.6.39.2 linux-user: Implement prlimit64 syscall linux-user/syscall.c: Enforce pselect6 sigset size restrictions linux-user/signal.c: Rename s390 target_ucontext fields to fix ia64 Riku Voipio (2): linux-user: correct syscall 123 on sh4 linux-user: make MIPS and ARM eabi use same argument reordering Wesley W. Terpstra (5): mips: sigaltstack args mips: missing syscall returns wrong errno mips: null pointer deref should segfault mips: rlimit incorrectly converts values mips: rlimit codes are not the same arm-semi.c | 113 --- linux-user/alpha/syscall_nr.h | 23 +- linux-user/arm/syscall_nr.h| 13 +++ linux-user/cris/syscall_nr.h |2 + linux-user/i386/syscall_nr.h | 12 +++ linux-user/ioctls.h| 13 +++ linux-user/m68k/syscall_nr.h | 16 linux-user/main.c | 33 +++- linux-user/microblaze/syscall_nr.h | 14 +++- linux-user/mips/syscall_nr.h | 13 +++ linux-user/mips64/syscall_nr.h | 13 +++ linux-user/mipsn32/syscall_nr.h| 14 +++ linux-user/ppc/syscall_nr.h| 30 +++ linux-user/s390x/syscall_nr.h | 13 +++- linux-user/sh4/syscall_nr.h| 34 - linux-user/signal.c| 30 linux-user/sparc/syscall_nr.h | 12 +++ linux-user/sparc64/syscall_nr.h| 12 +++ linux-user/syscall.c | 153 +--- linux-user/syscall_defs.h | 51 linux-user/syscall_types.h | 20 + linux-user/x86_64/syscall_nr.h | 12 +++ 22 files changed, 549 insertions(+), 97 deletions(-)
Re: [Qemu-devel] [PATCH 1/3] Fix conversions from pointer to tcg_target_long
On 15.07.2011, at 21:38, Stefan Weil wrote: > tcg_gen_exit_tb takes a parameter of type tcg_target_long, > so the type casts of pointer to long should be replaced by > type casts of pointer to tcg_target_long. > > These changes are needed for build environments where > sizeof(long) != sizeof(void *), especially for w64. > > See 4b4a72e55660abf7efe85aca78762dcfea5519ad which fixed the > same issue for the other targets. Changes the code to be aligned with the i386 target, so I'm in favor. Acked-by: Alexander Graf Alex
Re: [Qemu-devel] [PATCH 3/4] Add generic drive hotplugging
On 14.07.2011, at 14:13, Kevin Wolf wrote:
> Am 12.07.2011 09:21, schrieb Alexander Graf:
>> The monitor command for hotplugging is in i386 specific code. This is just
>> plain wrong, as S390 just learned how to do hotplugging too and needs to
>> get drives for that.
>>
>> So let's add a generic copy to generic code that handles drive_add in a
>> way that doesn't have pci dependencies. All pci specific code can then
>> be handled in a pci specific function.
>>
>> Signed-off-by: Alexander Graf
>>
>> ---
>>
>> v1 -> v2:
>>
>> - align generic drive_add to pci specific one
>> - rework to split between generic and pci code
>> ---
>> hw/device-hotplug.c | 51
>> +++
>> hw/pci-hotplug.c| 24
>> sysemu.h|6 +-
>> 3 files changed, 60 insertions(+), 21 deletions(-)
>>
>> diff --git a/hw/device-hotplug.c b/hw/device-hotplug.c
>> index 8b2ed7a..eb6dd0e 100644
>> --- a/hw/device-hotplug.c
>> +++ b/hw/device-hotplug.c
>> @@ -26,6 +26,9 @@
>> #include "boards.h"
>> #include "net.h"
>> #include "blockdev.h"
>> +#include "qemu-config.h"
>> +#include "sysemu.h"
>> +#include "monitor.h"
>>
>> DriveInfo *add_init_drive(const char *optstr)
>> {
>> @@ -44,3 +47,51 @@ DriveInfo *add_init_drive(const char *optstr)
>>
>> return dinfo;
>> }
>> +
>> +#if !defined(TARGET_I386)
>> +int pci_drive_hot_add(Monitor *mon, const QDict *qdict,
>> + DriveInfo *dinfo, int type)
>> +{
>> +/* On non-x86 we don't do PCI hotplug */
>> +monitor_printf(mon, "Can't hot-add drive to type %d\n", type);
>> +return -1;
>> +}
>> +#endif
>
> This assumes that only x86 can do PCI hotplug. If someone added it to
> another target, the error should be obvious enough, so I guess it's okay.
Yes, I tried to keep it functionally the same. If any other targets want to add
PCI hotplug support, it's as simple as an #ifdef change. For now, none does :).
Next time someone adds PCI hotplug support for another arch, we might want to
consider cleaning this whole thing up a bit though.
>
>> +
>> +/*
>> + * This version of drive_hot_add does not know anything about PCI specifics.
>> + * It is used as fallback on architectures that don't implement pci-hotplug.
>> + */
>
> Maybe it was true in v1, don't know, but now it's not a fallback, but a
> common implementation that is used by both x86 and s390 and calls a more
> specific one in some cases.
>
> It also doesn't make too much sense to have a comment that says what a
> function is _not_. Without knowing the context of this patch, I probably
> wouldn't understand what the comment is trying to say.
Yep. Will just remove the comment.
>
>> +void drive_hot_add(Monitor *mon, const QDict *qdict)
>> +{
>> +int type;
>> +DriveInfo *dinfo = NULL;
>> +const char *opts = qdict_get_str(qdict, "opts");
>> +
>> +dinfo = add_init_drive(opts);
>> +if (!dinfo) {
>> +goto err;
>> +}
>> +if (dinfo->devaddr) {
>> +monitor_printf(mon, "Parameter addr not supported\n");
>> +goto err;
>> +}
>> +type = dinfo->type;
>> +
>> +switch (type) {
>> +case IF_NONE:
>> +monitor_printf(mon, "OK\n");
>> +break;
>> +default:
>> +if (pci_drive_hot_add(mon, qdict, dinfo, type)) {
>> +goto err;
>> +}
>> +}
>> +return;
>> +
>> +err:
>> +if (dinfo) {
>> +drive_put_ref(dinfo);
>> +}
>> +return;
>> +}
>> diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c
>> index b59be2a..f08d367 100644
>> --- a/hw/pci-hotplug.c
>> +++ b/hw/pci-hotplug.c
>> @@ -103,24 +103,13 @@ static int scsi_hot_add(Monitor *mon, DeviceState
>> *adapter,
>> return 0;
>> }
>>
>> -void drive_hot_add(Monitor *mon, const QDict *qdict)
>> +int pci_drive_hot_add(Monitor *mon, const QDict *qdict,
>> + DriveInfo *dinfo, int type)
>> {
>> int dom, pci_bus;
>> unsigned slot;
>> -int type;
>> PCIDevice *dev;
>> -DriveInfo *dinfo = NULL;
>> const char *pci_addr = qdict_get_str(qdict, "pci_addr");
>> -const char *opts = qdict_get_str(qdict, "opts");
>> -
>> -dinfo = add_init_drive(opts);
>> -if (!dinfo)
>> -goto err;
>> -if (dinfo->devaddr) {
>> -monitor_printf(mon, "Parameter addr not supported\n");
>> -goto err;
>> -}
>> -type = dinfo->type;
>>
>> switch (type) {
>> case IF_SCSI:
>> @@ -137,19 +126,14 @@ void drive_hot_add(Monitor *mon, const QDict *qdict)
>> goto err;
>> }
>> break;
>> -case IF_NONE:
>> -monitor_printf(mon, "OK\n");
>> -break;
>> default:
>> monitor_printf(mon, "Can't hot-add drive to type %d\n", type);
>> goto err;
>> }
>> -return;
>>
>> +return 0;
>> err:
>> -if (dinfo)
>> -drive_put_ref(dinfo);
>> -return;
>> +return -1;
>> }
>
> Now that there isn't any error handling any more, "got
[Qemu-devel] [PATCH 2/4] Compile device-hotplug on all targets
All guest targets could potentially implement hotplugging. With the next patches in this set I will also reflect this in the monitor interface. So let's always compile it in. It shouldn't hurt. Signed-off-by: Alexander Graf --- Makefile.target |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/Makefile.target b/Makefile.target index a53a2ff..84fd700 100644 --- a/Makefile.target +++ b/Makefile.target @@ -230,12 +230,15 @@ ifeq ($(CONFIG_KVM), y) endif obj-$(CONFIG_IVSHMEM) += ivshmem.o +# Generic hotplugging +obj-y += device-hotplug.o + # Hardware support obj-i386-y += vga.o obj-i386-y += mc146818rtc.o i8259.o pc.o obj-i386-y += cirrus_vga.o sga.o apic.o ioapic.o piix_pci.o obj-i386-y += vmport.o -obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o +obj-i386-y += pci-hotplug.o smbios.o wdt_ib700.o obj-i386-y += debugcon.o multiboot.o obj-i386-y += pc_piix.o obj-i386-$(CONFIG_KVM) += kvmclock.o -- 1.6.0.2
[Qemu-devel] [PATCH 4/4] Expose drive_add on all architectures
All architectures can now use drive_add on the monitor. This of course
does not mean that there is hotplug support for the specific platform,
so in order to actually make use of the new drives you still need to
have a hotplug capable device.
Signed-off-by: Alexander Graf
---
hmp-commands.hx |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 6ad8806..e275f88 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -857,7 +857,6 @@ STEXI
Snapshot device, using snapshot file as target if provided
ETEXI
-#if defined(TARGET_I386)
{
.name = "drive_add",
.args_type = "pci_addr:s,opts:s",
@@ -869,7 +868,6 @@ ETEXI
.help = "add drive to PCI storage controller",
.mhandler.cmd = drive_hot_add,
},
-#endif
STEXI
@item drive_add
--
1.6.0.2
Re: [Qemu-devel] [PATCH v9 00/12] Adding VMDK monolithic flat support
On Tue, Jul 12, 2011 at 07:56:27PM +0800, Fam Zheng wrote: > Changes from v8: > 09/12: remove duplicated sscanf > 10/12: change option name to 'subformat', change commit message typo, > factor common parts of creating, and other small improvements > > Fam Zheng (12): > VMDK: introduce VmdkExtent > VMDK: bugfix, align offset to cluster in get_whole_cluster > VMDK: probe for monolithicFlat images > VMDK: separate vmdk_open by format version > VMDK: add field BDRVVmdkState.desc_offset > VMDK: flush multiple extents > VMDK: move 'static' cid_update flag to bs field > VMDK: change get_cluster_offset return type > VMDK: open/read/write for monolithicFlat image > VMDK: create different subformats > VMDK: fix coding style > block: add bdrv_get_allocated_file_size() operation > > block.c | 19 + > block.h |1 + > block/raw-posix.c | 21 + > block/raw-win32.c | 29 ++ > block/vmdk.c | 1296 > - > block_int.h |2 + > qemu-img.c| 31 +-- > 7 files changed, 964 insertions(+), 435 deletions(-) Reviewed-by: Stefan Hajnoczi
[Qemu-devel] [PATCH 1/4] [S390] Add hotplug support
I just submitted a few patches that enable the s390 virtio bus to receive
a hotplug add event. This patch implements the qemu side of it, so that new
hotplug events can be submitted to the guest.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- make s390 virtio hoplug code emulate-capable
---
hw/s390-virtio-bus.c | 24 +++-
hw/s390-virtio-bus.h |5 +
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/hw/s390-virtio-bus.c b/hw/s390-virtio-bus.c
index e2f3e32..0adbddb 100644
--- a/hw/s390-virtio-bus.c
+++ b/hw/s390-virtio-bus.c
@@ -82,12 +82,24 @@ VirtIOS390Bus *s390_virtio_bus_init(ram_addr_t *ram_size)
bus->dev_offs = bus->dev_page;
bus->next_ring = bus->dev_page + TARGET_PAGE_SIZE;
+/* Enable hotplugging */
+_bus->allow_hotplug = 1;
+
/* Allocate RAM for VirtIO device pages (descriptors, queues, rings) */
*ram_size += S390_DEVICE_PAGES * TARGET_PAGE_SIZE;
return bus;
}
+static void s390_virtio_irq(CPUState *env, int config_change, uint64_t token)
+{
+if (kvm_enabled()) {
+kvm_s390_virtio_irq(env, config_change, token);
+} else {
+cpu_inject_ext(env, VIRTIO_EXT_CODE, config_change, token);
+}
+}
+
static int s390_virtio_device_init(VirtIOS390Device *dev, VirtIODevice *vdev)
{
VirtIOS390Bus *bus;
@@ -109,6 +121,11 @@ static int s390_virtio_device_init(VirtIOS390Device *dev,
VirtIODevice *vdev)
dev->host_features = vdev->get_features(vdev, dev->host_features);
s390_virtio_device_sync(dev);
+if (dev->qdev.hotplugged) {
+CPUState *env = s390_cpu_addr2state(0);
+s390_virtio_irq(env, VIRTIO_PARAM_DEV_ADD, dev->dev_offs);
+}
+
return 0;
}
@@ -313,11 +330,7 @@ static void virtio_s390_notify(void *opaque, uint16_t
vector)
uint64_t token = s390_virtio_device_vq_token(dev, vector);
CPUState *env = s390_cpu_addr2state(0);
-if (kvm_enabled()) {
-kvm_s390_virtio_irq(env, 0, token);
-} else {
-cpu_inject_ext(env, VIRTIO_EXT_CODE, 0, token);
-}
+s390_virtio_irq(env, 0, token);
}
static unsigned virtio_s390_get_features(void *opaque)
@@ -385,6 +398,7 @@ static void
s390_virtio_bus_register_withprop(VirtIOS390DeviceInfo *info)
{
info->qdev.init = s390_virtio_busdev_init;
info->qdev.bus_info = &s390_virtio_bus_info;
+info->qdev.unplug = qdev_simple_unplug_cb;
assert(info->qdev.size >= sizeof(VirtIOS390Device));
qdev_register(&info->qdev);
diff --git a/hw/s390-virtio-bus.h b/hw/s390-virtio-bus.h
index f1bece7..d02a907 100644
--- a/hw/s390-virtio-bus.h
+++ b/hw/s390-virtio-bus.h
@@ -35,6 +35,11 @@
#define VIRTIO_RING_LEN(TARGET_PAGE_SIZE * 3)
#define S390_DEVICE_PAGES 512
+#define VIRTIO_PARAM_MASK 0xff
+#define VIRTIO_PARAM_VRING_INTERRUPT0x0
+#define VIRTIO_PARAM_CONFIG_CHANGED 0x1
+#define VIRTIO_PARAM_DEV_ADD0x2
+
typedef struct VirtIOS390Device {
DeviceState qdev;
ram_addr_t dev_offs;
--
1.6.0.2
[Qemu-devel] [PATCH 0/4] S390 virtio hotplug v3
Hey guys, this patch set adds support for hotplug add on S390. Apparently it's the first non-x86 platform receiving so much love in Qemu, so I've stumbled over some very basic #if defined(TARGET_I386) cases that just shouldn't be there. It's trying to make things as generic as possible. I've talked to Markus about this vs blockdev and he's fine with pulling in a "dirty" solution in case the right one takes too long. But we haven't decided on which one is more clean :). Alex Alexander Graf (4): [S390] Add hotplug support Compile device-hotplug on all targets Add generic drive hotplugging Expose drive_add on all architectures Makefile.target |5 - hmp-commands.hx |2 -- hw/device-hotplug.c | 47 +++ hw/pci-hotplug.c | 24 hw/s390-virtio-bus.c | 24 +++- hw/s390-virtio-bus.h |5 + sysemu.h |6 +- 7 files changed, 84 insertions(+), 29 deletions(-)
[Qemu-devel] [PATCH 3/4] Add generic drive hotplugging
The monitor command for hotplugging is in i386 specific code. This is just
plain wrong, as S390 just learned how to do hotplugging too and needs to
get drives for that.
So let's add a generic copy to generic code that handles drive_add in a
way that doesn't have pci dependencies. All pci specific code can then
be handled in a pci specific function.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- align generic drive_add to pci specific one
- rework to split between generic and pci code
v2 -> v3:
- remove comment
---
hw/device-hotplug.c | 47 +++
hw/pci-hotplug.c| 24
sysemu.h|6 +-
3 files changed, 56 insertions(+), 21 deletions(-)
diff --git a/hw/device-hotplug.c b/hw/device-hotplug.c
index 8b2ed7a..2bdc615 100644
--- a/hw/device-hotplug.c
+++ b/hw/device-hotplug.c
@@ -26,6 +26,9 @@
#include "boards.h"
#include "net.h"
#include "blockdev.h"
+#include "qemu-config.h"
+#include "sysemu.h"
+#include "monitor.h"
DriveInfo *add_init_drive(const char *optstr)
{
@@ -44,3 +47,47 @@ DriveInfo *add_init_drive(const char *optstr)
return dinfo;
}
+
+#if !defined(TARGET_I386)
+int pci_drive_hot_add(Monitor *mon, const QDict *qdict,
+ DriveInfo *dinfo, int type)
+{
+/* On non-x86 we don't do PCI hotplug */
+monitor_printf(mon, "Can't hot-add drive to type %d\n", type);
+return -1;
+}
+#endif
+
+void drive_hot_add(Monitor *mon, const QDict *qdict)
+{
+int type;
+DriveInfo *dinfo = NULL;
+const char *opts = qdict_get_str(qdict, "opts");
+
+dinfo = add_init_drive(opts);
+if (!dinfo) {
+goto err;
+}
+if (dinfo->devaddr) {
+monitor_printf(mon, "Parameter addr not supported\n");
+goto err;
+}
+type = dinfo->type;
+
+switch (type) {
+case IF_NONE:
+monitor_printf(mon, "OK\n");
+break;
+default:
+if (pci_drive_hot_add(mon, qdict, dinfo, type)) {
+goto err;
+}
+}
+return;
+
+err:
+if (dinfo) {
+drive_put_ref(dinfo);
+}
+return;
+}
diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c
index b59be2a..f08d367 100644
--- a/hw/pci-hotplug.c
+++ b/hw/pci-hotplug.c
@@ -103,24 +103,13 @@ static int scsi_hot_add(Monitor *mon, DeviceState
*adapter,
return 0;
}
-void drive_hot_add(Monitor *mon, const QDict *qdict)
+int pci_drive_hot_add(Monitor *mon, const QDict *qdict,
+ DriveInfo *dinfo, int type)
{
int dom, pci_bus;
unsigned slot;
-int type;
PCIDevice *dev;
-DriveInfo *dinfo = NULL;
const char *pci_addr = qdict_get_str(qdict, "pci_addr");
-const char *opts = qdict_get_str(qdict, "opts");
-
-dinfo = add_init_drive(opts);
-if (!dinfo)
-goto err;
-if (dinfo->devaddr) {
-monitor_printf(mon, "Parameter addr not supported\n");
-goto err;
-}
-type = dinfo->type;
switch (type) {
case IF_SCSI:
@@ -137,19 +126,14 @@ void drive_hot_add(Monitor *mon, const QDict *qdict)
goto err;
}
break;
-case IF_NONE:
-monitor_printf(mon, "OK\n");
-break;
default:
monitor_printf(mon, "Can't hot-add drive to type %d\n", type);
goto err;
}
-return;
+return 0;
err:
-if (dinfo)
-drive_put_ref(dinfo);
-return;
+return -1;
}
static PCIDevice *qemu_pci_hot_add_storage(Monitor *mon,
diff --git a/sysemu.h b/sysemu.h
index d3013f5..9c8e50f 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -144,9 +144,13 @@ extern unsigned int nb_prom_envs;
/* pci-hotplug */
void pci_device_hot_add(Monitor *mon, const QDict *qdict);
-void drive_hot_add(Monitor *mon, const QDict *qdict);
+int pci_drive_hot_add(Monitor *mon, const QDict *qdict,
+ DriveInfo *dinfo, int type);
void do_pci_device_hot_remove(Monitor *mon, const QDict *qdict);
+/* generic hotplug */
+void drive_hot_add(Monitor *mon, const QDict *qdict);
+
/* pcie aer error injection */
void pcie_aer_inject_error_print(Monitor *mon, const QObject *data);
int do_pcie_aer_inejct_error(Monitor *mon,
--
1.6.0.2
Re: [Qemu-devel] Possible leak in block/qcow.c
Am 18.07.2011 09:25, schrieb Frediano Ziglio: > Hi, > I noted that there are two cluster_data member in block/qcow.c, one > in BDRVQcowState, the other in QCowAIOCB. The last one is used in > qcow_aio_write_cb to hold buffer for encrypt the cluster before write > but I cannot find any related qemu_free while I can find many place > where BDRVQcowState::cluster_data is freed. It seems to me a leak but > I don't understand why nobody reported this problem before (it should > happen at every write so anybody using qcow encrypted should rapidly > see this problem). Perhaps there is a sort of garbage collector I'm > not aware? The trick is that ACBs are reused. I think they won't be freed while qemu is running, so the number of ACBs you have is the maximum number of parallel requests you had while running the VM. It's typically not a very large number. Kevin
Re: [Qemu-devel] [PATCH] USB: add usb network redirection support
p.s. For people wishing to give this a try, usbredir-0.3 needs a libusb-1.0.9 git snapshot (a 1.0.9 release is longer overdue). In the mean time grab the usbredir branch from my libusb repo and use that: http://cgit.freedesktop.org/~jwrdegoede/libusb/log/?h=usbredir Regards, Hans
[Qemu-devel] Upstream QEMU and Xen unstable not working
Bug resend.
This bug was reported about one month ago. QEMU fails to start with
Xen unstable. I found that it has not been fix with latest Xen
unstable. BIOS is Seabios (with Xen patch).
Xen-unstable a2457fc25c83872a5646c93f1e31958a2f5951e9
libxl: add LIBXL_MAC_{FMT,FMTLEN,BYTES}
Modelled after LIBXL_UUID_... (where I also add FMTLEN).
signed-off-by: Ian Campbell
Committed-by: Ian Jackson
QEMU cf973e469bd9d47c0460347764c1315a6180e13c
set ELF_HWCAP for SPARC and SPARC64
setting ELF_HWCAP fixes dynamic library loading for Linux/sparc64
This patch allows loading busybox from Debian 6 initrd
Signed-off-by: Artyom Tarasenko
Signed-off-by: Blue Swirl
These are not the problematic commits, I didn't do a regression
test. I just choose my latest commits as testing base.
Also, please note that
Xen-unstable a8f9242a7021a1febdc2ff7f8c6f6b66ee7e6745
does not trigger this bug.
Stefano and Anthony, you once said that you were going to setup a
public QEMU repository for Xen, how is it going now?
Wei.
--QEMU log--
char device redirected to /dev/pts/2
Warning: more nics requested than this machine supports; some have been ignored
qemu: hardware error: register_ioport_write: invalid opaque for address 0xc000
CPU #0:
EAX= EBX= ECX= EDX=0633
ESI= EDI= EBP= ESP=
EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=1
ES = 9300
CS =f000 9b00
SS = 9300
DS = 9300
FS = 9300
GS = 9300
LDT= 8200
TR = 8b00
GDT=
IDT=
CR0=6010 CR2= CR3= CR4=
DR0= DR1= DR2= DR3=
DR6=0ff0 DR7=0400
EFER=
FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80
FPR0= FPR1=
FPR2= FPR3=
FPR4= FPR5=
FPR6= FPR7=
XMM00= XMM01=
XMM02= XMM03=
XMM04= XMM05=
XMM06= XMM07=
--Seabios patch--
diff --git a/src/Kconfig b/src/Kconfig
index 6d55b23..6829f71 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -10,6 +10,12 @@ menu "General Features"
help
Configure as a coreboot payload.
+config XEN
+bool "Build for Xen HVM"
+default n
+help
+Configure to be used by xen hvmloader, for a HVM guest.
+
config THREADS
bool "Parallelize hardware init"
default y
diff --git a/src/shadow.c b/src/shadow.c
index ed530e0..a778701 100644
--- a/src/shadow.c
+++ b/src/shadow.c
@@ -102,7 +102,7 @@ static const struct pci_device_id
dram_controller_make_writable_tbl[] = {
void
make_bios_writable(void)
{
-if (CONFIG_COREBOOT)
+if (CONFIG_COREBOOT || CONFIG_XEN)
return;
dprintf(3, "enabling shadow ram\n");
@@ -127,7 +127,7 @@ static const struct pci_device_id
dram_controller_make_readonly_tbl[] = {
void
make_bios_readonly(void)
{
-if (CONFIG_COREBOOT)
+if (CONFIG_COREBOOT || CONFIG_XEN)
return;
dprintf(3, "locking shadow ram\n");
--Xen seabios config--
#
# Automatically generated make config: don't edit
# SeaBIOS Configuration
# Wed Apr 20 00:09:35 2011
#
#
# General Features
#
# CONFIG_COREBOOT is not set
CONFIG_XEN=y
CONFIG_THREADS=y
CONFIG_THREAD_OPTIONROMS=y
CONFIG_RELOCATE_INIT=y
CONFIG_BOOTMENU=y
CONFIG_BOOTMENU_WAIT=1000
# CONFIG_BOOTSPLASH is not set
#
# Hardware support
#
CONFIG_ATA=y
CONFIG_ATA_DMA=y
CONFIG_ATA_PIO32=y
CONFIG_AHCI=y
CONFIG_VIRTIO_BLK=y
CONFIG_FLOPPY=y
CONFIG_PS2PORT=y
CONFIG_USB=y
CONFIG_USB_UHCI=y
CONFIG_USB_OHCI=y
CONFIG_USB_EHCI=y
CONFIG_USB_MSC=y
CONFIG_USB_HUB=y
CONFIG_USB_KEYBOARD=y
CONFIG_USB_MOUSE=y
CONFIG_SERIAL=y
CONFIG_LPT=y
# CONFIG_EXTRA_PCI_ROOTS is not set
# CONFIG_USE_SMM is not set
CONFIG_MTRR_INIT=y
#
# BIOS interfaces
#
CONFIG_DRIVES=y
# CONFIG_CDROM_BOOT is not set
CONFIG_PCIBIOS=y
CONFIG_APMBIOS=y
CONFIG_PNPBIOS=y
CONFIG_OPTIONROMS=y
CONFIG_OPTIONROMS_DEPLOYED=y
CONFIG_OPTIONROMS_CHECKSUM=y
CONFIG_PMM=y
CONFIG_BOOT=y
CONFIG_KEYBOARD=y
CONFIG_KBD_CALL_INT15_4F=y
CONFIG_MOUSE=y
CONFIG_S3_RESUME=y
# CONFIG_S3_RESUME_VGA_INIT is not set
# CONFIG_DISABLE_A20 is not set
#
# BIOS Tables
#
CONFIG_PIRTABLE=y
CONFIG_MPTABLE=y
CONFIG_SMBIOS=y
CONFIG_ACPI=y
#
# Debugging
#
CONFIG_DEBUG_LEVEL=9
CONFIG_DEBUG_SERIAL=y
# CONFIG_SCREEN_AND_DEBUG is not set
Re: [Qemu-devel] [Xen-devel] Upstream QEMU and Xen unstable not working
On Mon, 2011-07-18 at 10:51 +0100, Wei Liu wrote:
> Bug resend.
>
> This bug was reported about one month ago. QEMU fails to start with
> Xen unstable. I found that it has not been fix with latest Xen
> unstable. BIOS is Seabios (with Xen patch).
Please use current mainline seabios.git -- it does not require any
additional patches.
http://wiki.xensource.com/xenwiki/QEMUUpstream also includes an updated
SeaBIOS .config which you might try.
Ian.
>
> Xen-unstable a2457fc25c83872a5646c93f1e31958a2f5951e9
> libxl: add LIBXL_MAC_{FMT,FMTLEN,BYTES}
>
> Modelled after LIBXL_UUID_... (where I also add FMTLEN).
>
> signed-off-by: Ian Campbell
> Committed-by: Ian Jackson
>
> QEMU cf973e469bd9d47c0460347764c1315a6180e13c
> set ELF_HWCAP for SPARC and SPARC64
>
> setting ELF_HWCAP fixes dynamic library loading for Linux/sparc64
> This patch allows loading busybox from Debian 6 initrd
>
> Signed-off-by: Artyom Tarasenko
> Signed-off-by: Blue Swirl
>
>
> These are not the problematic commits, I didn't do a regression
> test. I just choose my latest commits as testing base.
>
> Also, please note that
> Xen-unstable a8f9242a7021a1febdc2ff7f8c6f6b66ee7e6745
> does not trigger this bug.
>
> Stefano and Anthony, you once said that you were going to setup a
> public QEMU repository for Xen, how is it going now?
>
> Wei.
>
> --QEMU log--
>
> char device redirected to /dev/pts/2
> Warning: more nics requested than this machine supports; some have been
> ignored
> qemu: hardware error: register_ioport_write: invalid opaque for address 0xc000
> CPU #0:
> EAX= EBX= ECX= EDX=0633
> ESI= EDI= EBP= ESP=
> EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=1
> ES = 9300
> CS =f000 9b00
> SS = 9300
> DS = 9300
> FS = 9300
> GS = 9300
> LDT= 8200
> TR = 8b00
> GDT=
> IDT=
> CR0=6010 CR2= CR3= CR4=
> DR0= DR1= DR2= DR3=
> DR6=0ff0 DR7=0400
> EFER=
> FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80
> FPR0= FPR1=
> FPR2= FPR3=
> FPR4= FPR5=
> FPR6= FPR7=
> XMM00= XMM01=
> XMM02= XMM03=
> XMM04= XMM05=
> XMM06= XMM07=
>
> --Seabios patch--
> diff --git a/src/Kconfig b/src/Kconfig
> index 6d55b23..6829f71 100644
> --- a/src/Kconfig
> +++ b/src/Kconfig
> @@ -10,6 +10,12 @@ menu "General Features"
> help
> Configure as a coreboot payload.
>
> +config XEN
> +bool "Build for Xen HVM"
> +default n
> +help
> +Configure to be used by xen hvmloader, for a HVM guest.
> +
> config THREADS
> bool "Parallelize hardware init"
> default y
> diff --git a/src/shadow.c b/src/shadow.c
> index ed530e0..a778701 100644
> --- a/src/shadow.c
> +++ b/src/shadow.c
> @@ -102,7 +102,7 @@ static const struct pci_device_id
> dram_controller_make_writable_tbl[] = {
> void
> make_bios_writable(void)
> {
> -if (CONFIG_COREBOOT)
> +if (CONFIG_COREBOOT || CONFIG_XEN)
> return;
>
> dprintf(3, "enabling shadow ram\n");
> @@ -127,7 +127,7 @@ static const struct pci_device_id
> dram_controller_make_readonly_tbl[] = {
> void
> make_bios_readonly(void)
> {
> -if (CONFIG_COREBOOT)
> +if (CONFIG_COREBOOT || CONFIG_XEN)
> return;
>
> dprintf(3, "locking shadow ram\n");
>
> --Xen seabios config--
> #
> # Automatically generated make config: don't edit
> # SeaBIOS Configuration
> # Wed Apr 20 00:09:35 2011
> #
>
> #
> # General Features
> #
> # CONFIG_COREBOOT is not set
> CONFIG_XEN=y
> CONFIG_THREADS=y
> CONFIG_THREAD_OPTIONROMS=y
> CONFIG_RELOCATE_INIT=y
> CONFIG_BOOTMENU=y
> CONFIG_BOOTMENU_WAIT=1000
> # CONFIG_BOOTSPLASH is not set
>
> #
> # Hardware support
> #
> CONFIG_ATA=y
> CONFIG_ATA_DMA=y
> CONFIG_ATA_PIO32=y
> CONFIG_AHCI=y
> CONFIG_VIRTIO_BLK=y
> CONFIG_FLOPPY=y
> CONFIG_PS2PORT=y
> CONFIG_USB=y
> CONFIG_USB_UHCI=y
> CONFIG_USB_OHCI=y
> CONFIG_USB_EHCI=y
> CONFIG_USB_MSC=y
> CONFIG_USB_HUB=y
> CONFIG_USB_KEYBOARD=y
> CONFIG_USB_MOUSE=y
> CONFIG_SERIAL=y
> CONFIG_LPT=y
> # CONFIG_EXTRA_PCI_ROOTS is not set
> # CONFIG_USE_SMM is not set
> CONFIG_MTRR_INIT=y
>
> #
> # BIOS interfaces
> #
> CONFIG_DRIVES=y
> # CONFIG_CDROM_BOOT is not se
[Qemu-devel] [Bug 807893] Re: qemu privilege escalation
Here's some reproduction code you can use to see the difference between
glibc and raw system calls:
https://gist.github.com/1084042
If you're wondering about Linux and non-glibc distributions using qemu,
Alpine is one particular answer to that question (so the affected Linux
distributions is non-zero).
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/807893
Title:
qemu privilege escalation
Status in QEMU:
Confirmed
Bug description:
If qemu is started as root, with -runas, the extra groups is not
dropped correctly
/proc/`pidof qemu`/status
..
Uid:100 100 100 100
Gid:100 100 100 100
FDSize: 32
Groups: 0 1 2 3 4 6 10 11 26 27
...
The fix is to add initgroups() or setgroups(1, [gid]) where
appropriate to os-posix.c.
The extra gid's allow read or write access to other files (such as
/dev etc).
Emulating the qemu code:
# python
...
>>> import os
>>> os.setgid(100)
>>> os.setuid(100)
>>> os.execve("/bin/sh", [ "/bin/sh" ], os.environ)
sh-4.1$ xxd /dev/sda | head -n2
000: eb48 9000 .H..
010:
sh-4.1$ ls -l /dev/sda
brw-rw 1 root disk 8, 0 Jul 8 11:54 /dev/sda
sh-4.1$ id
uid=100(qemu00) gid=100(users)
groups=100(users),0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),26(tape),27(video)
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/807893/+subscriptions
Re: [Qemu-devel] [PATCH] linux-user/signal.c: Rename s390 target_ucontext fields to fix ia64
On 12.07.2011, at 22:27, Peter Maydell wrote: > The ia64 sys/ucontext.h defines macros 'uc_link', 'uc_sigmask' and > 'uc_stack'. Rename the s390 target_ucontext struct members to tuc_*, > bringing them into line with the other targets and fixing a compile > failure on ia64 hosts caused by this clash. Looks good to me. Riku, are you taking this into your linux-user tree? Alex
Re: [Qemu-devel] [PATCH] linux-user/signal.c: Rename s390 target_ucontext fields to fix ia64
On 07/18/2011 01:18 PM, Alexander Graf wrote: The ia64 sys/ucontext.h defines macros 'uc_link', 'uc_sigmask' and 'uc_stack'. Rename the s390 target_ucontext struct members to tuc_*, bringing them into line with the other targets and fixing a compile failure on ia64 hosts caused by this clash. Looks good to me. Riku, are you taking this into your linux-user tree? Already included in the pull request I sent earlier today. Riku
Re: [Qemu-devel] [PATCH] linux-user/signal.c: Rename s390 target_ucontext fields to fix ia64
On 18.07.2011, at 12:28, riku voipio wrote: > On 07/18/2011 01:18 PM, Alexander Graf wrote: >>> The ia64 sys/ucontext.h defines macros 'uc_link', 'uc_sigmask' and >>> 'uc_stack'. Rename the s390 target_ucontext struct members to tuc_*, >>> bringing them into line with the other targets and fixing a compile >>> failure on ia64 hosts caused by this clash. > >> Looks good to me. Riku, are you taking this into your linux-user tree? > > Already included in the pull request I sent earlier today. Ah, must have missed it. Thanks! Alex
[Qemu-devel] [PATCH] user: Restore debug usage message for '-d ?' in user mode emulation
The code which prints the debug usage message on '-d ?' for *-user
has to come before the check for "not enough arguments", so that
"qemu-foo -d ?" prints the list of possible debug log items rather than
the generic usage message. (This was inadvertently broken in commit
c235d73.)
Signed-off-by: Peter Maydell
---
NB that I've tested the linux-user part of this fix but don't have access to
bsd/darwin to test those files; however the change is identical for all three
files so it should be OK...
bsd-user/main.c|8 +---
darwin-user/main.c |8 +---
linux-user/main.c | 11 ++-
3 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/bsd-user/main.c b/bsd-user/main.c
index 6018a41..a63b877 100644
--- a/bsd-user/main.c
+++ b/bsd-user/main.c
@@ -856,9 +856,6 @@ int main(int argc, char **argv)
usage();
}
}
-if (optind >= argc)
-usage();
-filename = argv[optind];
/* init debug */
cpu_set_log_filename(log_file);
@@ -877,6 +874,11 @@ int main(int argc, char **argv)
cpu_set_log(mask);
}
+if (optind >= argc) {
+usage();
+}
+filename = argv[optind];
+
/* Zero out regs */
memset(regs, 0, sizeof(struct target_pt_regs));
diff --git a/darwin-user/main.c b/darwin-user/main.c
index 35196a1..72307ad 100644
--- a/darwin-user/main.c
+++ b/darwin-user/main.c
@@ -809,9 +809,6 @@ int main(int argc, char **argv)
usage();
}
}
-if (optind >= argc)
-usage();
-filename = argv[optind];
/* init debug */
cpu_set_log_filename(log_file);
@@ -830,6 +827,11 @@ int main(int argc, char **argv)
cpu_set_log(mask);
}
+if (optind >= argc) {
+usage();
+}
+filename = argv[optind];
+
/* Zero out regs */
memset(regs, 0, sizeof(struct target_pt_regs));
diff --git a/linux-user/main.c b/linux-user/main.c
index 289054b..8976b60 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -3019,11 +3019,6 @@ int main(int argc, char **argv, char **envp)
usage();
}
}
-if (optind >= argc)
-usage();
-filename = argv[optind];
-exec_path = argv[optind];
-
/* init debug */
cpu_set_log_filename(log_file);
if (log_mask) {
@@ -3041,6 +3036,12 @@ int main(int argc, char **argv, char **envp)
cpu_set_log(mask);
}
+if (optind >= argc) {
+usage();
+}
+filename = argv[optind];
+exec_path = argv[optind];
+
/* Zero out regs */
memset(regs, 0, sizeof(struct target_pt_regs));
--
1.7.1
Re: [Qemu-devel] [Xen-devel] Re: [PATCH 4/5] xen: Fix the memory registration to reflect of what is done by Xen.
On Fri, 15 Jul 2011, Anthony PERARD wrote: > On Fri, Jul 15, 2011 at 18:05, Stefano Stabellini > wrote: > > Shouldn't we avoid registering any memory for the whole video ram area? > > I mean: > > > > 0xa - 0x10 > > No, because SeaBIOS load the Options ROM (VGA Bios, PXE) to the area > between 0xc and 0x10, and this go through QEMU. > > The area between 0xa and 0xc is registred later by the > cirrus_vga bits, as IO. OK. Can you please expand your comment in the code with the same explanation?
Re: [Qemu-devel] error "kvm: virtio: trying to map MMIO memory"
2011/7/17 Stéphanie Ouillon : > I have been facing a problem for 3-4 days with my virtio network device > driver in qemu: when I load the driver, I get the following error: > kvm: virtio: trying to map MMIO memory [...] > Would anybody have a clue about what kind of bug would provoke this error in > qemu ? It means a descriptor has an addr field that is not a bus address backed by RAM. Instead the incorrect address is to a MMIO memory region. Normally all buffers that you pass via virtio are guest physical RAM addresses, hardware mapped registers (MMIO) should not be passed over virtio and there's usually really no reason to do that. This suggests you are setting an incorrect address in the guest driver or are forgetting to set the address field thereby causing a stale value to be read by QEMU. I suggest adding the following to qemu/hw/virtio.c:virtqueue_map_sg() right before the if statement that checks for failed memory map: fprintf(stderr, "addr " TARGET_FMT_plx " len " TARGET_FMT_plx " is_write %d\n", addr[i], len, is_write); Compare the addresses that QEMU is seeing with those you have given to virtio in the guest kernel. It should be possible to correlate the buffers that the guest wants to give the host with what QEMU sees. Let us know if you need any more help debugging. Stefan
Re: [Qemu-devel] [PATCH v3] xen: implement unplug protocol in xen_platform
On 15.07.2011, at 12:52, Kevin Wolf wrote:
> Am 15.07.2011 12:34, schrieb Stefano Stabellini:
>> On Fri, 1 Jul 2011, Stefano Stabellini wrote:
>>> On Fri, 1 Jul 2011, Kevin Wolf wrote:
Am 30.06.2011 16:16, schrieb Stefano Stabellini:
> On Thu, 30 Jun 2011, Kevin Wolf wrote:
>>> +static int pci_piix3_xen_ide_unplug(DeviceState *dev)
>>> +{
>>> +PCIDevice *pci_dev;
>>> +PCIIDEState *pci_ide;
>>> +DriveInfo *di;
>>> +int i = 0;
>>> +
>>> +pci_dev = DO_UPCAST(PCIDevice, qdev, dev);
>>> +pci_ide = DO_UPCAST(PCIIDEState, dev, pci_dev);
>>> +
>>> +for (; i < 3; i++) {
>>> +di = drive_get_by_index(IF_IDE, i);
>>> +if (di != NULL && di->bdrv != NULL && !di->bdrv->removable) {
>>> +DeviceState *ds = bdrv_get_attached(di->bdrv);
>>> +if (ds) {
>>> +bdrv_detach(di->bdrv, ds);
>>> +}
>>> +bdrv_close(di->bdrv);
>>> +pci_ide->bus[di->bus].ifs[di->unit].bs = NULL;
>>
>> Have you tested if this is enough if the guest tries to continue using
>> the device? I don't know of any case where it's not sufficient, just
>> trying to make sure that it's really true in practice.
>
> The purpose of this is to "hide" the disk from the guest. The unplug is
> supposed to happen *before* the guest enumerates the IDE disks; it is
> responsibility of the guest to make sure of it.
> I tested it with Linux PV on HVM drivers, and Linux doesn't see the
> emulated disk after the unplug, as it should be.
Yeah. What I meant is that we should make sure that a misbehaving guest,
which just keeps on playing with the IDE ports anyway, can't crash qemu.
A quick review suggests that it is the case, but testing it anyway would
be better.
>>>
>>> I see what you mean: I tested it, a guest cannot crash Qemu.
>>>
>>
>> ping?
>
> I thought Alex had already merged it. I'm pretty sure that I stated
> somewhere that the patch is okay for me now. In case I didn't:
>
> Acked-by: Kevin Wolf
Ah, must have missed it :). Thanks.
Stefano, could you please rebase? The patch doesn't apply cleanly anymore.
Alex
Re: [Qemu-devel] [PATCH] checkpatch: Fix bracing false positives on #if
On Sun, Jul 17, 2011 at 9:48 AM, Blue Swirl wrote:
> 789f88d0b21fedfd4251d56bb7a9fbfbda7a4ac7 only fixed #else,
> fix also #if.
>
> Signed-off-by: Blue Swirl
> ---
> scripts/checkpatch.pl | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 075b614..9bc867f 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -2537,6 +2537,7 @@ sub process {
> }
> if (!defined $suppress_ifbraces{$linenr - 1} &&
> $line =~ /\b(if|while|for|else)\b/ &&
> + $line !~ /\#\s*if/ &&
> $line !~ /\#\s*else/) {
> my $allowed = 0;
>
> --
> 1.6.2.4
Reviewed-by: Stefan Hajnoczi
Re: [Qemu-devel] [PATCH 0/5] Enable QEMU to handle more than 2GB with Xen.
On 15.07.2011, at 19:05, Stefano Stabellini wrote: > On Fri, 15 Jul 2011, Anthony PERARD wrote: >> Hi all, >> >> Xen is not limited by the QEMU's virtual address space for the allocation of >> the guest RAM. So even with a QEMU 32bits, a Xen guest can have more than 4 >> GB >> of RAM. >> >> With this serie, we will be able to run a guest with more than 4GB. The main >> point is to change ram_addr_t from ulong to uin64 when QEMU is configure with >> Xen. The second point is better register the memory in QEMU. >> >> Regards, >> >> >> Anthony PERARD (5): >> xen: Fix xen_enabled(). >> exec.c: Use ram_addr_t in cpu_physical_memory_rw(...). >> cpu-common: Have a ram_addr_t of uint64 with Xen. >> xen: Fix the memory registration to reflect of what is done by Xen. >> vl.c: Check the asked ram_size later. >> >> cpu-common.h |8 >> exec.c | 13 +++-- >> hw/xen.h |2 +- >> vl.c | 14 -- >> xen-all.c| 23 +++ >> 5 files changed, 39 insertions(+), 21 deletions(-) > > All the patches look good to me, just a comment on the 4th patch. I included patches 1 and 2 in xen-next. 3 and 4 are in discussion and 5 should only be applied when the others are in :) Alex
Re: [Qemu-devel] [PATCH 1/5] xen: Fix xen_enabled().
On 15.07.2011, at 16:32, Anthony Perard wrote:
> Use the "host" CONFIG_ define instead of the "target" one.
>
> Signed-off-by: Anthony PERARD
> ---
> hw/xen.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/hw/xen.h b/hw/xen.h
> index e432705..43b95d6 100644
> --- a/hw/xen.h
> +++ b/hw/xen.h
> @@ -24,7 +24,7 @@ extern int xen_allowed;
>
> static inline int xen_enabled(void)
> {
> -#ifdef CONFIG_XEN
> +#ifdef CONFIG_XEN_BACKEND
is there any way to get this one more clever? The current patch fixes it for
your use case, sure, but I'd prefer that if you do:
./configure --enable-xen --target-list=alpha-softmmu
I'll get xen_enabled to be inline exterminated and not slow down the alpha
target. How about something like
#ifdef CONFIG_NO_XEN
return 0;
#elif defined(CONFIG_XEN_BACKEND)
return xen_allowed;
#else
return 0;
#endif
That way code that is compiled per-target won't get slowed down just because we
have the xen option on.
Alex
Re: [Qemu-devel] [PATCH 3/5] cpu-common: Have a ram_addr_t of uint64 with Xen.
On 15.07.2011, at 16:32, Anthony Perard wrote:
> In Xen case, memory can be bigger than the host memory. that mean a
> 32bits host (and QEMU) should be able to handle a RAM address of 64bits.
>
> Signed-off-by: Anthony PERARD
> ---
> cpu-common.h |8
> exec.c |9 +
> xen-all.c|2 +-
> 3 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/cpu-common.h b/cpu-common.h
> index e4fcded..e1b40fe 100644
> --- a/cpu-common.h
> +++ b/cpu-common.h
> @@ -27,7 +27,15 @@ enum device_endian {
> };
>
> /* address in the RAM (different from a physical address) */
> +#ifndef CONFIG_XEN_BACKEND
> typedef unsigned long ram_addr_t;
Do we really want to depend this on _BACKEND? ram_addr_t is target dependent,
no?
Alex
[Qemu-devel] [PATCH 0/3] Random xen patches
While applying some of the outstanding patches from the masses of Xen patches on the mailing list, I stumbled over a few things and wrote up patches to fix them. Functionally, nothing should change with these applied, but I want to give people the chance to review them before pushing them :). Alexander Graf (3): xen: add mapcache stubs xen: remove CONFIG_XEN_MAPCACHE xen: make xen_enabled even more clever configure |8 +--- hw/xen.h |2 +- xen-stub.c | 26 ++ 3 files changed, 32 insertions(+), 4 deletions(-)
[Qemu-devel] [PATCH 3/3] xen: make xen_enabled even more clever
When using xen_enabled() we're currently only checking if xen is enabled
at all during the build. But what if you want to build multiple targets
out of which only one can potentially run xen code?
That means that for generic code we'll still have to fall back to the
variable and potentially slow the code down, but it's not as important as
that is mostly xen device emulation which is not touched for non-xen targets.
The target specific code however can with this patch see that it's unable to
ever execute xen code. We can thus always return 0 on xen_enabled(), giving
gcc enough hints to evict the mapcache code from the target memory management
code.
Signed-off-by: Alexander Graf
---
configure |5 +
hw/xen.h |2 +-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index f537130..f79b23b 100755
--- a/configure
+++ b/configure
@@ -3235,7 +3235,12 @@ case "$target_arch2" in
if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
target_phys_bits=64
echo "CONFIG_XEN=y" >> $config_target_mak
+else
+ echo "CONFIG_NO_XEN=y" >> $config_target_mak
fi
+;;
+ *)
+echo "CONFIG_NO_XEN=y" >> $config_target_mak
esac
case "$target_arch2" in
i386|x86_64|ppcemb|ppc|ppc64|s390x)
diff --git a/hw/xen.h b/hw/xen.h
index 43b95d6..2162111 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -24,7 +24,7 @@ extern int xen_allowed;
static inline int xen_enabled(void)
{
-#ifdef CONFIG_XEN_BACKEND
+#if defined(CONFIG_XEN_BACKEND) && !defined(CONFIG_NO_XEN)
return xen_allowed;
#else
return 0;
--
1.6.0.2
[Qemu-devel] [PATCH 2/3] xen: remove CONFIG_XEN_MAPCACHE
We were still exporting CONFIG_XEN_MAPCACHE, even though it's completely unused by now. Remove it. Signed-off-by: Alexander Graf --- configure |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/configure b/configure index e57efb1..f537130 100755 --- a/configure +++ b/configure @@ -3235,9 +3235,6 @@ case "$target_arch2" in if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then target_phys_bits=64 echo "CONFIG_XEN=y" >> $config_target_mak - if test "$cpu" = "i386" -o "$cpu" = "x86_64"; then - echo "CONFIG_XEN_MAPCACHE=y" >> $config_target_mak - fi fi esac case "$target_arch2" in -- 1.6.0.2
Re: [Qemu-devel] [PATCH v6 0/5] Coroutines for better asynchronous programming
On Sat, Jul 16, 2011 at 11:08 AM, Blue Swirl wrote: > On Mon, Jun 27, 2011 at 12:21 PM, Stefan Hajnoczi wrote: >> Here is the latest version of the coroutine series with Mac OS X fixes from >> Andreas Färber . >> >> QEMU is event-driven and suffers when blocking operations are performed >> because >> VM execution may be stopped until the operation completes. Therefore many >> operations that could block are performed asynchronously and a callback is >> invoked when the operation has completed. This allows QEMU to continue >> executing while the operation is pending. >> >> The downside to callbacks is that they split up code into many smaller >> functions, each of which is a single step in a state machine that quickly >> becomes complex and hard to understand. Callback functions also result in >> lots >> of noise as variables are packed and unpacked into temporary structs that >> pass >> state to the callback function. >> >> This patch series introduces coroutines as a solution for writing >> asynchronous >> code while still having a nice sequential control flow. The semantics are >> explained in the second patch. The fourth patch adds automated tests. >> >> A nice feature of coroutines is that it is relatively easy to take >> synchronous >> code and lift it into a coroutine to make it asynchronous. Work has been >> done >> to move qcow2 request processing into coroutines and thereby make it >> asynchronous (today qcow2 will perform synchronous metadata accesses). This >> qcow2 work is still ongoing and not quite ready for mainline yet. >> >> Coroutines are also being used for virtfs (virtio-9p) so I have submitted >> this >> patch now because virtfs patches that depend on coroutines are being >> published. > > Coroutines seem to work fine on OpenBSD (Sparc64, also tests are > passed) and mingw32, with a few minor issues. > > With simpletrace enabled there is a link failure: > $ make test-coroutine > LINK test-coroutine > simpletrace.o: In function `get_clock': > /src/qemu/qemu-timer.h:117: undefined reference to `use_rt_clock' > > This can be fixed for example by adding qemu-timer-common.o to the > list of linked objects. Do you want me to send a patch to add qemu-timer-common.o or is this easy to do while merging? > I can't compile coroutine tests for Mingw32 because of this: > $ make test-coroutine > CC test-coroutine.o > In file included from > /usr/local/i686-mingw32msvc/include/glib-2.0/glib/galloca.h:30:0, > from /usr/local/i686-mingw32msvc/include/glib-2.0/glib.h:30, > from /src/qemu/test-coroutine.c:14: > /usr/local/i686-mingw32msvc/include/glib-2.0/glib/gtypes.h:30:24: > fatal error: glibconfig.h: No such file or directory > > I used glib win32 zips from > http://ftp.gnome.org/pub/gnome/binaries/win32/glib/2.12/, is there a > better site? Otherwise QEMU builds fine and runs under Wine nicely. Paolo, Stefan Weil: Any ideas regarding w32 glib headers above? Stefan
[Qemu-devel] [PATCH 1/3] xen: add mapcache stubs
During the transition to get rid of CONFIG_XEN_MAPCACHE we lost the mapcache
stubs along the way. Nobody realized it because the commands were guarded by
if (xen_enabled()) clauses that made gcc optimize out the respective calls.
This patch adds the stubs again - this time in the generic xen-stubs.c
Signed-off-by: Alexander Graf
---
xen-stub.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/xen-stub.c b/xen-stub.c
index efe2ab5..76d80e9 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -8,6 +8,7 @@
#include "qemu-common.h"
#include "hw/xen.h"
+#include "xen-mapcache.h"
void xenstore_store_pv_console_info(int i, CharDriverState *chr)
{
@@ -43,3 +44,28 @@ int xen_init(void)
{
return -ENOSYS;
}
+
+/*** mapcache stubs ***/
+
+void xen_map_cache_init(void)
+{
+}
+
+uint8_t *xen_map_cache(target_phys_addr_t phys_addr, target_phys_addr_t size,
+ uint8_t lock)
+{
+return qemu_get_ram_ptr(phys_addr);
+}
+
+ram_addr_t xen_ram_addr_from_mapcache(void *ptr)
+{
+return -1;
+}
+
+void xen_invalidate_map_cache(void)
+{
+}
+
+void xen_invalidate_map_cache_entry(uint8_t *buffer)
+{
+}
--
1.6.0.2
Re: [Qemu-devel] [PATCH V3] e1000: Handle IO Port.
On Sat, Jul 2, 2011 at 18:35, Andreas Färber wrote:
> Am 30.06.2011 um 23:35 schrieb Anthony PERARD:
>
>> This patch introduces the two IOPorts on e1000, IOADDR and IODATA. The
>> IOADDR is used to specify which register we want to access when we read
>> or write on IODATA.
>>
>> This patch fixes some weird behavior that I see when I use e1000 with
>> QEMU/Xen, the guest memory can be corrupted by this NIC because it will
>> write on memory that it doesn't own anymore after a reset. It's because
>> the kernel Linux use the IOPort to reset the network card instead of the
>> MMIO.
>>
>> Signed-off-by: Anthony PERARD
>> ---
>
>> diff --git a/hw/e1000.c b/hw/e1000.c
>> index 96d84f9..bd39d80 100644
>> --- a/hw/e1000.c
>> +++ b/hw/e1000.c
>
>> @@ -971,7 +1006,7 @@ static bool is_version_1(void *opaque, int
>> version_id)
>>
>> static const VMStateDescription vmstate_e1000 = {
>> .name = "e1000",
>> - .version_id = 2,
>> + .version_id = 3,
>> .minimum_version_id = 1,
>> .minimum_version_id_old = 1,
>> .fields = (VMStateField []) {
>> @@ -1043,6 +1078,7 @@ static const VMStateDescription vmstate_e1000 = {
>> VMSTATE_UINT32_SUB_ARRAY(mac_reg, E1000State, RA, 32),
>> VMSTATE_UINT32_SUB_ARRAY(mac_reg, E1000State, MTA, 128),
>> VMSTATE_UINT32_SUB_ARRAY(mac_reg, E1000State, VFTA, 128),
>> + VMSTATE_UINT32_V(ioport_addr, E1000State, 3),
>> VMSTATE_END_OF_LIST()
>> }
>> };
>
> Juan, shouldn't this use a subsection instead of bumping the version?
>
> Andreas
>
>
Ping?
--
Anthony PERARD
Re: [Qemu-devel] [PATCH 3/3] xen: make xen_enabled even more clever
On Sun, Jul 17, 2011 at 06:39, Alexander Graf wrote:
> When using xen_enabled() we're currently only checking if xen is enabled
> at all during the build. But what if you want to build multiple targets
> out of which only one can potentially run xen code?
>
> That means that for generic code we'll still have to fall back to the
> variable and potentially slow the code down, but it's not as important as
> that is mostly xen device emulation which is not touched for non-xen targets.
>
> The target specific code however can with this patch see that it's unable to
> ever execute xen code. We can thus always return 0 on xen_enabled(), giving
> gcc enough hints to evict the mapcache code from the target memory management
> code.
>
> Signed-off-by: Alexander Graf
> ---
> configure | 5 +
> hw/xen.h | 2 +-
> 2 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/configure b/configure
> index f537130..f79b23b 100755
> --- a/configure
> +++ b/configure
> @@ -3235,7 +3235,12 @@ case "$target_arch2" in
> if test "$xen" = "yes" -a "$target_softmmu" = "yes" ; then
> target_phys_bits=64
> echo "CONFIG_XEN=y" >> $config_target_mak
> + else
> + echo "CONFIG_NO_XEN=y" >> $config_target_mak
> fi
> + ;;
> + *)
> + echo "CONFIG_NO_XEN=y" >> $config_target_mak
> esac
> case "$target_arch2" in
> i386|x86_64|ppcemb|ppc|ppc64|s390x)
> diff --git a/hw/xen.h b/hw/xen.h
> index 43b95d6..2162111 100644
> --- a/hw/xen.h
> +++ b/hw/xen.h
> @@ -24,7 +24,7 @@ extern int xen_allowed;
>
> static inline int xen_enabled(void)
> {
> -#ifdef CONFIG_XEN_BACKEND
> +#if defined(CONFIG_XEN_BACKEND) && !defined(CONFIG_NO_XEN)
> return xen_allowed;
> #else
> return 0;
Cool, better than my fix.
Acked-by: Anthony PERARD
--
Anthony PERARD
Re: [Qemu-devel] live snapshot wiki updated
On Fri, Jul 15, 2011 at 3:58 PM, Jes Sorensen wrote: > I have been updating the live snapshot wiki for qemu to try and cover > the commands we will want for async snapshot handling too. > > http://wiki.qemu.org/Features/Snapshots Regarding fd passing, do we even support SELinux today with backing files? Stefan
Re: [Qemu-devel] [PATCH] USB: add usb network redirection support
On 07/18/11 09:13, Hans de Goede wrote: This patch adds support for a usb-redir device, which takes a chardev as a communication channel to an actual usbdevice using the usbredir protocol. Compiling the usb-redir device requires usbredir-0.3 to be installed for the usbredir protocol parser, usbredir-0.3 also contains a server for redirecting usb traffic from an actual usb device. You can get the 0.3 release of usbredir here: http://people.fedoraproject.org/~jwrdegoede/usbredir-0.3.tar.bz2 (getting a more formal site for it is a WIP) Looks good overall. scripts/checkpatch.pl has a bunch of codestyle complains which need to be fixed. cheers, Gerd
Re: [Qemu-devel] [Xen-devel] Re: [PATCH 3/5] cpu-common: Have a ram_addr_t of uint64 with Xen.
On Mon, Jul 18, 2011 at 13:30, Alexander Graf wrote:
>
> On 15.07.2011, at 16:32, Anthony Perard wrote:
>
>> In Xen case, memory can be bigger than the host memory. that mean a
>> 32bits host (and QEMU) should be able to handle a RAM address of 64bits.
>>
>> Signed-off-by: Anthony PERARD
>> ---
>> cpu-common.h | 8
>> exec.c | 9 +
>> xen-all.c | 2 +-
>> 3 files changed, 14 insertions(+), 5 deletions(-)
>>
>> diff --git a/cpu-common.h b/cpu-common.h
>> index e4fcded..e1b40fe 100644
>> --- a/cpu-common.h
>> +++ b/cpu-common.h
>> @@ -27,7 +27,15 @@ enum device_endian {
>> };
>>
>> /* address in the RAM (different from a physical address) */
>> +#ifndef CONFIG_XEN_BACKEND
>> typedef unsigned long ram_addr_t;
>
> Do we really want to depend this on _BACKEND? ram_addr_t is target dependent,
> no?
:(, indeed, it's seams to be target dependent, I did not check that
carefully enough. So CONFIG_XEN is enough.
Thanks,
--
Anthony PERARD
Re: [Qemu-devel] [PATCH v9 00/12] Adding VMDK monolithic flat support
Am 12.07.2011 13:56, schrieb Fam Zheng:
> Changes from v8:
> 09/12: remove duplicated sscanf
> 10/12: change option name to 'subformat', change commit message typo,
> factor common parts of creating, and other small improvements
>
> Fam Zheng (12):
> VMDK: introduce VmdkExtent
> VMDK: bugfix, align offset to cluster in get_whole_cluster
> VMDK: probe for monolithicFlat images
> VMDK: separate vmdk_open by format version
> VMDK: add field BDRVVmdkState.desc_offset
> VMDK: flush multiple extents
> VMDK: move 'static' cid_update flag to bs field
> VMDK: change get_cluster_offset return type
> VMDK: open/read/write for monolithicFlat image
> VMDK: create different subformats
> VMDK: fix coding style
> block: add bdrv_get_allocated_file_size() operation
>
> block.c | 19 +
> block.h |1 +
> block/raw-posix.c | 21 +
> block/raw-win32.c | 29 ++
> block/vmdk.c | 1296
> -
> block_int.h |2 +
> qemu-img.c| 31 +--
> 7 files changed, 964 insertions(+), 435 deletions(-)
This doesn't build for me:
cc1: warnings being treated as errors
block/vmdk.c: In function 'vmdk_parse_extents':
block/vmdk.c:482: error: format '%lld' expects type 'long long int *',
but argument 4 has type 'int64_t *'
block/vmdk.c:482: error: format '%lld' expects type 'long long int *',
but argument 7 has type 'int64_t *'
block/vmdk.c: In function 'vmdk_create_extent':
block/vmdk.c:1024: error: invalid storage class for function
'filename_decompose'
[...]
The following patch makes it compile. I haven't tried figuring out which
patches need to be fixed, but should be easy enough for you. Please
resend only those patches that need to be changed, I have already merged
everything (plus my fixup) and will only update it in the block branch.
Kevin
diff --git a/block/vmdk.c b/block/vmdk.c
index 63d7605..37478d2 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -478,7 +478,7 @@ static int vmdk_parse_extents(const char *desc,
BlockDriverState *bs,
* RW [size in sectors] SPARSE "file-name.vmdk"
*/
flat_offset = -1;
-ret = sscanf(p, "%10s %lld %10s %511s %lld",
+ret = sscanf(p, "%10s %" SCNd64 " %10s %511s %" SCNd64,
access, §ors, type, fname, &flat_offset);
if (ret < 4 || strcmp(access, "RW")) {
goto next_line;
@@ -927,6 +927,7 @@ static int vmdk_create_extent(const char *filename,
int64_t filesize, bool flat)
0644);
if (fd < 0) {
return -errno;
+}
if (flat) {
ret = ftruncate(fd, filesize);
if (ret < 0) {
Re: [Qemu-devel] [Xen-devel] Re: [PATCH 4/5] xen: Fix the memory registration to reflect of what is done by Xen.
On Mon, Jul 18, 2011 at 12:14, Stefano Stabellini wrote: > On Fri, 15 Jul 2011, Anthony PERARD wrote: >> On Fri, Jul 15, 2011 at 18:05, Stefano Stabellini >> wrote: >> > Shouldn't we avoid registering any memory for the whole video ram area? >> > I mean: >> > >> > 0xa - 0x10 >> >> No, because SeaBIOS load the Options ROM (VGA Bios, PXE) to the area >> between 0xc and 0x10, and this go through QEMU. >> >> The area between 0xa and 0xc is registred later by the >> cirrus_vga bits, as IO. > > OK. Can you please expand your comment in the code with the same > explanation? Yes, I will do that. -- Anthony PERARD
[Qemu-devel] [PATCH 0/9] usb: replace buffers with iovecs.
Hi, This patch series introduces iovecs to the USB subsystem, usb packet payload is passed around as iovec instead of a linear buffer. This allows the host controllers to use scatter lists and to pass on data buffers directly, so we can avoid an extra copy. please review, Gerd Gerd Hoffmann (9): Add iov_hexdump() Add iov_clear() move QEMUSGList typedef usb: use iovecs in USBPacket usb-serial: iovec support usb-host: iovec support usb-storage: iovec support uhci: remove buffer ehci: iovec support, remove buffer Makefile.objs |1 + dma.h |4 +- hw/bt-hid.c| 16 +++--- hw/milkymist-softusb.c |8 +- hw/usb-bt.c| 31 -- hw/usb-ccid.c | 46 -- hw/usb-ehci.c | 160 hw/usb-hid.c |6 +- hw/usb-hub.c |8 ++- hw/usb-libhw.c | 63 +++ hw/usb-msd.c | 109 - hw/usb-musb.c | 22 +++--- hw/usb-net.c | 65 +++- hw/usb-ohci.c | 23 +++ hw/usb-serial.c| 26 +--- hw/usb-uhci.c | 51 +++ hw/usb-wacom.c |6 +- hw/usb.c | 86 + hw/usb.h | 13 +++- iov.c | 54 iov.h |4 + qemu-common.h |1 + usb-linux.c| 48 +-- 23 files changed, 500 insertions(+), 351 deletions(-) create mode 100644 hw/usb-libhw.c
[Qemu-devel] [PATCH 1/9] Add iov_hexdump()
Useful for debugging purposes.
Signed-off-by: Gerd Hoffmann
---
iov.c | 31 +++
iov.h |2 ++
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/iov.c b/iov.c
index 1e02791..60553c7 100644
--- a/iov.c
+++ b/iov.c
@@ -73,3 +73,34 @@ size_t iov_size(const struct iovec *iov, const unsigned int
iov_cnt)
}
return len;
}
+
+void iov_hexdump(const struct iovec *iov, const unsigned int iov_cnt,
+ FILE *fp, const char *prefix, size_t limit)
+{
+unsigned int i, v, b;
+uint8_t *c;
+
+c = iov[0].iov_base;
+for (i = 0, v = 0, b = 0; b < limit; i++, b++) {
+if (i == iov[v].iov_len) {
+i = 0; v++;
+if (v == iov_cnt) {
+break;
+}
+c = iov[v].iov_base;
+}
+if ((b % 16) == 0) {
+fprintf(fp, "%s: %04x:", prefix, b);
+}
+if ((b % 4) == 0) {
+fprintf(fp, " ");
+}
+fprintf(fp, " %02x", c[i]);
+if ((b % 16) == 15) {
+fprintf(fp, "\n");
+}
+}
+if ((b % 16) != 0) {
+fprintf(fp, "\n");
+}
+}
diff --git a/iov.h b/iov.h
index 110f67a..c2c5b39 100644
--- a/iov.h
+++ b/iov.h
@@ -17,3 +17,5 @@ size_t iov_from_buf(struct iovec *iov, unsigned int iov_cnt,
size_t iov_to_buf(const struct iovec *iov, const unsigned int iov_cnt,
void *buf, size_t iov_off, size_t size);
size_t iov_size(const struct iovec *iov, const unsigned int iov_cnt);
+void iov_hexdump(const struct iovec *iov, const unsigned int iov_cnt,
+ FILE *fp, const char *prefix, size_t limit);
--
1.7.1
[Qemu-devel] [PATCH 2/9] Add iov_clear()
Fill the spefified area with zeros.
Signed-off-by: Gerd Hoffmann
---
iov.c | 23 +++
iov.h |2 ++
2 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/iov.c b/iov.c
index 60553c7..e7385c4 100644
--- a/iov.c
+++ b/iov.c
@@ -62,6 +62,29 @@ size_t iov_to_buf(const struct iovec *iov, const unsigned
int iov_cnt,
return buf_off;
}
+size_t iov_clear(const struct iovec *iov, const unsigned int iov_cnt,
+ size_t iov_off, size_t size)
+{
+size_t iovec_off, buf_off;
+unsigned int i;
+
+iovec_off = 0;
+buf_off = 0;
+for (i = 0; i < iov_cnt && size; i++) {
+if (iov_off < (iovec_off + iov[i].iov_len)) {
+size_t len = MIN((iovec_off + iov[i].iov_len) - iov_off , size);
+
+memset(iov[i].iov_base + (iov_off - iovec_off), 0, len);
+
+buf_off += len;
+iov_off += len;
+size -= len;
+}
+iovec_off += iov[i].iov_len;
+}
+return buf_off;
+}
+
size_t iov_size(const struct iovec *iov, const unsigned int iov_cnt)
{
size_t len;
diff --git a/iov.h b/iov.h
index c2c5b39..94d2f78 100644
--- a/iov.h
+++ b/iov.h
@@ -17,5 +17,7 @@ size_t iov_from_buf(struct iovec *iov, unsigned int iov_cnt,
size_t iov_to_buf(const struct iovec *iov, const unsigned int iov_cnt,
void *buf, size_t iov_off, size_t size);
size_t iov_size(const struct iovec *iov, const unsigned int iov_cnt);
+size_t iov_clear(const struct iovec *iov, const unsigned int iov_cnt,
+ size_t iov_off, size_t size);
void iov_hexdump(const struct iovec *iov, const unsigned int iov_cnt,
FILE *fp, const char *prefix, size_t limit);
--
1.7.1
[Qemu-devel] [PATCH 3/9] move QEMUSGList typedef
Move the QEMUSGList typedef to qemu-common so it can easily be used.
The actual struct definition stays in dma.h.
Signed-off-by: Gerd Hoffmann
---
dma.h |4 ++--
qemu-common.h |1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/dma.h b/dma.h
index 3d8324b..a6db5ba 100644
--- a/dma.h
+++ b/dma.h
@@ -20,12 +20,12 @@ typedef struct {
target_phys_addr_t len;
} ScatterGatherEntry;
-typedef struct {
+struct QEMUSGList {
ScatterGatherEntry *sg;
int nsg;
int nalloc;
target_phys_addr_t size;
-} QEMUSGList;
+};
void qemu_sglist_init(QEMUSGList *qsg, int alloc_hint);
void qemu_sglist_add(QEMUSGList *qsg, target_phys_addr_t base,
diff --git a/qemu-common.h b/qemu-common.h
index abd7a75..565b4b6 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -284,6 +284,7 @@ typedef struct I2SCodec I2SCodec;
typedef struct SSIBus SSIBus;
typedef struct EventNotifier EventNotifier;
typedef struct VirtIODevice VirtIODevice;
+typedef struct QEMUSGList QEMUSGList;
typedef uint64_t pcibus_t;
--
1.7.1
[Qemu-devel] [PATCH 5/9] usb-serial: iovec support
Add full support for iovecs to usb-serial.
Signed-off-by: Gerd Hoffmann
---
hw/usb-serial.c | 27 ---
1 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/hw/usb-serial.c b/hw/usb-serial.c
index 4a00211..1133e8d 100644
--- a/hw/usb-serial.c
+++ b/hw/usb-serial.c
@@ -359,38 +359,42 @@ static int usb_serial_handle_control(USBDevice *dev,
USBPacket *p,
static int usb_serial_handle_data(USBDevice *dev, USBPacket *p)
{
USBSerialState *s = (USBSerialState *)dev;
-int ret = 0;
+int i, ret = 0;
uint8_t devep = p->devep;
-uint8_t *data = p->iov.iov[0].iov_base;
-int len = p->iov.iov[0].iov_len;
-int first_len;
+struct iovec *iov;
+uint8_t header[2];
+int first_len, len;
-assert(p->iov.niov == 1); /* temporary */
switch (p->pid) {
case USB_TOKEN_OUT:
if (devep != 2)
goto fail;
-qemu_chr_write(s->cs, data, len);
+for (i = 0; i < p->iov.niov; i++) {
+iov = p->iov.iov + i;
+qemu_chr_write(s->cs, iov->iov_base, iov->iov_len);
+}
break;
case USB_TOKEN_IN:
if (devep != 1)
goto fail;
first_len = RECV_BUF - s->recv_ptr;
+len = p->iov.size;
if (len <= 2) {
ret = USB_RET_NAK;
break;
}
-*data++ = usb_get_modem_lines(s) | 1;
+header[0] = usb_get_modem_lines(s) | 1;
/* We do not have the uart details */
/* handle serial break */
if (s->event_trigger && s->event_trigger & FTDI_BI) {
s->event_trigger &= ~FTDI_BI;
-*data = FTDI_BI;
+header[1] = FTDI_BI;
+usb_packet_copy(p, header, 2);
ret = 2;
break;
} else {
-*data++ = 0;
+header[1] = 0;
}
len -= 2;
if (len > s->recv_used)
@@ -401,9 +405,10 @@ static int usb_serial_handle_data(USBDevice *dev,
USBPacket *p)
}
if (first_len > len)
first_len = len;
-memcpy(data, s->recv_buf + s->recv_ptr, first_len);
+usb_packet_copy(p, header, 2);
+usb_packet_copy(p, s->recv_buf + s->recv_ptr, first_len);
if (len > first_len)
-memcpy(data + first_len, s->recv_buf, len - first_len);
+usb_packet_copy(p, s->recv_buf, len - first_len);
s->recv_used -= len;
s->recv_ptr = (s->recv_ptr + len) % RECV_BUF;
ret = len + 2;
--
1.7.1
[Qemu-devel] [PATCH 6/9] usb-host: iovec support
Add full support for iovecs to usb-host. The code can split large
transfers into smaller ones already, we are using this to also split
requests at iovec borders.
Signed-off-by: Gerd Hoffmann
---
usb-linux.c | 27 ++-
1 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index 83ebf6e..536d93c 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -707,7 +707,7 @@ static int usb_host_handle_data(USBDevice *dev, USBPacket
*p)
USBHostDevice *s = DO_UPCAST(USBHostDevice, dev, dev);
struct usbdevfs_urb *urb;
AsyncURB *aurb;
-int ret, rem;
+int ret, rem, prem, v;
uint8_t *pbuf;
uint8_t ep;
@@ -735,10 +735,18 @@ static int usb_host_handle_data(USBDevice *dev, USBPacket
*p)
return usb_host_handle_iso_data(s, p, p->pid == USB_TOKEN_IN);
}
-assert(p->iov.niov == 1); /* temporary */
-rem = p->iov.iov[0].iov_len;
-pbuf = p->iov.iov[0].iov_base;
+v = 0;
+prem = p->iov.iov[v].iov_len;
+pbuf = p->iov.iov[v].iov_base;
+rem = p->iov.size;
while (rem) {
+if (prem == 0) {
+v++;
+assert(v < p->iov.niov);
+prem = p->iov.iov[v].iov_len;
+pbuf = p->iov.iov[v].iov_base;
+assert(prem <= rem);
+}
aurb = async_alloc(s);
aurb->packet = p;
@@ -747,16 +755,17 @@ static int usb_host_handle_data(USBDevice *dev, USBPacket
*p)
urb->type = USBDEVFS_URB_TYPE_BULK;
urb->usercontext = s;
urb->buffer= pbuf;
+urb->buffer_length = prem;
-if (rem > MAX_USBFS_BUFFER_SIZE) {
+if (urb->buffer_length > MAX_USBFS_BUFFER_SIZE) {
urb->buffer_length = MAX_USBFS_BUFFER_SIZE;
-aurb->more = 1;
-} else {
-urb->buffer_length = rem;
-aurb->more = 0;
}
pbuf += urb->buffer_length;
+prem -= urb->buffer_length;
rem -= urb->buffer_length;
+if (rem) {
+aurb->more = 1;
+}
ret = ioctl(s->fd, USBDEVFS_SUBMITURB, urb);
--
1.7.1
[Qemu-devel] [PATCH 4/9] usb: use iovecs in USBPacket
Zap data pointer from USBPacket, add a QEMUIOVector instead.
Add a bunch of helper functions to manage USBPacket data.
Switch over users to the new interface.
Note that USBPacket->len was used for two purposes: First to
pass in the buffer size and second to return the number of
transfered bytes or the status code on async transfers. There
is a new result variable for the latter. A new status code
was added to catch uninitialized result.
Nobody creates iovecs with more than one element (yet).
Some users are (temporarely) limited to iovecs with a single
element to keep the patch size as small as possible.
Signed-off-by: Gerd Hoffmann
---
Makefile.objs |1 +
hw/bt-hid.c| 16
hw/milkymist-softusb.c |8 ++--
hw/usb-bt.c| 31 +++--
hw/usb-ccid.c | 46 ++
hw/usb-ehci.c | 21 ---
hw/usb-hid.c |6 ++-
hw/usb-hub.c |8 +++--
hw/usb-libhw.c | 63 +++
hw/usb-msd.c | 12 --
hw/usb-musb.c | 22 ++--
hw/usb-net.c | 65
hw/usb-ohci.c | 23 ++---
hw/usb-serial.c|5 ++-
hw/usb-uhci.c | 38 +
hw/usb-wacom.c |6 ++-
hw/usb.c | 86
hw/usb.h | 13 ++-
usb-linux.c| 27 ---
19 files changed, 303 insertions(+), 194 deletions(-)
create mode 100644 hw/usb-libhw.c
diff --git a/Makefile.objs b/Makefile.objs
index cea15e4..d8a8d27 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -171,6 +171,7 @@ user-obj-y += cutils.o cache-utils.o
hw-obj-y =
hw-obj-y += vl.o loader.o
+hw-obj-y += usb-libhw.o
hw-obj-$(CONFIG_VIRTIO) += virtio.o virtio-console.o
hw-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o
hw-obj-y += fw_cfg.o
diff --git a/hw/bt-hid.c b/hw/bt-hid.c
index 09120af..a4204f9 100644
--- a/hw/bt-hid.c
+++ b/hw/bt-hid.c
@@ -127,11 +127,11 @@ static int bt_hid_out(struct bt_hid_device_s *s)
USBPacket p;
if (s->data_type == BT_DATA_OUTPUT) {
-p.pid = USB_TOKEN_OUT;
-p.devep = 1;
-p.data = s->dataout.buffer;
-p.len = s->dataout.len;
+usb_packet_init(&p);
+usb_packet_setup(&p, USB_TOKEN_OUT, 0, 1);
+usb_packet_addbuf(&p, s->dataout.buffer, s->dataout.len);
s->dataout.len = s->usbdev->info->handle_data(s->usbdev, &p);
+usb_packet_cleanup(&p);
return s->dataout.len;
}
@@ -150,11 +150,11 @@ static int bt_hid_in(struct bt_hid_device_s *s)
{
USBPacket p;
-p.pid = USB_TOKEN_IN;
-p.devep = 1;
-p.data = s->datain.buffer;
-p.len = sizeof(s->datain.buffer);
+usb_packet_init(&p);
+usb_packet_setup(&p, USB_TOKEN_IN, 0, 1);
+usb_packet_addbuf(&p, s->dataout.buffer, sizeof(s->datain.buffer));
s->datain.len = s->usbdev->info->handle_data(s->usbdev, &p);
+usb_packet_cleanup(&p);
return s->datain.len;
}
diff --git a/hw/milkymist-softusb.c b/hw/milkymist-softusb.c
index ce2bfc6..03f039b 100644
--- a/hw/milkymist-softusb.c
+++ b/hw/milkymist-softusb.c
@@ -234,11 +234,11 @@ static void softusb_usbdev_datain(void *opaque)
USBPacket p;
-p.pid = USB_TOKEN_IN;
-p.devep = 1;
-p.data = s->kbd_usb_buffer;
-p.len = sizeof(s->kbd_usb_buffer);
+usb_packet_init(&p);
+usb_packet_setup(&p, USB_TOKEN_IN, 0, 1);
+usb_packet_addbuf(&p, s->kbd_usb_buffer, sizeof(s->kbd_usb_buffer));
s->usbdev->info->handle_data(s->usbdev, &p);
+usb_packet_cleanup(&p);
softusb_kbd_changed(s);
}
diff --git a/hw/usb-bt.c b/hw/usb-bt.c
index e364513..6bebc7a 100644
--- a/hw/usb-bt.c
+++ b/hw/usb-bt.c
@@ -294,9 +294,9 @@ static inline int usb_bt_fifo_dequeue(struct
usb_hci_in_fifo_s *fifo,
if (likely(!fifo->len))
return USB_RET_STALL;
-len = MIN(p->len, fifo->fifo[fifo->start].len);
-memcpy(p->data, fifo->fifo[fifo->start].data, len);
-if (len == p->len) {
+len = MIN(p->iov.size, fifo->fifo[fifo->start].len);
+usb_packet_copy(p, fifo->fifo[fifo->start].data, len);
+if (len == p->iov.size) {
fifo->fifo[fifo->start].len -= len;
fifo->fifo[fifo->start].data += len;
} else {
@@ -319,20 +319,13 @@ static inline void usb_bt_fifo_out_enqueue(struct
USBBtState *s,
struct usb_hci_out_fifo_s *fifo,
void (*send)(struct HCIInfo *, const uint8_t *, int),
int (*complete)(const uint8_t *, int),
-const uint8_t *data, int len)
+USBPacket *p)
{
-if (fifo->len) {
-memcpy(fifo->data + fifo->len, data, len);
-fifo->len += len;
-if (complete(fifo->data, fifo->len)) {
-send(s->hci, fifo->data, fifo->len);
-fifo->len = 0;
-}
-} else if (complete(dat
[Qemu-devel] [PATCH 7/9] usb-storage: iovec support
Add full iovec support to usb-storage.
Signed-off-by: Gerd Hoffmann
---
hw/usb-msd.c | 107 ++---
1 files changed, 49 insertions(+), 58 deletions(-)
diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index 64fb9f8..91c4552 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -43,8 +43,6 @@ typedef struct {
enum USBMSDMode mode;
uint32_t scsi_len;
uint8_t *scsi_buf;
-uint32_t usb_len;
-uint8_t *usb_buf;
uint32_t data_len;
uint32_t residue;
uint32_t tag;
@@ -176,20 +174,14 @@ static const USBDesc desc = {
.str = desc_strings,
};
-static void usb_msd_copy_data(MSDState *s)
+static void usb_msd_copy_data(MSDState *s, USBPacket *p)
{
uint32_t len;
-len = s->usb_len;
+len = p->iov.size - p->result;
if (len > s->scsi_len)
len = s->scsi_len;
-if (s->mode == USB_MSDM_DATAIN) {
-memcpy(s->usb_buf, s->scsi_buf, len);
-} else {
-memcpy(s->scsi_buf, s->usb_buf, len);
-}
-s->usb_len -= len;
+usb_packet_copy(p, s->scsi_buf, len);
s->scsi_len -= len;
-s->usb_buf += len;
s->scsi_buf += len;
s->data_len -= len;
if (s->scsi_len == 0 || s->data_len == 0) {
@@ -225,9 +217,9 @@ static void usb_msd_transfer_data(SCSIRequest *req,
uint32_t len)
s->scsi_len = len;
s->scsi_buf = scsi_req_get_buf(req);
if (p) {
-usb_msd_copy_data(s);
-if (s->packet && s->usb_len == 0) {
-p->result = p->iov.size;
+usb_msd_copy_data(s, p);
+p = s->packet;
+if (p && p->result == p->iov.size) {
/* Set s->packet to NULL before calling usb_packet_complete
because another request may be issued before
usb_packet_complete returns. */
@@ -257,16 +249,13 @@ static void usb_msd_command_complete(SCSIRequest *req,
uint32_t status)
s->mode = USB_MSDM_CBW;
} else {
if (s->data_len) {
-s->data_len -= s->usb_len;
-if (s->mode == USB_MSDM_DATAIN) {
-memset(s->usb_buf, 0, s->usb_len);
-}
-s->usb_len = 0;
+int len = (p->iov.size - p->result);
+usb_packet_skip(p, len);
+s->data_len -= len;
}
if (s->data_len == 0) {
s->mode = USB_MSDM_CSW;
}
-p->result = p->iov.size;
}
s->packet = NULL;
usb_packet_complete(&s->dev, p);
@@ -352,10 +341,7 @@ static int usb_msd_handle_data(USBDevice *dev, USBPacket
*p)
int ret = 0;
struct usb_msd_cbw cbw;
uint8_t devep = p->devep;
-uint8_t *data = p->iov.iov[0].iov_base;
-int len = p->iov.iov[0].iov_len;
-assert(p->iov.niov == 1); /* temporary */
switch (p->pid) {
case USB_TOKEN_OUT:
if (devep != 2)
@@ -363,11 +349,11 @@ static int usb_msd_handle_data(USBDevice *dev, USBPacket
*p)
switch (s->mode) {
case USB_MSDM_CBW:
-if (len != 31) {
+if (p->iov.size != 31) {
fprintf(stderr, "usb-msd: Bad CBW size");
goto fail;
}
-memcpy(&cbw, data, 31);
+usb_packet_copy(p, &cbw, 31);
if (le32_to_cpu(cbw.sig) != 0x43425355) {
fprintf(stderr, "usb-msd: Bad signature %08x\n",
le32_to_cpu(cbw.sig));
@@ -398,36 +384,39 @@ static int usb_msd_handle_data(USBDevice *dev, USBPacket
*p)
if (s->mode != USB_MSDM_CSW && s->residue == 0) {
scsi_req_continue(s->req);
}
-ret = len;
+ret = p->result;
break;
case USB_MSDM_DATAOUT:
-DPRINTF("Data out %d/%d\n", len, s->data_len);
-if (len > s->data_len)
+DPRINTF("Data out %zd/%d\n", p->iov.size, s->data_len);
+if (p->iov.size > s->data_len) {
goto fail;
+}
-s->usb_buf = data;
-s->usb_len = len;
if (s->scsi_len) {
-usb_msd_copy_data(s);
+usb_msd_copy_data(s, p);
}
-if (s->residue && s->usb_len) {
-s->data_len -= s->usb_len;
-if (s->data_len == 0)
-s->mode = USB_MSDM_CSW;
-s->usb_len = 0;
+if (s->residue) {
+int len = p->iov.size - p->result;
+if (len) {
+usb_packet_skip(p, len);
+s->data_len -= len;
+if (s->data_len == 0) {
+s->mode = USB_MSDM_CSW;
+}
+}
}
-if (s->usb_len) {
+if (p->result < p->iov.size) {
DPRINTF("Deferring packet %p\n", p);
s->packet = p;
ret = USB_RET_ASYNC;
}
[Qemu-devel] [PATCH 8/9] uhci: remove buffer
Map guest memory and pass on a direct pointer instead of copying
the bits to a indirect buffer.
Signed-off-by: Gerd Hoffmann
---
hw/usb-uhci.c | 15 +++
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index 20b829b..824e3a5 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -31,6 +31,7 @@
#include "qemu-timer.h"
#include "usb-uhci.h"
#include "iov.h"
+#include "dma.h"
//#define DEBUG
//#define DEBUG_DUMP_DATA
@@ -111,6 +112,7 @@ typedef struct UHCIState UHCIState;
*/
typedef struct UHCIAsync {
USBPacket packet;
+QEMUSGList sgl;
UHCIState *uhci;
QTAILQ_ENTRY(UHCIAsync) next;
uint32_t td;
@@ -118,7 +120,6 @@ typedef struct UHCIAsync {
int8_tvalid;
uint8_t isoc;
uint8_t done;
-uint8_t buffer[2048];
} UHCIAsync;
typedef struct UHCIPort {
@@ -176,6 +177,7 @@ static UHCIAsync *uhci_async_alloc(UHCIState *s)
async->done = 0;
async->isoc = 0;
usb_packet_init(&async->packet);
+qemu_sglist_init(&async->sgl, 1);
return async;
}
@@ -183,6 +185,7 @@ static UHCIAsync *uhci_async_alloc(UHCIState *s)
static void uhci_async_free(UHCIState *s, UHCIAsync *async)
{
usb_packet_cleanup(&async->packet);
+qemu_sglist_destroy(&async->sgl);
qemu_free(async);
}
@@ -706,11 +709,6 @@ static int uhci_complete_td(UHCIState *s, UHCI_TD *td,
UHCIAsync *async, uint32_
goto out;
}
-if (len > 0) {
-/* write the data back */
-cpu_physical_memory_write(td->buffer, async->buffer, len);
-}
-
if ((td->ctrl & TD_CTRL_SPD) && len < max_len) {
*int_mask |= 0x02;
/* short packet: do not update QH */
@@ -827,12 +825,12 @@ static int uhci_handle_td(UHCIState *s, uint32_t addr,
UHCI_TD *td, uint32_t *in
usb_packet_setup(&async->packet, pid, (td->token >> 8) & 0x7f,
(td->token >> 15) & 0xf);
-usb_packet_addbuf(&async->packet, async->buffer, max_len);
+qemu_sglist_add(&async->sgl, td->buffer, max_len);
+usb_packet_map(&async->packet, &async->sgl);
switch(pid) {
case USB_TOKEN_OUT:
case USB_TOKEN_SETUP:
-cpu_physical_memory_read(td->buffer, async->buffer, max_len);
len = uhci_broadcast_packet(s, &async->packet);
if (len >= 0)
len = max_len;
@@ -859,6 +857,7 @@ static int uhci_handle_td(UHCIState *s, uint32_t addr,
UHCI_TD *td, uint32_t *in
done:
len = uhci_complete_td(s, td, async, int_mask);
+usb_packet_unmap(&async->packet);
uhci_async_free(s, async);
return len;
}
--
1.7.1
[Qemu-devel] [PATCH 9/9] ehci: ioven support, remove buffer
Map guest memory and pass on a direct pointer instead of copying
the bits to a indirect buffer. EHCI transfer descriptors can
reference multiple (physical guest) pages so we'll actually start
seeing usb packets wich carry iovec with more than one element.
Signed-off-by: Gerd Hoffmann
---
hw/usb-ehci.c | 147 -
1 files changed, 62 insertions(+), 85 deletions(-)
diff --git a/hw/usb-ehci.c b/hw/usb-ehci.c
index f01d1b0..194fb89 100644
--- a/hw/usb-ehci.c
+++ b/hw/usb-ehci.c
@@ -28,6 +28,7 @@
#include "pci.h"
#include "monitor.h"
#include "trace.h"
+#include "dma.h"
#define EHCI_DEBUG 0
@@ -269,6 +270,7 @@ typedef struct EHCIqtd {
uint32_t bufptr[5]; // Standard buffer pointer
#define QTD_BUFPTR_MASK 0xf000
+#define QTD_BUFPTR_SH 12
} EHCIqtd;
/* EHCI spec version 1.0 Section 3.6
@@ -357,7 +359,7 @@ struct EHCIQueue {
uint32_t qtdaddr; // address QTD read from
USBPacket packet;
-uint8_t buffer[BUFF_SIZE];
+QEMUSGList sgl;
int pid;
uint32_t tbytes;
enum async_state async;
@@ -414,7 +416,7 @@ struct EHCIState {
uint32_t p_fetch_addr; // which address to look at next
USBPacket ipacket;
-uint8_t ibuffer[BUFF_SIZE];
+QEMUSGList isgl;
int isoch_pause;
uint64_t last_run_ns;
@@ -1165,58 +1167,56 @@ static int ehci_qh_do_overlay(EHCIQueue *q)
return 0;
}
-static int ehci_buffer_rw(EHCIQueue *q, int bytes, int rw)
+static int ehci_init_transfer(EHCIQueue *q)
{
-int bufpos = 0;
-int cpage, offset;
-uint32_t head;
-uint32_t tail;
-
-
-if (!bytes) {
-return 0;
-}
-
-cpage = get_field(q->qh.token, QTD_TOKEN_CPAGE);
-if (cpage > 4) {
-fprintf(stderr, "cpage out of range (%d)\n", cpage);
-return USB_RET_PROCERR;
-}
+uint32_t cpage, offset, bytes, plen;
+target_phys_addr_t page;
+cpage = get_field(q->qh.token, QTD_TOKEN_CPAGE);
+bytes = get_field(q->qh.token, QTD_TOKEN_TBYTES);
offset = q->qh.bufptr[0] & ~QTD_BUFPTR_MASK;
+qemu_sglist_init(&q->sgl, 5);
-do {
-/* start and end of this page */
-head = q->qh.bufptr[cpage] & QTD_BUFPTR_MASK;
-tail = head + ~QTD_BUFPTR_MASK + 1;
-/* add offset into page */
-head |= offset;
-
-if (bytes <= (tail - head)) {
-tail = head + bytes;
+while (bytes > 0) {
+if (cpage > 4) {
+fprintf(stderr, "cpage out of range (%d)\n", cpage);
+return USB_RET_PROCERR;
}
-trace_usb_ehci_data(rw, cpage, offset, head, tail-head, bufpos);
-cpu_physical_memory_rw(head, q->buffer + bufpos, tail - head, rw);
-
-bufpos += (tail - head);
-offset += (tail - head);
-bytes -= (tail - head);
-
-if (bytes > 0) {
-cpage++;
+page = q->qh.bufptr[cpage] & QTD_BUFPTR_MASK;
+page += offset;
+plen = bytes;
+if (plen > 4096 - offset) {
+plen = 4096 - offset;
offset = 0;
+cpage++;
}
-} while (bytes > 0);
-/* save cpage */
-set_field(&q->qh.token, cpage, QTD_TOKEN_CPAGE);
+qemu_sglist_add(&q->sgl, page, plen);
+bytes -= plen;
+}
+return 0;
+}
-/* save offset into cpage */
-q->qh.bufptr[0] &= QTD_BUFPTR_MASK;
-q->qh.bufptr[0] |= offset;
+static void ehci_finish_transfer(EHCIQueue *q, int status)
+{
+uint32_t cpage, offset;
-return 0;
+qemu_sglist_destroy(&q->sgl);
+
+if (status > 0) {
+/* update cpage & offset */
+cpage = get_field(q->qh.token, QTD_TOKEN_CPAGE);
+offset = q->qh.bufptr[0] & ~QTD_BUFPTR_MASK;
+
+offset += status;
+cpage += offset >> QTD_BUFPTR_SH;
+offset &= ~QTD_BUFPTR_MASK;
+
+set_field(&q->qh.token, cpage, QTD_TOKEN_CPAGE);
+q->qh.bufptr[0] &= QTD_BUFPTR_MASK;
+q->qh.bufptr[0] |= offset;
+}
}
static void ehci_async_complete_packet(USBPort *port, USBPacket *packet)
@@ -1295,10 +1295,6 @@ err:
}
if (q->tbytes && q->pid == USB_TOKEN_IN) {
-if (ehci_buffer_rw(q, q->usb_status, 1) != 0) {
-q->usb_status = USB_RET_PROCERR;
-return;
-}
q->tbytes -= q->usb_status;
} else {
q->tbytes = 0;
@@ -1307,6 +1303,8 @@ err:
DPRINTF("updating tbytes to %d\n", q->tbytes);
set_field(&q->qh.token, q->tbytes, QTD_TOKEN_TBYTES);
}
+ehci_finish_transfer(q, q->usb_status);
+usb_packet_unmap(&q->packet);
q->qh.token ^= QTD_TOKEN_DTOGGLE;
q->qh.token &= ~QTD_TOKEN_ACTIVE;
@@ -1346,8 +1344,7 @@ static int ehci_execute(EHCIQueue *q)
default: fprintf(stderr, "bad token\n"); break;
}
-if ((q->tbytes && q->pid != USB_TOKEN_IN) &&
-(ehci_buffer_rw(q, q->tbytes, 0) != 0)) {
Re: [Qemu-devel] [PATCH 0/3] Random xen patches
On Sun, 17 Jul 2011, Alexander Graf wrote: > While applying some of the outstanding patches from the masses of Xen patches > on the mailing list, I stumbled over a few things and wrote up patches to fix > them. > > Functionally, nothing should change with these applied, but I want to give > people the chance to review them before pushing them :). They all look all right to me, thanks.
Re: [Qemu-devel] [PATCH v3] xen: implement unplug protocol in xen_platform
On Mon, 18 Jul 2011, Alexander Graf wrote:
> On 15.07.2011, at 12:52, Kevin Wolf wrote:
>
> > Am 15.07.2011 12:34, schrieb Stefano Stabellini:
> >> On Fri, 1 Jul 2011, Stefano Stabellini wrote:
> >>> On Fri, 1 Jul 2011, Kevin Wolf wrote:
> Am 30.06.2011 16:16, schrieb Stefano Stabellini:
> > On Thu, 30 Jun 2011, Kevin Wolf wrote:
> >>> +static int pci_piix3_xen_ide_unplug(DeviceState *dev)
> >>> +{
> >>> +PCIDevice *pci_dev;
> >>> +PCIIDEState *pci_ide;
> >>> +DriveInfo *di;
> >>> +int i = 0;
> >>> +
> >>> +pci_dev = DO_UPCAST(PCIDevice, qdev, dev);
> >>> +pci_ide = DO_UPCAST(PCIIDEState, dev, pci_dev);
> >>> +
> >>> +for (; i < 3; i++) {
> >>> +di = drive_get_by_index(IF_IDE, i);
> >>> +if (di != NULL && di->bdrv != NULL && !di->bdrv->removable) {
> >>> +DeviceState *ds = bdrv_get_attached(di->bdrv);
> >>> +if (ds) {
> >>> +bdrv_detach(di->bdrv, ds);
> >>> +}
> >>> +bdrv_close(di->bdrv);
> >>> +pci_ide->bus[di->bus].ifs[di->unit].bs = NULL;
> >>
> >> Have you tested if this is enough if the guest tries to continue using
> >> the device? I don't know of any case where it's not sufficient, just
> >> trying to make sure that it's really true in practice.
> >
> > The purpose of this is to "hide" the disk from the guest. The unplug is
> > supposed to happen *before* the guest enumerates the IDE disks; it is
> > responsibility of the guest to make sure of it.
> > I tested it with Linux PV on HVM drivers, and Linux doesn't see the
> > emulated disk after the unplug, as it should be.
>
> Yeah. What I meant is that we should make sure that a misbehaving guest,
> which just keeps on playing with the IDE ports anyway, can't crash qemu.
> A quick review suggests that it is the case, but testing it anyway would
> be better.
> >>>
> >>> I see what you mean: I tested it, a guest cannot crash Qemu.
> >>>
> >>
> >> ping?
> >
> > I thought Alex had already merged it. I'm pretty sure that I stated
> > somewhere that the patch is okay for me now. In case I didn't:
> >
> > Acked-by: Kevin Wolf
>
> Ah, must have missed it :). Thanks.
>
> Stefano, could you please rebase? The patch doesn't apply cleanly anymore.
OK, I'll send it again based on your latest xen-next branch.
Re: [Qemu-devel] Upstream QEMU and Xen unstable not working
On Mon, 18 Jul 2011, Wei Liu wrote:
> Bug resend.
>
> This bug was reported about one month ago. QEMU fails to start with
> Xen unstable. I found that it has not been fix with latest Xen
> unstable. BIOS is Seabios (with Xen patch).
>
> Xen-unstable a2457fc25c83872a5646c93f1e31958a2f5951e9
> libxl: add LIBXL_MAC_{FMT,FMTLEN,BYTES}
>
> Modelled after LIBXL_UUID_... (where I also add FMTLEN).
>
> signed-off-by: Ian Campbell
> Committed-by: Ian Jackson
>
> QEMU cf973e469bd9d47c0460347764c1315a6180e13c
> set ELF_HWCAP for SPARC and SPARC64
>
> setting ELF_HWCAP fixes dynamic library loading for Linux/sparc64
> This patch allows loading busybox from Debian 6 initrd
>
> Signed-off-by: Artyom Tarasenko
> Signed-off-by: Blue Swirl
>
>
> These are not the problematic commits, I didn't do a regression
> test. I just choose my latest commits as testing base.
>
> Also, please note that
> Xen-unstable a8f9242a7021a1febdc2ff7f8c6f6b66ee7e6745
> does not trigger this bug.
>
> Stefano and Anthony, you once said that you were going to setup a
> public QEMU repository for Xen, how is it going now?
We are getting there, but there are still too many xen patches floating
around qemu-devel at the moment to announce a new qemu xen tree.
However you can try the following branch for now:
git://xenbits.xen.org/people/sstabellini/qemu-dm.git xen-next
Re: [Qemu-devel] [PATCH 4/5] xen: Fix the memory registration to reflect of what is done by Xen.
On Fri, 15 Jul 2011, Anthony PERARD wrote: > A Xen guest memory is allocated by libxc. But this memory is not > allocated continuously, instead, it leaves the VGA IO memory space not > allocated, same for the MMIO space (at HVM_BELOW_4G_MMIO_START of size > HVM_BELOW_4G_MMIO_LENGTH). I realized now that you started using HVM_BELOW_4G_MMIO_START and HVM_BELOW_4G_MMIO_LENGTH without including xen/hvm/e820.h. It fails to compile on the latest xen-unstable.
[Qemu-devel] [Bug 811683] Re: 7400, 7410, 7450 cpus vector have wrong exception prefix at reset
Google for MPC7450UM.pdf and MPC7410UM.pdf. These two documents cover the 7441, 7445, 7451, 7455, 7457, 7447, 7448 and the 7410 and 7400 CPUs, respectively. For all these, Alex' description applies. However, (and I made a mistake in my original post), the setting affected is env->hreset_excp_prefix = 0xfff0UL; in addition, hreset_vector should be: env->hreset_vector = 0x0100UL; NOTE - I believe the other points raised by Alex (initialize MSR[IP] -- which BTW is called MSR_EP in qemu -- and switching the exception prefix when MSR[IP] is changed) are already correctly handled, see: target-ppc/helper.c: cpu_reset() target-ppc/helper-hreg.h: hreg_store_msr() Should I post a patch to the mailing-list? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/811683 Title: 7400,7410,7450 cpus vector have wrong exception prefix at reset Status in QEMU: New Bug description: I have a proprietary ROM implementing system calls that are executed via the 'SC' instruction. I use qemu-0.14.1, qemu-system-ppc -M prep -cpu $CPU -bios my_bios -kernel my_kernel That works fine on a 604 (CPU=0x00040103) - but does not on an emulated 7400 (CPU=0x000c0209) or 7450 (CPU=0x8201). I found that the emulator jumps to 0x0c00 instead of 0xfff00c00. Probably this is due to a wrong setting in target-ppc/translate_init.c: init_excp_604() correctly sets env->hreset_vector=0xfff0UL; but init_excp_7400() says env->hreset_vector=0xUL; which seems wrong. (the 7400 manual says a hard-reset jumps initializes the prefix to 0xfff0.) Likewise, init_excp_7450() (and probably other, related CPUs) are wrong. Indeed, when I change the value in init_excp_7400() to 0xfff0UL then everything works as expected for me. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/811683/+subscriptions
[Qemu-devel] [Bug 812398] [NEW] powerpc 7450 MMU initialization broken
Public bug reported: The 7540 family of PPCs' MMU can update TLBs using hardware search (like a 604 or 7400) but also using a software algorithm. The mechanism used is defined by HID0[STEN]. By default (CPU reset) HID0 is set to 0x8000 (BTW; another small bug, qemu doesn't set the hardwired MSB), hence the software-table lookup feature is *disabled*. However, the default (and immutable) 'mmu_model' for this CPU family is POWERC_MMU_SOFT_74XX which choses the soft TLB replacement scheme. To fix this: 1) the initial mmu_model for the 7450 family (includes 7441, 7445, 7451, 7455, 7457, 7447, 7448) should be: POWERPC_MMU_32B 2) when HID0[STEN] is written then the mmu_model should be changed accordingly (I'm not familiar enough with the qemu internal state to judge if any cached state would have to be updated). ** 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/812398 Title: powerpc 7450 MMU initialization broken Status in QEMU: New Bug description: The 7540 family of PPCs' MMU can update TLBs using hardware search (like a 604 or 7400) but also using a software algorithm. The mechanism used is defined by HID0[STEN]. By default (CPU reset) HID0 is set to 0x8000 (BTW; another small bug, qemu doesn't set the hardwired MSB), hence the software-table lookup feature is *disabled*. However, the default (and immutable) 'mmu_model' for this CPU family is POWERC_MMU_SOFT_74XX which choses the soft TLB replacement scheme. To fix this: 1) the initial mmu_model for the 7450 family (includes 7441, 7445, 7451, 7455, 7457, 7447, 7448) should be: POWERPC_MMU_32B 2) when HID0[STEN] is written then the mmu_model should be changed accordingly (I'm not familiar enough with the qemu internal state to judge if any cached state would have to be updated). To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/812398/+subscriptions
[Qemu-devel] [PATCH RESEND v3] xen: implement unplug protocol in xen_platform
From: Stefano Stabellini
The unplug protocol is necessary to support PV drivers in the guest: the
drivers expect to be able to "unplug" emulated disks and nics before
initializing the Xen PV interfaces.
It is responsibility of the guest to make sure that the unplug is done
before the emulated devices or the PV interface start to be used.
We use pci_for_each_device to walk the PCI bus, identify the devices and
disks that we want to disable and dynamically unplug them.
Changes in v2:
- use PCI_CLASS constants;
- replace pci_unplug_device with qdev_unplug;
- do not import hw/ide/internal.h in xen_platform.c;
Changes in v3:
- introduce piix3-ide-xen, that support hot-unplug;
- move the unplug code to hw/ide/piix.c;
- just call qdev_unplug from xen_platform.c to unplug the IDE disks;
Signed-off-by: Stefano Stabellini
---
hw/ide.h |1 +
hw/ide/piix.c | 44
hw/pc_piix.c |6 +-
hw/xen_platform.c | 43 ++-
4 files changed, 92 insertions(+), 2 deletions(-)
diff --git a/hw/ide.h b/hw/ide.h
index 34d9394..a490cbb 100644
--- a/hw/ide.h
+++ b/hw/ide.h
@@ -13,6 +13,7 @@ ISADevice *isa_ide_init(int iobase, int iobase2, int isairq,
/* ide-pci.c */
void pci_cmd646_ide_init(PCIBus *bus, DriveInfo **hd_table,
int secondary_ide_enabled);
+PCIDevice *pci_piix3_xen_ide_init(PCIBus *bus, DriveInfo **hd_table, int
devfn);
PCIDevice *pci_piix3_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn);
PCIDevice *pci_piix4_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn);
void vt82c686b_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn);
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 84f72b0..f527dbd 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -149,6 +149,42 @@ static int pci_piix_ide_initfn(PCIDevice *dev)
return 0;
}
+static int pci_piix3_xen_ide_unplug(DeviceState *dev)
+{
+PCIDevice *pci_dev;
+PCIIDEState *pci_ide;
+DriveInfo *di;
+int i = 0;
+
+pci_dev = DO_UPCAST(PCIDevice, qdev, dev);
+pci_ide = DO_UPCAST(PCIIDEState, dev, pci_dev);
+
+for (; i < 3; i++) {
+di = drive_get_by_index(IF_IDE, i);
+if (di != NULL && di->bdrv != NULL && !di->bdrv->removable) {
+DeviceState *ds = bdrv_get_attached(di->bdrv);
+if (ds) {
+bdrv_detach(di->bdrv, ds);
+}
+bdrv_close(di->bdrv);
+pci_ide->bus[di->bus].ifs[di->unit].bs = NULL;
+drive_put_ref(di);
+}
+}
+qdev_reset_all(&(pci_ide->dev.qdev));
+return 0;
+}
+
+PCIDevice *pci_piix3_xen_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn)
+{
+PCIDevice *dev;
+
+dev = pci_create_simple(bus, devfn, "piix3-ide-xen");
+dev->qdev.info->unplug = pci_piix3_xen_ide_unplug;
+pci_ide_create_devs(dev, hd_table);
+return dev;
+}
+
/* hd_table must contain 4 block drivers */
/* NOTE: for the PIIX3, the IRQs and IOports are hardcoded */
PCIDevice *pci_piix3_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn)
@@ -182,6 +218,14 @@ static PCIDeviceInfo piix_ide_info[] = {
.device_id= PCI_DEVICE_ID_INTEL_82371SB_1,
.class_id = PCI_CLASS_STORAGE_IDE,
},{
+.qdev.name= "piix3-ide-xen",
+.qdev.size= sizeof(PCIIDEState),
+.qdev.no_user = 1,
+.init = pci_piix_ide_initfn,
+.vendor_id= PCI_VENDOR_ID_INTEL,
+.device_id= PCI_DEVICE_ID_INTEL_82371SB_1,
+.class_id = PCI_CLASS_STORAGE_IDE,
+},{
.qdev.name= "piix4-ide",
.qdev.size= sizeof(PCIIDEState),
.qdev.no_user = 1,
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index c5c16b4..40b73ea 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -155,7 +155,11 @@ static void pc_init1(ram_addr_t ram_size,
ide_drive_get(hd, MAX_IDE_BUS);
if (pci_enabled) {
PCIDevice *dev;
-dev = pci_piix3_ide_init(pci_bus, hd, piix3_devfn + 1);
+if (xen_enabled()) {
+dev = pci_piix3_xen_ide_init(pci_bus, hd, piix3_devfn + 1);
+} else {
+dev = pci_piix3_ide_init(pci_bus, hd, piix3_devfn + 1);
+}
idebus[0] = qdev_get_child_bus(&dev->qdev, "ide.0");
idebus[1] = qdev_get_child_bus(&dev->qdev, "ide.1");
} else {
diff --git a/hw/xen_platform.c b/hw/xen_platform.c
index b167eee..a271369 100644
--- a/hw/xen_platform.c
+++ b/hw/xen_platform.c
@@ -76,6 +76,35 @@ static void log_writeb(PCIXenPlatformState *s, char val)
}
/* Xen Platform, Fixed IOPort */
+#define UNPLUG_ALL_IDE_DISKS 1
+#define UNPLUG_ALL_NICS 2
+#define UNPLUG_AUX_IDE_DISKS 4
+
+static void unplug_nic(PCIBus *b, PCIDevice *d)
+{
+if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
+PCI_CLASS_NETWORK_ETHERNET) {
+qdev_unplug(&(d->qdev));
+}
+}
+
+static void pci_unplug_nics(PCIBus *bus)
+{
+pci_for_each_device(b
Re: [Qemu-devel] [Bug 811683] [NEW] 7400, 7410, 7450 cpus vector have wrong exception prefix at reset
Hi Andreas. I posted a reply to the bug database. Regarding my 'bios' - it is really nothing. I need it to boot RTEMS. It just mocks up a minimal residual and jumps to the kernel load address. You can take a look at http://www.rtems.org/viewvc/rtems/c/src/lib/libbsp/powerpc/shared/bootloader/ The stuff that goes into the dummy 'bios' is qemu_fakerom.S and qemu_fakeres.c Regards - Till On 07/17/2011 05:34 PM, Andreas Färber wrote: > Hi, > > Am 16.07.2011 um 23:49 schrieb till: > >> I have a proprietary ROM implementing system calls that are executed >> via >> the 'SC' instruction. >> >> I use qemu-0.14.1, >> >> qemu-system-ppc -M prep -cpu $CPU -bios my_bios -kernel my_kernel >> >> That works fine on a 604 (CPU=0x00040103) - but does not on an >> emulated 7400 (CPU=0x000c0209) or 7450 (CPU=0x8201). I found >> that the emulator jumps to 0x0c00 instead of 0xfff00c00. >> Probably this is due to a wrong setting in target-ppc/ >> translate_init.c: >> >> init_excp_604() correctly sets env->hreset_vector=0xfff0UL; >> >> but >> >> init_excp_7400() says env->hreset_vector=0xUL; >> >> which seems wrong. (the 7400 manual says a hard-reset jumps >> initializes the >> prefix to 0xfff0.) > Do you have a link to a spec saying so? Should be trivial to change > then. > >> Likewise, init_excp_7450() (and probably other, related CPUs) are >> wrong. >> >> Indeed, when I change the value in init_excp_7400() to 0xfff0UL >> then >> everything works as expected for me. >> >> ** Affects: qemu >> Importance: Undecided >> Status: New >> Bug description: >> I have a proprietary ROM implementing system calls that are executed >> via the 'SC' instruction. >> >> I use qemu-0.14.1, >> >> qemu-system-ppc -M prep -cpu $CPU -bios my_bios -kernel my_kernel > We are currently in the process of revamping the PReP machine you are > using above. Is your BIOS available publicly so that we can test we > don't break anything for you? > > Andreas > -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/811683 Title: 7400,7410,7450 cpus vector have wrong exception prefix at reset Status in QEMU: New Bug description: I have a proprietary ROM implementing system calls that are executed via the 'SC' instruction. I use qemu-0.14.1, qemu-system-ppc -M prep -cpu $CPU -bios my_bios -kernel my_kernel That works fine on a 604 (CPU=0x00040103) - but does not on an emulated 7400 (CPU=0x000c0209) or 7450 (CPU=0x8201). I found that the emulator jumps to 0x0c00 instead of 0xfff00c00. Probably this is due to a wrong setting in target-ppc/translate_init.c: init_excp_604() correctly sets env->hreset_vector=0xfff0UL; but init_excp_7400() says env->hreset_vector=0xUL; which seems wrong. (the 7400 manual says a hard-reset jumps initializes the prefix to 0xfff0.) Likewise, init_excp_7450() (and probably other, related CPUs) are wrong. Indeed, when I change the value in init_excp_7400() to 0xfff0UL then everything works as expected for me. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/811683/+subscriptions
Re: [Qemu-devel] 2.6.32.x guest dies when trying to run tcpdump
Hello gentlemans, I'm back to this issue, hopefully I'm not bothering too much :( To summarize first: we're experiencing problems with 2.6.32.x KVM guests crashing when running tcpdump. The problem has been fixed since then, in newer kernels, but I'd like to find the fix and get it to 2.6.32.x stable series. I've been bisecting this lately, and narrowed this to 2.6.34 - the problem has been fixed there. The problem is, I've somehow got cornered there: I've got ~3200 commits left, but got into state, where I can't test commits further - there was regression in 2.6.34-rc1 (I think), which caused tcpdump to stop working (see http://lkml.org/lkml/2010/3/9/439) Regression was introduced by 914c8ad2d18b62ad1420f518c0cab0b0b90ab308 and fixed by 1162563f82b434e3099c9e6c1bbdba846d792f0d. I can still reproduce the problem with 1162563f82b434e3099c9e6c1bbdba846d792f0d, and can't with 4961e02f1999e1c3468c09b2669c94d7c3ae82a8. When I try to continue to bisect, git gets me to fa0d976298b25d090fafc3460c63fee1c8eea854, the commit which is somewhere between 1162563f82b434e3099c9e6c1bbdba846d792f0d and 4961e02f1999e1c3468c09b2669c94d7c3ae82a8. Strange thing is, that I'm again hitting the other problem with tcpdump, which should have been fixed by 1162563f82b434e3099c9e6c1bbdba846d792f0d! When I check the net/packet/af_packet.c, the fix really doesn't seem to be there although that commit is a lot later then 1162563f82b434e3099c9e6c1bbdba846d792f0d! I'm not sure about what I'm doing wrong, I guess it has to do something with merging branches... Can somebody more knowledgeable about git hint me about how to continue? I'd really like to get this fixed for 2.6.32... Thanks a lot to anyone willing to help! with best regards nik On Sun, Apr 17, 2011 at 05:15:24PM +0200, Nikola Ciprich wrote: > OK, just wanted to let You know I were testing it quite a lot, and I'm not > able to reproduce this with 2.6.38.3-rc1. > So the bug must have been fixed. > I'll bisect it to find proper fix so it can be posted to stable... > n. > > > On Sat, Apr 02, 2011 at 09:42:26PM +0200, Nikola Ciprich wrote: > > Hello Stefan! > > > > > It looks like your guests are SMP. How many vcpus are you running? > > > How many physical cpus does /proc/cpuinfo list on the host? > > one of guests is SMP (8cpus), one is UP, host has 2x4 cores. > > > > > > Is the host overloaded when this occurs? > > nope > > > > > > > > Are there any clues in host dmesg? > > nothing :( > > I guess I shall try 2.6.38 or maybe latest git to check if the problem > > is still present... > > > > > > > > Stefan > > > -- > > > To unsubscribe from this list: send the line "unsubscribe kvm" in > > > the body of a message to majord...@vger.kernel.org > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > > > -- > > - > > Ing. Nikola CIPRICH > > LinuxBox.cz, s.r.o. > > 28. rijna 168, 709 01 Ostrava > > > > tel.: +420 596 603 142 > > fax:+420 596 621 273 > > mobil: +420 777 093 799 > > > > www.linuxbox.cz > > > > mobil servis: +420 737 238 656 > > email servis: ser...@linuxbox.cz > > - > > -- > > To unsubscribe from this list: send the line "unsubscribe kvm" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > - > Ing. Nikola CIPRICH > LinuxBox.cz, s.r.o. > 28. rijna 168, 709 01 Ostrava > > tel.: +420 596 603 142 > fax:+420 596 621 273 > mobil: +420 777 093 799 > > www.linuxbox.cz > > mobil servis: +420 737 238 656 > email servis: ser...@linuxbox.cz > - -- - Ing. Nikola CIPRICH LinuxBox.cz, s.r.o. 28. rijna 168, 709 01 Ostrava tel.: +420 596 603 142 fax:+420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: ser...@linuxbox.cz - pgplizsICWC1w.pgp Description: PGP signature
[Qemu-devel] qemu FreeBSD/sparc64 host - a bit of debugging
Hi! I'm the FreeBSD qemu port maintainer and don't have a sparc64 box myself, but Jashank Jeremy (Cc'd) now was so kind to test qemu 0.14.1 on a FreeBSD/sparc64 box booting a FreeBSD 8/i386 install iso using i386-softmmu and we found two things: 1. The hang people have been reporting seems to be caused by this tb: IN: 0x000e7a31: in $0xb3,%al 0x000e7a33: test %al,%al 0x000e7a35: jne0xe7a31 i.e. it (the qemu bios I suppose) is waiting for x86 ioport 0xb3 to become zero. This port is #defined in hw/apm.c as: qemu-0.14.1/hw/apm.c:#define APM_STS_IOPORT 0xb3 but the definition seems to be used nowhere in that source file. Anyone have an idea why this port is never zero on sparc64 hosts but seems to be on others? (endian issue? uninitialized variable?) 2. Booting the same guest with -no-acpi gets further, bios and bootloader messages are printed until it hangs again, this time while handling a guest irq 8 which seems to be rtc. Maybe this is useful to some... :) Thanx, Juergen
[Qemu-devel] KVM call agenda for July 18
Hi Please send in any agenda items you are interested in covering. >From last week: - Device passthrough on non-PCI (take 2) (agraf) Later, Juan.
Re: [Qemu-devel] KVM call agenda for July 18
On 07/18/2011 02:11 PM, Juan Quintela wrote: Hi Please send in any agenda items you are interested in covering. From last week: - Device passthrough on non-PCI (take 2) (agraf) - 0.15 Release Schedule - Unified object model (QEMU Object Model) Regards, Anthony Liguori Later, Juan.
Re: [Qemu-devel] [Xen-devel] Re: [PATCH 3/5] cpu-common: Have a ram_addr_t of uint64 with Xen.
On Mon, Jul 18, 2011 at 15:46, Anthony PERARD wrote:
> On Mon, Jul 18, 2011 at 13:30, Alexander Graf wrote:
>>
>> On 15.07.2011, at 16:32, Anthony Perard wrote:
>>
>>> In Xen case, memory can be bigger than the host memory. that mean a
>>> 32bits host (and QEMU) should be able to handle a RAM address of 64bits.
>>>
>>> Signed-off-by: Anthony PERARD
>>> ---
>>> cpu-common.h | 8
>>> exec.c | 9 +
>>> xen-all.c | 2 +-
>>> 3 files changed, 14 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/cpu-common.h b/cpu-common.h
>>> index e4fcded..e1b40fe 100644
>>> --- a/cpu-common.h
>>> +++ b/cpu-common.h
>>> @@ -27,7 +27,15 @@ enum device_endian {
>>> };
>>>
>>> /* address in the RAM (different from a physical address) */
>>> +#ifndef CONFIG_XEN_BACKEND
>>> typedef unsigned long ram_addr_t;
>>
>> Do we really want to depend this on _BACKEND? ram_addr_t is target
>> dependent, no?
>
> :(, indeed, it's seams to be target dependent, I did not check that
> carefully enough. So CONFIG_XEN is enough.
Actually, this does not work because it is used in libhw64 (like
target_phys_addr_t).
So I am thinking about eithier introduce a new config variable in
./configure (ram_addr_bits), or just have
#if defined(CONFIG_XEN_BACKEND) && TARGET_PHYS_ADDR_BITS == 64
So, libhw64 with xen activated will be compiled with a ram_addr of
64b, and the libhw32 will stay with a "unsigned long".
--
Anthony PERARD
[Qemu-devel] [PATCH] Fix duplicate device reset
qbus_reset_all_fn was registered twice, so a lot of device reset functions were also called twice when QEMU started. It is sufficient to call sysbus_get_default() which will register qbus_reset_all_fn. Signed-off-by: Stefan Weil --- vl.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/vl.c b/vl.c index fcd7395..fb2f6db 100644 --- a/vl.c +++ b/vl.c @@ -3301,7 +3301,7 @@ int main(int argc, char **argv, char **envp) /* TODO: once all bus devices are qdevified, this should be done * when bus is created by qdev.c */ -qemu_register_reset(qbus_reset_all_fn, sysbus_get_default()); +sysbus_get_default(); qemu_run_machine_init_done_notifiers(); qemu_system_reset(VMRESET_SILENT); -- 1.7.2.5
[Qemu-devel] [PATCHv3 0/3] ds1225y: qdev-ification (used in MIPS Jazz)
This patchset qdev-ifies the ds1225y device, used in MIPS Jazz emulation. Changes since v2: - replace "nvram" by "ds1225y" for qdev device name (no change in patches 1 and 2) Changes since v1: - rebased - split into multiple patches as per Markus advice Hervé Poussineau (3): ds1225y: Remove protection stuff, which doesn't belong to this device ds1225y: use trace framework ds1225y: convert to qdev device, and use it in MIPS Jazz emulation hw/ds1225y.c | 151 --- hw/mips.h |4 -- hw/mips_jazz.c | 11 +++- trace-events |4 ++ 4 files changed, 89 insertions(+), 81 deletions(-) -- 1.7.5.4
[Qemu-devel] [PATCHv3 2/3] ds1225y: use trace framework
Signed-off-by: Hervé Poussineau
---
hw/ds1225y.c | 16 +---
trace-events |4
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/hw/ds1225y.c b/hw/ds1225y.c
index 1fd7010..5105b9b 100644
--- a/hw/ds1225y.c
+++ b/hw/ds1225y.c
@@ -24,9 +24,7 @@
#include "hw.h"
#include "mips.h"
-#include "nvram.h"
-
-//#define DEBUG_NVRAM
+#include "trace.h"
typedef struct ds1225y_t
{
@@ -42,10 +40,7 @@ static uint32_t nvram_readb (void *opaque,
target_phys_addr_t addr)
uint32_t val;
val = s->contents[addr];
-
-#ifdef DEBUG_NVRAM
-printf("nvram: read 0x%x at " TARGET_FMT_lx "\n", val, addr);
-#endif
+trace_nvram_read(addr, val);
return val;
}
@@ -71,11 +66,10 @@ static void nvram_writeb (void *opaque, target_phys_addr_t
addr, uint32_t val)
{
ds1225y_t *s = opaque;
-#ifdef DEBUG_NVRAM
-printf("nvram: write 0x%x at " TARGET_FMT_lx "\n", val, addr);
-#endif
+val &= 0xff;
+trace_nvram_write(addr, s->contents[addr], val);
-s->contents[addr] = val & 0xff;
+s->contents[addr] = val;
if (s->file) {
qemu_fseek(s->file, addr, SEEK_SET);
qemu_put_byte(s->file, (int)val);
diff --git a/trace-events b/trace-events
index bebf612..a8cac32 100644
--- a/trace-events
+++ b/trace-events
@@ -92,6 +92,10 @@ disable cs4231_mem_readl_reg(uint32_t reg, uint32_t ret)
"read reg %d: 0x%08x"
disable cs4231_mem_writel_reg(uint32_t reg, uint32_t old, uint32_t val) "write
reg %d: 0x%08x -> 0x%08x"
disable cs4231_mem_writel_dreg(uint32_t reg, uint32_t old, uint32_t val)
"write dreg %d: 0x%02x -> 0x%02x"
+# hw/ds1225y.c
+disable nvram_read(uint32_t addr, uint32_t ret) "read addr %d: 0x%02x"
+disable nvram_write(uint32_t addr, uint32_t old, uint32_t val) "write addr %d:
0x%02x -> 0x%02x"
+
# hw/eccmemctl.c
disable ecc_mem_writel_mer(uint32_t val) "Write memory enable %08x"
disable ecc_mem_writel_mdr(uint32_t val) "Write memory delay %08x"
--
1.7.5.4
[Qemu-devel] [PATCHv3 1/3] ds1225y: Remove protection stuff, which doesn't belong to this device
Signed-off-by: Hervé Poussineau
---
hw/ds1225y.c | 42 +-
hw/mips.h|1 -
2 files changed, 1 insertions(+), 42 deletions(-)
diff --git a/hw/ds1225y.c b/hw/ds1225y.c
index b1c5232..1fd7010 100644
--- a/hw/ds1225y.c
+++ b/hw/ds1225y.c
@@ -33,7 +33,6 @@ typedef struct ds1225y_t
uint32_t chip_size;
QEMUFile *file;
uint8_t *contents;
-uint8_t protection;
} ds1225y_t;
@@ -98,34 +97,6 @@ static void nvram_writel (void *opaque, target_phys_addr_t
addr, uint32_t val)
nvram_writeb(opaque, addr + 3, (val >> 24) & 0xff);
}
-static void nvram_writeb_protected (void *opaque, target_phys_addr_t addr,
uint32_t val)
-{
-ds1225y_t *s = opaque;
-
-if (s->protection != 7) {
-#ifdef DEBUG_NVRAM
-printf("nvram: prevent write of 0x%x at " TARGET_FMT_lx "\n", val, addr);
-#endif
-return;
-}
-
-nvram_writeb(opaque, addr, val);
-}
-
-static void nvram_writew_protected (void *opaque, target_phys_addr_t addr,
uint32_t val)
-{
-nvram_writeb_protected(opaque, addr, val & 0xff);
-nvram_writeb_protected(opaque, addr + 1, (val >> 8) & 0xff);
-}
-
-static void nvram_writel_protected (void *opaque, target_phys_addr_t addr,
uint32_t val)
-{
-nvram_writeb_protected(opaque, addr, val & 0xff);
-nvram_writeb_protected(opaque, addr + 1, (val >> 8) & 0xff);
-nvram_writeb_protected(opaque, addr + 2, (val >> 16) & 0xff);
-nvram_writeb_protected(opaque, addr + 3, (val >> 24) & 0xff);
-}
-
static CPUReadMemoryFunc * const nvram_read[] = {
&nvram_readb,
&nvram_readw,
@@ -138,23 +109,16 @@ static CPUWriteMemoryFunc * const nvram_write[] = {
&nvram_writel,
};
-static CPUWriteMemoryFunc * const nvram_write_protected[] = {
-&nvram_writeb_protected,
-&nvram_writew_protected,
-&nvram_writel_protected,
-};
-
/* Initialisation routine */
void *ds1225y_init(target_phys_addr_t mem_base, const char *filename)
{
ds1225y_t *s;
-int mem_indexRW, mem_indexRP;
+int mem_indexRW;
QEMUFile *file;
s = qemu_mallocz(sizeof(ds1225y_t));
s->chip_size = 0x2000; /* Fixed for ds1225y chip: 8 KiB */
s->contents = qemu_mallocz(s->chip_size);
-s->protection = 7;
/* Read current file */
file = qemu_fopen(filename, "rb");
@@ -174,9 +138,5 @@ void *ds1225y_init(target_phys_addr_t mem_base, const char
*filename)
mem_indexRW = cpu_register_io_memory(nvram_read, nvram_write, s,
DEVICE_NATIVE_ENDIAN);
cpu_register_physical_memory(mem_base, s->chip_size, mem_indexRW);
-/* Read/write protected memory */
-mem_indexRP = cpu_register_io_memory(nvram_read, nvram_write_protected, s,
- DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory(mem_base + s->chip_size, s->chip_size,
mem_indexRP);
return s;
}
diff --git a/hw/mips.h b/hw/mips.h
index 73aa8f8..93c8831 100644
--- a/hw/mips.h
+++ b/hw/mips.h
@@ -10,7 +10,6 @@ PCIBus *bonito_init(qemu_irq *pic);
/* ds1225y.c */
void *ds1225y_init(target_phys_addr_t mem_base, const char *filename);
-void ds1225y_set_protection(void *opaque, int protection);
/* g364fb.c */
int g364fb_mm_init(target_phys_addr_t vram_base,
--
1.7.5.4
[Qemu-devel] [PATCHv3 3/3] ds1225y: convert to qdev device, and use it in MIPS Jazz emulation
Signed-off-by: Hervé Poussineau
---
hw/ds1225y.c | 99 +--
hw/mips.h |3 --
hw/mips_jazz.c | 11 +-
3 files changed, 82 insertions(+), 31 deletions(-)
diff --git a/hw/ds1225y.c b/hw/ds1225y.c
index 5105b9b..87412e2 100644
--- a/hw/ds1225y.c
+++ b/hw/ds1225y.c
@@ -22,21 +22,20 @@
* THE SOFTWARE.
*/
-#include "hw.h"
-#include "mips.h"
+#include "sysbus.h"
#include "trace.h"
-typedef struct ds1225y_t
-{
+typedef struct {
+DeviceState qdev;
uint32_t chip_size;
+char *filename;
QEMUFile *file;
uint8_t *contents;
-} ds1225y_t;
-
+} NvRamState;
static uint32_t nvram_readb (void *opaque, target_phys_addr_t addr)
{
-ds1225y_t *s = opaque;
+NvRamState *s = opaque;
uint32_t val;
val = s->contents[addr];
@@ -64,7 +63,7 @@ static uint32_t nvram_readl (void *opaque, target_phys_addr_t
addr)
static void nvram_writeb (void *opaque, target_phys_addr_t addr, uint32_t val)
{
-ds1225y_t *s = opaque;
+NvRamState *s = opaque;
val &= 0xff;
trace_nvram_write(addr, s->contents[addr], val);
@@ -103,34 +102,83 @@ static CPUWriteMemoryFunc * const nvram_write[] = {
&nvram_writel,
};
-/* Initialisation routine */
-void *ds1225y_init(target_phys_addr_t mem_base, const char *filename)
+static int nvram_post_load(void *opaque, int version_id)
{
-ds1225y_t *s;
-int mem_indexRW;
+NvRamState *s = opaque;
+
+/* Close file, as filename may has changed in load/store process */
+if (s->file) {
+qemu_fclose(s->file);
+}
+
+/* Write back nvram contents */
+s->file = qemu_fopen(s->filename, "wb");
+if (s->file) {
+/* Write back contents, as 'wb' mode cleaned the file */
+qemu_put_buffer(s->file, s->contents, s->chip_size);
+qemu_fflush(s->file);
+}
+
+return 0;
+}
+
+static const VMStateDescription vmstate_nvram = {
+.name = "nvram",
+.version_id = 0,
+.minimum_version_id = 0,
+.minimum_version_id_old = 0,
+.post_load = nvram_post_load,
+.fields = (VMStateField[]) {
+VMSTATE_VARRAY_UINT32(contents, NvRamState, chip_size, 0,
+ vmstate_info_uint8, uint8_t),
+VMSTATE_END_OF_LIST()
+}
+};
+
+typedef struct {
+SysBusDevice busdev;
+NvRamState nvram;
+} SysBusNvRamState;
+
+static int nvram_sysbus_initfn(SysBusDevice *dev)
+{
+NvRamState *s = &FROM_SYSBUS(SysBusNvRamState, dev)->nvram;
QEMUFile *file;
+int s_io;
-s = qemu_mallocz(sizeof(ds1225y_t));
-s->chip_size = 0x2000; /* Fixed for ds1225y chip: 8 KiB */
s->contents = qemu_mallocz(s->chip_size);
+s_io = cpu_register_io_memory(nvram_read, nvram_write, s,
+ DEVICE_NATIVE_ENDIAN);
+sysbus_init_mmio(dev, s->chip_size, s_io);
+
/* Read current file */
-file = qemu_fopen(filename, "rb");
+file = qemu_fopen(s->filename, "rb");
if (file) {
/* Read nvram contents */
qemu_get_buffer(file, s->contents, s->chip_size);
qemu_fclose(file);
}
-s->file = qemu_fopen(filename, "wb");
-if (s->file) {
-/* Write back contents, as 'wb' mode cleaned the file */
-qemu_put_buffer(s->file, s->contents, s->chip_size);
-qemu_fflush(s->file);
-}
+nvram_post_load(s, 0);
-/* Read/write memory */
-mem_indexRW = cpu_register_io_memory(nvram_read, nvram_write, s,
- DEVICE_NATIVE_ENDIAN);
-cpu_register_physical_memory(mem_base, s->chip_size, mem_indexRW);
-return s;
+return 0;
}
+
+static SysBusDeviceInfo nvram_sysbus_info = {
+.qdev.name = "ds1225y",
+.qdev.size = sizeof(SysBusNvRamState),
+.qdev.vmsd = &vmstate_nvram,
+.init = nvram_sysbus_initfn,
+.qdev.props = (Property[]) {
+DEFINE_PROP_UINT32("size", SysBusNvRamState, nvram.chip_size, 0x2000),
+DEFINE_PROP_STRING("filename", SysBusNvRamState, nvram.filename),
+DEFINE_PROP_END_OF_LIST(),
+},
+};
+
+static void nvram_register(void)
+{
+sysbus_register_withprop(&nvram_sysbus_info);
+}
+
+device_init(nvram_register)
diff --git a/hw/mips.h b/hw/mips.h
index 93c8831..cae5f4c 100644
--- a/hw/mips.h
+++ b/hw/mips.h
@@ -8,9 +8,6 @@ PCIBus *gt64120_register(qemu_irq *pic);
/* bonito.c */
PCIBus *bonito_init(qemu_irq *pic);
-/* ds1225y.c */
-void *ds1225y_init(target_phys_addr_t mem_base, const char *filename);
-
/* g364fb.c */
int g364fb_mm_init(target_phys_addr_t vram_base,
target_phys_addr_t ctrl_base, int it_shift,
diff --git a/hw/mips_jazz.c b/hw/mips_jazz.c
index a100394..99002c3 100644
--- a/hw/mips_jazz.c
+++ b/hw/mips_jazz.c
@@ -37,6 +37,7 @@
#include "loader.h"
#include "mc146818rtc.h"
#include "blockdev.h"
+#include "sysbus.h"
enum jazz_model_e
{
@@ -115,6 +116,8 @@ void mips_jazz_init (ram_addr_t ram_size,
void* rc4030_opaque;
int s_rtc, s_d
[Qemu-devel] [PATCH v9 09/12] VMDK: open/read/write for monolithicFlat image
Parse vmdk decriptor file and open mono flat image.
Read/write the flat extent.
Signed-off-by: Fam Zheng
---
block/vmdk.c | 171 +-
1 files changed, 158 insertions(+), 13 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index f637d98..e1fb962 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -65,6 +65,7 @@ typedef struct VmdkExtent {
bool flat;
int64_t sectors;
int64_t end_sector;
+int64_t flat_start_offset;
int64_t l1_table_offset;
int64_t l1_backup_table_offset;
uint32_t *l1_table;
@@ -407,9 +408,10 @@ fail:
static int vmdk_parent_open(BlockDriverState *bs)
{
char *p_name;
-char desc[DESC_SIZE];
+char desc[DESC_SIZE + 1];
BDRVVmdkState *s = bs->opaque;
+desc[DESC_SIZE] = '\0';
if (bdrv_pread(bs->file, s->desc_offset, desc, DESC_SIZE) != DESC_SIZE) {
return -1;
}
@@ -584,6 +586,144 @@ static int vmdk_open_vmdk4(BlockDriverState *bs, int
flags)
return ret;
}
+/* find an option value out of descriptor file */
+static int vmdk_parse_description(const char *desc, const char *opt_name,
+char *buf, int buf_size)
+{
+char *opt_pos, *opt_end;
+const char *end = desc + strlen(desc);
+
+opt_pos = strstr(desc, opt_name);
+if (!opt_pos) {
+return -1;
+}
+/* Skip "=\"" following opt_name */
+opt_pos += strlen(opt_name) + 2;
+if (opt_pos >= end) {
+return -1;
+}
+opt_end = opt_pos;
+while (opt_end < end && *opt_end != '"') {
+opt_end++;
+}
+if (opt_end == end || buf_size < opt_end - opt_pos + 1) {
+return -1;
+}
+pstrcpy(buf, opt_end - opt_pos + 1, opt_pos);
+return 0;
+}
+
+static int vmdk_parse_extents(const char *desc, BlockDriverState *bs,
+const char *desc_file_path)
+{
+int ret;
+char access[11];
+char type[11];
+char fname[512];
+const char *p = desc;
+int64_t sectors = 0;
+int64_t flat_offset;
+
+while (*p) {
+/* parse extent line:
+ * RW [size in sectors] FLAT "file-name.vmdk" OFFSET
+ * or
+ * RW [size in sectors] SPARSE "file-name.vmdk"
+ */
+flat_offset = -1;
+ret = sscanf(p, "%10s %" SCNd64 " %10s %511s %" SCNd64,
+access, §ors, type, fname, &flat_offset);
+if (ret < 4 || strcmp(access, "RW")) {
+goto next_line;
+} else if (!strcmp(type, "FLAT")) {
+if (ret != 5 || flat_offset < 0) {
+return -EINVAL;
+}
+} else if (ret != 4) {
+return -EINVAL;
+}
+
+/* trim the quotation marks around */
+if (fname[0] == '"') {
+memmove(fname, fname + 1, strlen(fname));
+if (strlen(fname) <= 1 || fname[strlen(fname) - 1] != '"') {
+return -EINVAL;
+}
+fname[strlen(fname) - 1] = '\0';
+}
+if (sectors <= 0 ||
+(strcmp(type, "FLAT") && strcmp(type, "SPARSE")) ||
+(strcmp(access, "RW"))) {
+goto next_line;
+}
+
+/* save to extents array */
+if (!strcmp(type, "FLAT")) {
+/* FLAT extent */
+char extent_path[PATH_MAX];
+BlockDriverState *extent_file;
+VmdkExtent *extent;
+
+path_combine(extent_path, sizeof(extent_path),
+desc_file_path, fname);
+ret = bdrv_file_open(&extent_file, extent_path, bs->open_flags);
+if (ret) {
+return ret;
+}
+extent = vmdk_add_extent(bs, extent_file, true, sectors,
+0, 0, 0, 0, sectors);
+extent->flat_start_offset = flat_offset;
+} else {
+/* SPARSE extent, not supported for now */
+fprintf(stderr,
+"VMDK: Not supported extent type \"%s\""".\n", type);
+return -ENOTSUP;
+}
+next_line:
+/* move to next line */
+while (*p && *p != '\n') {
+p++;
+}
+p++;
+}
+return 0;
+}
+
+static int vmdk_open_desc_file(BlockDriverState *bs, int flags)
+{
+int ret;
+char buf[2048];
+char ct[128];
+BDRVVmdkState *s = bs->opaque;
+
+ret = bdrv_pread(bs->file, 0, buf, sizeof(buf));
+if (ret < 0) {
+return ret;
+}
+buf[2047] = '\0';
+if (vmdk_parse_description(buf, "createType", ct, sizeof(ct))) {
+return -EINVAL;
+}
+if (strcmp(ct, "monolithicFlat")) {
+fprintf(stderr,
+"VMDK: Not supported image type \"%s\""".\n", ct);
+return -ENOTSUP;
+}
+s->desc_offset = 0;
+ret = vmdk_parse_extents(buf, bs, bs->file->filename);
+if (ret) {
+return ret;
+}
+
+/* try to open parent images, if exist */
+if (vmdk_parent_open(bs)) {
+qemu_free(s->extents);
+return -EINVAL;
+}
+s->paren
[Qemu-devel] buildbot failure in qemu on block_x86_64_debian_5_0
The Buildbot has detected a new failure on builder block_x86_64_debian_5_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/block_x86_64_debian_5_0/builds/38 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_block' triggered this build Build Source Stamp: [branch block] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
[Qemu-devel] buildbot failure in qemu on block_i386_debian_5_0
The Buildbot has detected a new failure on builder block_i386_debian_5_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/block_i386_debian_5_0/builds/38 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_block' triggered this build Build Source Stamp: [branch block] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
[Qemu-devel] [PATCH v9 10/12] VMDK: create different subformats
Add create option 'format', with enums:
monolithicSparse
monolithicFlat
twoGbMaxExtentSparse
twoGbMaxExtentFlat
Each creates a subformat image file. The default is monolithicSparse.
Signed-off-by: Fam Zheng
---
block/vmdk.c | 503 +++--
block_int.h |1 +
2 files changed, 275 insertions(+), 229 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index e1fb962..b53c5f5 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -156,8 +156,9 @@ static int vmdk_probe(const uint8_t *buf, int buf_size,
const char *filename)
#define CHECK_CID 1
#define SECTOR_SIZE 512
-#define DESC_SIZE 20*SECTOR_SIZE // 20 sectors of 512 bytes each
-#define HEADER_SIZE 512// first sector of 512 bytes
+#define DESC_SIZE (20 * SECTOR_SIZE)/* 20 sectors of 512 bytes each */
+#define BUF_SIZE 4096
+#define HEADER_SIZE 512 /* first sector of 512 bytes */
static void vmdk_free_extents(BlockDriverState *bs)
{
@@ -243,168 +244,6 @@ static int vmdk_is_cid_valid(BlockDriverState *bs)
return 1;
}
-static int vmdk_snapshot_create(const char *filename, const char *backing_file)
-{
-int snp_fd, p_fd;
-int ret;
-uint32_t p_cid;
-char *p_name, *gd_buf, *rgd_buf;
-const char *real_filename, *temp_str;
-VMDK4Header header;
-uint32_t gde_entries, gd_size;
-int64_t gd_offset, rgd_offset, capacity, gt_size;
-char p_desc[DESC_SIZE], s_desc[DESC_SIZE], hdr[HEADER_SIZE];
-static const char desc_template[] =
-"# Disk DescriptorFile\n"
-"version=1\n"
-"CID=%x\n"
-"parentCID=%x\n"
-"createType=\"monolithicSparse\"\n"
-"parentFileNameHint=\"%s\"\n"
-"\n"
-"# Extent description\n"
-"RW %u SPARSE \"%s\"\n"
-"\n"
-"# The Disk Data Base \n"
-"#DDB\n"
-"\n";
-
-snp_fd = open(filename, O_RDWR | O_CREAT | O_TRUNC | O_BINARY |
O_LARGEFILE, 0644);
-if (snp_fd < 0)
-return -errno;
-p_fd = open(backing_file, O_RDONLY | O_BINARY | O_LARGEFILE);
-if (p_fd < 0) {
-close(snp_fd);
-return -errno;
-}
-
-/* read the header */
-if (lseek(p_fd, 0x0, SEEK_SET) == -1) {
-ret = -errno;
-goto fail;
-}
-if (read(p_fd, hdr, HEADER_SIZE) != HEADER_SIZE) {
-ret = -errno;
-goto fail;
-}
-
-/* write the header */
-if (lseek(snp_fd, 0x0, SEEK_SET) == -1) {
-ret = -errno;
-goto fail;
-}
-if (write(snp_fd, hdr, HEADER_SIZE) == -1) {
-ret = -errno;
-goto fail;
-}
-
-memset(&header, 0, sizeof(header));
-memcpy(&header,&hdr[4], sizeof(header)); // skip the VMDK4_MAGIC
-
-if (ftruncate(snp_fd, header.grain_offset << 9)) {
-ret = -errno;
-goto fail;
-}
-/* the descriptor offset = 0x200 */
-if (lseek(p_fd, 0x200, SEEK_SET) == -1) {
-ret = -errno;
-goto fail;
-}
-if (read(p_fd, p_desc, DESC_SIZE) != DESC_SIZE) {
-ret = -errno;
-goto fail;
-}
-
-if ((p_name = strstr(p_desc,"CID")) != NULL) {
-p_name += sizeof("CID");
-sscanf(p_name,"%x",&p_cid);
-}
-
-real_filename = filename;
-if ((temp_str = strrchr(real_filename, '\\')) != NULL)
-real_filename = temp_str + 1;
-if ((temp_str = strrchr(real_filename, '/')) != NULL)
-real_filename = temp_str + 1;
-if ((temp_str = strrchr(real_filename, ':')) != NULL)
-real_filename = temp_str + 1;
-
-snprintf(s_desc, sizeof(s_desc), desc_template, p_cid, p_cid, backing_file,
- (uint32_t)header.capacity, real_filename);
-
-/* write the descriptor */
-if (lseek(snp_fd, 0x200, SEEK_SET) == -1) {
-ret = -errno;
-goto fail;
-}
-if (write(snp_fd, s_desc, strlen(s_desc)) == -1) {
-ret = -errno;
-goto fail;
-}
-
-gd_offset = header.gd_offset * SECTOR_SIZE; // offset of GD table
-rgd_offset = header.rgd_offset * SECTOR_SIZE; // offset of RGD table
-capacity = header.capacity * SECTOR_SIZE; // Extent size
-/*
- * Each GDE span 32M disk, means:
- * 512 GTE per GT, each GTE points to grain
- */
-gt_size = (int64_t)header.num_gtes_per_gte * header.granularity *
SECTOR_SIZE;
-if (!gt_size) {
-ret = -EINVAL;
-goto fail;
-}
-gde_entries = (uint32_t)(capacity / gt_size); // number of gde/rgde
-gd_size = gde_entries * sizeof(uint32_t);
-
-/* write RGD */
-rgd_buf = qemu_malloc(gd_size);
-if (lseek(p_fd, rgd_offset, SEEK_SET) == -1) {
-ret = -errno;
-goto fail_rgd;
-}
-if (read(p_fd, rgd_buf, gd_size) != gd_size) {
-ret = -errno;
-goto fail_rgd;
-}
-if (lseek(snp_fd, rgd_offset, SEEK_SET) == -1) {
-ret = -errno;
-goto fail_rgd;
-}
-if (write(snp_fd, rgd_buf, gd_size) == -1) {
-ret = -errno;
-goto fail_rgd;
-}
-
-/* wr
Re: [Qemu-devel] [PATCH v9 00/12] Adding VMDK monolithic flat support
Hi,
Resent [09/12] and [10/12].
On Mon, Jul 18, 2011 at 10:52 PM, Kevin Wolf wrote:
> Am 12.07.2011 13:56, schrieb Fam Zheng:
>> Changes from v8:
>> 09/12: remove duplicated sscanf
>> 10/12: change option name to 'subformat', change commit message typo,
>> factor common parts of creating, and other small improvements
>>
>> Fam Zheng (12):
>> VMDK: introduce VmdkExtent
>> VMDK: bugfix, align offset to cluster in get_whole_cluster
>> VMDK: probe for monolithicFlat images
>> VMDK: separate vmdk_open by format version
>> VMDK: add field BDRVVmdkState.desc_offset
>> VMDK: flush multiple extents
>> VMDK: move 'static' cid_update flag to bs field
>> VMDK: change get_cluster_offset return type
>> VMDK: open/read/write for monolithicFlat image
>> VMDK: create different subformats
>> VMDK: fix coding style
>> block: add bdrv_get_allocated_file_size() operation
>>
>> block.c | 19 +
>> block.h | 1 +
>> block/raw-posix.c | 21 +
>> block/raw-win32.c | 29 ++
>> block/vmdk.c | 1296
>> -
>> block_int.h | 2 +
>> qemu-img.c | 31 +--
>> 7 files changed, 964 insertions(+), 435 deletions(-)
>
> This doesn't build for me:
>
> cc1: warnings being treated as errors
> block/vmdk.c: In function 'vmdk_parse_extents':
> block/vmdk.c:482: error: format '%lld' expects type 'long long int *',
> but argument 4 has type 'int64_t *'
> block/vmdk.c:482: error: format '%lld' expects type 'long long int *',
> but argument 7 has type 'int64_t *'
> block/vmdk.c: In function 'vmdk_create_extent':
> block/vmdk.c:1024: error: invalid storage class for function
> 'filename_decompose'
> [...]
>
> The following patch makes it compile. I haven't tried figuring out which
> patches need to be fixed, but should be easy enough for you. Please
> resend only those patches that need to be changed, I have already merged
> everything (plus my fixup) and will only update it in the block branch.
>
> Kevin
>
>
> diff --git a/block/vmdk.c b/block/vmdk.c
> index 63d7605..37478d2 100644
> --- a/block/vmdk.c
> +++ b/block/vmdk.c
> @@ -478,7 +478,7 @@ static int vmdk_parse_extents(const char *desc,
> BlockDriverState *bs,
> * RW [size in sectors] SPARSE "file-name.vmdk"
> */
> flat_offset = -1;
> - ret = sscanf(p, "%10s %lld %10s %511s %lld",
> + ret = sscanf(p, "%10s %" SCNd64 " %10s %511s %" SCNd64,
> access, §ors, type, fname, &flat_offset);
> if (ret < 4 || strcmp(access, "RW")) {
> goto next_line;
> @@ -927,6 +927,7 @@ static int vmdk_create_extent(const char *filename,
> int64_t filesize, bool flat)
> 0644);
> if (fd < 0) {
> return -errno;
> + }
> if (flat) {
> ret = ftruncate(fd, filesize);
> if (ret < 0) {
>
--
Best regards!
Fam Zheng
Re: [Qemu-devel] [PATCH] Fix duplicate device reset
Thank you for addressing this. Similar patches were proposed and weren't merged unfortunately. The reason why the qdev_register_reset() in vl.c is to keep the reset order. The reset for main_system_bus shouldn't registered by qbus_create_inplace(). But the check, bus != main_system_bus, doesn't work as intended because main_system_bus is NULL in early qdev creation. So there are possible ways for the fix. - Don't care the reset order your patch + remove "if (bus != main_system_bus)" in qbus_create_inplace() - keep the reset order - instantiate main_system_bus early. So the check, bus != main_system_bus in qbus_create_inplace(), will work. or - fix the check, bus != main_system_bus in qbus_create_inplace(), somehow thanks, On Mon, Jul 18, 2011 at 10:22:26PM +0200, Stefan Weil wrote: > qbus_reset_all_fn was registered twice, so a lot of device reset > functions were also called twice when QEMU started. > > It is sufficient to call sysbus_get_default() which will > register qbus_reset_all_fn. > > Signed-off-by: Stefan Weil > --- > vl.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/vl.c b/vl.c > index fcd7395..fb2f6db 100644 > --- a/vl.c > +++ b/vl.c > @@ -3301,7 +3301,7 @@ int main(int argc, char **argv, char **envp) > > /* TODO: once all bus devices are qdevified, this should be done > * when bus is created by qdev.c */ > -qemu_register_reset(qbus_reset_all_fn, sysbus_get_default()); > +sysbus_get_default(); > qemu_run_machine_init_done_notifiers(); > > qemu_system_reset(VMRESET_SILENT); > -- > 1.7.2.5 > -- yamahata
Re: [Qemu-devel] [Xen-devel] Upstream QEMU and Xen unstable not working
On Mon, 2011-07-18 at 11:03 +0100, Ian Campbell wrote: > On Mon, 2011-07-18 at 10:51 +0100, Wei Liu wrote: > > Bug resend. > > > > This bug was reported about one month ago. QEMU fails to start with > > Xen unstable. I found that it has not been fix with latest Xen > > unstable. BIOS is Seabios (with Xen patch). > > Please use current mainline seabios.git -- it does not require any > additional patches. > > http://wiki.xensource.com/xenwiki/QEMUUpstream also includes an updated > SeaBIOS .config which you might try. > > Ian. > Thanks Ian. This bug is fixed. But I spot new bug with Stefano's xen-next QEMU. --mainline seabios with xen-next-- (XEN) HVM7: HVM Loader (XEN) HVM7: Detected Xen v4.2-unstable (XEN) HVM7: Xenbus rings @0xfeffc000, event channel 2 (XEN) HVM7: System requested SeaBIOS (XEN) HVM7: CPU speed is 2993 MHz (XEN) irq.c:264: Dom7 PCI link 0 changed 0 -> 5 (XEN) HVM7: PCI-ISA link 0 routed to IRQ5 (XEN) irq.c:264: Dom7 PCI link 1 changed 0 -> 10 (XEN) HVM7: PCI-ISA link 1 routed to IRQ10 (XEN) irq.c:264: Dom7 PCI link 2 changed 0 -> 11 (XEN) HVM7: PCI-ISA link 2 routed to IRQ11 (XEN) irq.c:264: Dom7 PCI link 3 changed 0 -> 5 (XEN) HVM7: PCI-ISA link 3 routed to IRQ5 (XEN) HVM7: *** HVMLoader assertion '(devfn != PCI_ISA_DEVFN) || ((vendor_id == 0x8086) && (XEN) HVM7: (device_id == 0x7000))' failed at pci.c:78 (XEN) HVM7: *** HVMLoader crashed. If I use Anthony's old QEMU tree, qemu-dm-15, HVM boots up. But there are issues with irq binding. --mainline seabios with qemu-dm-15-- (XEN) irq.c:344: Dom6 callback via changed to Direct Vector 0xf3 (XEN) irq.c:1979: dom6: pirq 16 or emuirq 8 already mapped (XEN) irq.c:1979: dom6: pirq 16 or emuirq 12 already mapped (XEN) irq.c:1979: dom6: pirq 16 or emuirq 1 already mapped (XEN) irq.c:1979: dom6: pirq 16 or emuirq 6 already mapped (XEN) irq.c:1979: dom6: pirq 16 or emuirq 4 already mapped (XEN) irq.c:1979: dom6: pirq 16 or emuirq 7 already mapped (XEN) event_channel.c:341:d6 EVTCHNOP failure: error -17 (XEN) event_channel.c:341:d6 EVTCHNOP failure: error -17 (XEN) event_channel.c:341:d6 EVTCHNOP failure: error -17 (XEN) event_channel.c:341:d6 EVTCHNOP failure: error -17 Wei.
Re: [Qemu-devel] qemu FreeBSD/sparc64 host - a bit of debugging
On Mon, Jul 18, 2011 at 2:22 PM, Juergen Lock wrote: > Hi! > > I'm the FreeBSD qemu port maintainer and don't have a sparc64 box > myself, but Jashank Jeremy (Cc'd) now was so kind to test qemu 0.14.1 > on a FreeBSD/sparc64 box booting a FreeBSD 8/i386 install iso using > i386-softmmu What's the difference- an honest question- between this and a normal qemu boot? > and we found two things: > > 1. The hang people have been reporting seems to be caused by this tb: > >IN: >0x000e7a31: in $0xb3,%al >0x000e7a33: test %al,%al >0x000e7a35: jne0xe7a31 > > i.e. it (the qemu bios I suppose) is waiting for x86 ioport 0xb3 > to become zero. This port is #defined in hw/apm.c as: > >qemu-0.14.1/hw/apm.c:#define APM_STS_IOPORT 0xb3 > > but the definition seems to be used nowhere in that source file. > Anyone have an idea why this port is never zero on sparc64 hosts > but seems to be on others? (endian issue? uninitialized variable?) > Have you asked Whitehorn what it my be? > > 2. Booting the same guest with -no-acpi gets further, bios and > bootloader messages are printed until it hangs again, this > time while handling a guest irq 8 which seems to be rtc. > Is there a way of disabling the clock? If not, then would it be useful to set the emulated cpu speed? > > Maybe this is useful to some... :) > Actually, it's quite useful to me. > > Thanx, > Juergen > Thanks here the same.
[Qemu-devel] buildbot failure in qemu on xen_i386_debian_5_0
The Buildbot has detected a new failure on builder xen_i386_debian_5_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/xen_i386_debian_5_0/builds/38 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_xen' triggered this build Build Source Stamp: [branch xen-next] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
[Qemu-devel] buildbot failure in qemu on xen_x86_64_debian_5_0
The Buildbot has detected a new failure on builder xen_x86_64_debian_5_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/xen_x86_64_debian_5_0/builds/38 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_xen' triggered this build Build Source Stamp: [branch xen-next] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
Re: [Qemu-devel] [PATCH] Fix duplicate device reset
Am 19.07.2011 04:39, schrieb Isaku Yamahata: Thank you for addressing this. Similar patches were proposed and weren't merged unfortunately. The reason why the qdev_register_reset() in vl.c is to keep the reset order. The reset for main_system_bus shouldn't registered by qbus_create_inplace(). But the check, bus != main_system_bus, doesn't work as intended because main_system_bus is NULL in early qdev creation. So there are possible ways for the fix. - Don't care the reset order your patch + remove "if (bus != main_system_bus)" in qbus_create_inplace() - keep the reset order - instantiate main_system_bus early. So the check, bus != main_system_bus in qbus_create_inplace(), will work. or - fix the check, bus != main_system_bus in qbus_create_inplace(), somehow thanks, Hi, my patch does not remove sysbus_get_default(), so the reset order is kept because main_system_bus is instantiated by this call. Cheers, Stefan
Re: [Qemu-devel] failed migration makes monitor stuck
Ping? Anyone know this area of code? Can we just remove one monitor_resume() call from migrate_fd_put_buffer() ? 09.07.2011 15:07, Michael Tokarev wrote: > After some debugging I found a programming error in > error handling in migration, but I'm not sure how to > fix it. > > When migration starts, monitor gets suspended, calling > monitor_suspend() routine which increments assotiated > suspend_cnt counter. > > At the end of migration, in migrate_fd_cleanup(), > monitor_resume() gets called, which decrements the > counter. > > But monitor_resume() gets also called from another > place, in migrate_fd_put_buffer(), in case we > encountered a write error. > > So, suppose a tcp endpoint has disconnected, or the > exec: program terminated due to error or whatnot -- > in all these cases write will fail, and we'll call > monitor_resume() twice as a result: once in this > place in migrate_fd_put_buffer(), and once more at > the end in migrate_fd_cleanup(). > > This results in suspend_cnt being decremented twice, > with the resultant value being -1. > > So monitor_can_read() will return 0 from now on, since > it compares suspend_cnt with 0. And hence, monitor will > stop working. > > To me it looks like monitor_resume() call should be > removed from migrate_fd_put_buffer(), but I'm not sure > _why_ it were here in the first place. > > There's more: monitor_suspend() gets called from within > protocol handlers (using migrate_fd_monitor_suspend() > routine), -- are we sure that all current and future > protocol handlers will call this function? > > Thanks! > > /mjt >
Re: [Qemu-devel] [PATCH 0/4] scsi fixes
On 07/12/2011 03:37 PM, Kevin Wolf wrote: Am 11.07.2011 15:02, schrieb Hannes Reinecke: Hi all, these are some fixes I found during debugging my megasas HBA emulation. This time I've sent them as a separate patchset for inclusion. All of them have been acked, so please apply. Hannes Reinecke (4): iov: Update parameter usage in iov_(to|from)_buf() scsi: Add 'hba_private' to SCSIRequest scsi-disk: Fixup debugging statement scsi-disk: Mask out serial number EVPD Thanks, applied all to the block branch. Any chance to have them pulled into the main tree? My megasas emulation relies on them, and it feels a bit stupid to send a patch relying on some fixes not in mainline. At the same time it's really stupid to resend the entire patchset again ... Thanks. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
[Qemu-devel] buildbot failure in qemu on s390-next_i386_debian_5_0
The Buildbot has detected a new failure on builder s390-next_i386_debian_5_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/s390-next_i386_debian_5_0/builds/38 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_s390-next' triggered this build Build Source Stamp: [branch s390-next] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
[Qemu-devel] buildbot failure in qemu on s390-next_x86_64_debian_5_0
The Buildbot has detected a new failure on builder s390-next_x86_64_debian_5_0 while building qemu. Full details are available at: http://buildbot.b1-systems.de/qemu/builders/s390-next_x86_64_debian_5_0/builds/38 Buildbot URL: http://buildbot.b1-systems.de/qemu/ Buildslave for this Build: yuzuki Build Reason: The Nightly scheduler named 'nightly_s390-next' triggered this build Build Source Stamp: [branch s390-next] HEAD Blamelist: BUILD FAILED: failed git sincerely, -The Buildbot
