Re: [Qemu-devel] [PATCH v4 11/11] Exynos4210: added display controller implementation
Dear Dmitry, Thank you for feedback. As you probably know, there is some decision making process in large corporations. We'll discuss naming conventions on project meeting, make proposal, send it to peers, get approve and apply. Regards, Dmitry Solodkiy, Mobile SW PL, Advanced Software Group, Moscow RD center, Samsung Electronics -Original Message- From: Dmitry Zhurikhin [mailto:z...@ispras.ru] Sent: Wednesday, December 21, 2011 3:50 PM To: Evgeny Voevodin Cc: qemu-devel@nongnu.org; m.koz...@samsung.com; Mitsyanko Igor; d.solod...@samsung.com; Kirill Batuzov Subject: Re: [Qemu-devel] [PATCH v4 11/11] Exynos4210: added display controller implementation On 12/19/2011 03:53 PM, Evgeny Voevodin wrote: From: Mitsyanko Igor i.mitsya...@samsung.com Exynos4210 display controller (FIMD) has 5 hardware windows with alpha and chroma key blending functions. Signed-off-by: Evgeny Voevodin e.voevo...@samsung.com Hello! Nice work you've done there. Seeing you took our LCD implementation as a starting point I've got a small suggestion (don't consider it a blocker or anything) to make the names of your devices more generic. Glancing through the public documents Dmitry gave a link to I had a feeling that they are pretty much the same as used in S5C-based devices (and from my memory in S3C-based, at least SMDK6410, as well). What I noticed is that some new registers appeared in many devices like this one or ADC and keypad while documentation for most devices remained the same literally (I think only interrupt controller is much different from that used in S5PC110 and am not sure about DMA controller as it uses PL330's as well but seems in different configuration). This probably means and is logical that Samsung uses mostly the same basic devices for its SOCs. Then I think there is no point giving them device-specific names. How much Exynos4210-special details are coded here? Is it hard to separate them to support e.g. S5PC110 FIMD with the same device? Next year Samsung will come out with S6C, Exynos5210, F-something or whatever (you should know better) and it will feature once again the same basic devices with once again slightly updated interfaces. Then your colleagues who will work on implementing support of these boards in QEMU will either invent their own way of emulation for pretty much the same devices or will need to rename already present in QEMU ones to be used inside of their new board emulation. So what do you think about naming them more generic from the start? Dmitry
[Qemu-devel] [PATCH] w32: Build windows and console executables
System emulation executables with SDL are typically windows executables. Sometimes console executables are more useful, so create both variants if linker option -mwindows was detected. Signed-off-by: Stefan Weil s...@weilnetz.de --- Makefile.target | 14 ++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/Makefile.target b/Makefile.target index 3261383..489a80c 100644 --- a/Makefile.target +++ b/Makefile.target @@ -27,10 +27,19 @@ ifdef CONFIG_USER_ONLY QEMU_PROG=qemu-$(TARGET_ARCH2) else # system emulator name +ifneq (,$(findstring -mwindows,$(LIBS))) +# Terminate program name with a 'w' because the linker builds a windows executable. +QEMU_PROG=qemu-system-$(TARGET_ARCH2)w$(EXESUF) +QEMU_PROGC=qemu-system-$(TARGET_ARCH2)$(EXESUF) +else # windows executable QEMU_PROG=qemu-system-$(TARGET_ARCH2)$(EXESUF) +endif # windows executable endif PROGS=$(QEMU_PROG) +ifdef QEMU_PROGC +PROGS+=$(QEMU_PROGC) +endif STPFILES= ifndef CONFIG_HAIKU @@ -406,6 +415,11 @@ obj-$(CONFIG_GDBSTUB_XML) += gdbstub-xml.o $(QEMU_PROG): $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y) $(call LINK,$^) +ifdef QEMU_PROGC +# The linker built a windows executable. Make also a console executable. +$(QEMU_PROGC): $(QEMU_PROG) + $(call quiet-command,$(OBJCOPY) --subsystem console $(QEMU_PROG) $(QEMU_PROGC), GEN $(QEMU_PROGC)) +endif gdbstub-xml.c: $(TARGET_XML_FILES) $(SRC_PATH)/scripts/feature_to_c.sh $(call quiet-command,rm -f $@ $(SHELL) $(SRC_PATH)/scripts/feature_to_c.sh $@ $(TARGET_XML_FILES), GEN $(TARGET_DIR)$@) -- 1.7.0.4
Re: [Qemu-devel] Seem thread Competition
On Thu, Dec 22, 2011 at 10:13:50AM +0800, ZhouPeng wrote:
Hi,
I meet the err:
# virsh dumpxml 63
error: internal error cannot parse json {timestamp: {seconds:
1323332828, microseco{timest35p:39}, econds:PICE_D 1CO3233TE828,
Dmicrosec dsdata52}, : {ser: SPrCE_DISONNEC{ED, port: {serve
: {6299: 62, famiamily: ipv:, hist: pv41 hos6:
182.168.12.231}, 2lient.: {p2rt: 3350196, faily: }, cl,
ho{sport:t35020, : 19y: i2.4, 168.1.: 19}: lexical error:
invalid string in json text.
ds: 1323332828, microseco{timest35p:39}, econds:PICE_D
This similar bug seems has been reported by:
https://bugzilla.redhat.com/show_bug.cgi?id=744105
The patch(http://cgit.freedesktop.org/spice/qemu/commit/?h=spice.v42)
seems be related with the competition.
But I searched the upstream qemu, it has not been merged in.
My qemu is qemu-kvm-0.15.1 on 3.1.2-1.fc16.x86_64
Is there any plan about this bug, it seems be some serious.
The patch Daniel Berrange mentioned wotrked around it in qemu and is in
qemu 1.0-rc0 and onward, still checking qemu-kvm. There is another patch
in spice-0.10 and in 0.8, still need to check if it's in fedora. Which
version of spice are you using?
Thanks,
--
Zhou Peng
Re: [Qemu-devel] [PATCH] w32: Build windows and console executables
On Thu, Dec 22, 2011 at 16:03, Stefan Weil s...@weilnetz.de wrote: System emulation executables with SDL are typically windows executables. Sometimes console executables are more useful, so create both variants if linker option -mwindows was detected. Signed-off-by: Stefan Weil s...@weilnetz.de --- Makefile.target | 14 ++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/Makefile.target b/Makefile.target index 3261383..489a80c 100644 --- a/Makefile.target +++ b/Makefile.target @@ -27,10 +27,19 @@ ifdef CONFIG_USER_ONLY QEMU_PROG=qemu-$(TARGET_ARCH2) else # system emulator name +ifneq (,$(findstring -mwindows,$(LIBS))) +# Terminate program name with a 'w' because the linker builds a windows executable. +QEMU_PROG=qemu-system-$(TARGET_ARCH2)w$(EXESUF) +QEMU_PROGC=qemu-system-$(TARGET_ARCH2)$(EXESUF) +else # windows executable QEMU_PROG=qemu-system-$(TARGET_ARCH2)$(EXESUF) +endif # windows executable endif I prefer QEMU_PROG QEMU_PROGW. PROGS=$(QEMU_PROG) +ifdef QEMU_PROGC +PROGS+=$(QEMU_PROGC) +endif STPFILES= ifndef CONFIG_HAIKU @@ -406,6 +415,11 @@ obj-$(CONFIG_GDBSTUB_XML) += gdbstub-xml.o $(QEMU_PROG): $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y) $(call LINK,$^) +ifdef QEMU_PROGC +# The linker built a windows executable. Make also a console executable. +$(QEMU_PROGC): $(QEMU_PROG) + $(call quiet-command,$(OBJCOPY) --subsystem console $(QEMU_PROG) $(QEMU_PROGC), GEN $(QEMU_PROGC)) +endif gdbstub-xml.c: $(TARGET_XML_FILES) $(SRC_PATH)/scripts/feature_to_c.sh $(call quiet-command,rm -f $@ $(SHELL) $(SRC_PATH)/scripts/feature_to_c.sh $@ $(TARGET_XML_FILES), GEN $(TARGET_DIR)$@) -- 1.7.0.4
Re: [Qemu-devel] [PATCH v3 1/6] cutils: extract buffer_is_zero() from qemu-img.c
On Wed, Dec 21, 2011 at 09:43:55AM -0700, Eric Blake wrote: On 12/21/2011 09:00 AM, Stefan Hajnoczi wrote: The qemu-img.c:is_not_zero() function checks if a buffer contains all zeroes. This function will come in handy for zero-detection in the block layer, so clean it up and move it to cutils.c. Note that the function now returns true if the buffer is all zeroes. This avoids the double-negatives (i.e. !is_not_zero()) that the old function can cause in callers. Are there plans to improve the efficiency of buffer_is_zero to take advantage of metadata about sparseness? That is, there are cases where we can use metadata to prove a region of a file is sparse, without having to read every byte within that region. Now that this series is giving QED special metadata that marks a zero cluster, it is faster to query if that metadata exists denoting a zero cluster than it is to read the entire cluster and check for non-zero. Likewise, with regular files, the kernel provides lseek(SEEK_HOLE) (or the older, lower-level, ioctl(FS_IOC_FIEMAP)); which at least GNU coreutils is using for efficient sparse detection in source files. Yes, there are ways to optimize this for specific storage backends. But we need a code path that supports all storage systems first. For example, raw files over NFS or an image file over HTTP (curl). In the case of qcow2 or QED backing files we already don't read zeroes today. Instead we memset the read buffer to zero and the waste CPU cycles doing buffer_is_zero() detection. At least this means that file I/O (and network I/O, if using NFS) is already optimal if your backing file is qcow2 or QED - it's just the CPU cycles that we can optimize away. Stefan
Re: [Qemu-devel] [PATCH v3 2/6] block: add .bdrv_co_write_zeroes() interface
On Wed, Dec 21, 2011 at 05:50:32PM +0100, Christoph Hellwig wrote: On Wed, Dec 21, 2011 at 04:00:36PM +, Stefan Hajnoczi wrote: The ability to zero regions of an image file is a useful primitive for higher-level features such as image streaming or zero write detection. Image formats may support an optimized metadata representation instead of writing zeroes into the image file. This allows zero writes to be potentially faster than regular write operations and also preserve sparseness of the image file. The .bdrv_co_write_zeroes() interface should be implemented by block drivers that wish to provide efficient zeroing. Note that this operation is different from the discard operation, which may leave the contents of the region indeterminate. That means discarded blocks are not guaranteed to contain zeroes and may contain junk data instead. Most real life discard operations zero the data, and both the ATA and SCSI spec allow the device to set a bit which gurantees this behaviour. I think we also should make these one interface, and if the caller needs it to actually zero out the discarded blocks it should check if the discard implementation guarantees that. Okay, I see how that could work but still need to look into the details of how to combine the two and check the zero/indeterminate bit coming from ATA/SCSI. Stefan
Re: [Qemu-devel] Seem thread Competition
On Thu, Dec 22, 2011 at 4:42 PM, Alon Levy al...@redhat.com wrote:
On Thu, Dec 22, 2011 at 10:13:50AM +0800, ZhouPeng wrote:
Hi,
I meet the err:
# virsh dumpxml 63
error: internal error cannot parse json {timestamp: {seconds:
1323332828, microseco{timest35p:39}, econds:PICE_D 1CO3233TE828,
Dmicrosec dsdata52}, : {ser: SPrCE_DISONNEC{ED, port: {serve
: {6299: 62, famiamily: ipv:, hist: pv41 hos6:
182.168.12.231}, 2lient.: {p2rt: 3350196, faily: }, cl,
ho{sport:t35020, : 19y: i2.4, 168.1.: 19}: lexical error:
invalid string in json text.
ds: 1323332828, microseco{timest35p:39}, econds:PICE_D
This similar bug seems has been reported by:
https://bugzilla.redhat.com/show_bug.cgi?id=744105
The patch(http://cgit.freedesktop.org/spice/qemu/commit/?h=spice.v42)
seems be related with the competition.
But I searched the upstream qemu, it has not been merged in.
My qemu is qemu-kvm-0.15.1 on 3.1.2-1.fc16.x86_64
Is there any plan about this bug, it seems be some serious.
The patch Daniel Berrange mentioned wotrked around it in qemu and is in
qemu 1.0-rc0 and onward, still checking qemu-kvm. There is another patch
Yea, I searched in spice-core.c again and the patch is in qemu unstable
Sorry, I carelessly search by me but not me; before.
in spice-0.10 and in 0.8, still need to check if it's in fedora. Which
version of spice are you using?
spice-server.x86_64 version 0.9.1
Thanks Alon,
--
Zhou Peng
[Qemu-devel] usb-ohci: td.cbp incorrectly updated near page end
The current code that updates the cbp value after a transfer looks like this:
td.cbp += ret;
if ((td.cbp 0xfff) + ret 0xfff) {
handle page overflow
because the 'ret' value is effectively added twice the check may fire too early
when the overflow hasn't happened yet.
Below is one of the possible changes that correct the behavior:
--- hw/usb-ohci.c.orig 2011-12-22 02:44:49.650537164 +0200
+++ hw/usb-ohci.c 2011-12-22 03:50:37.545642734 +0200
@@ -1025,10 +1031,10 @@ static int ohci_service_td(OHCIState *oh
if (ret == len) {
td.cbp = 0;
} else {
-td.cbp += ret;
if ((td.cbp 0xfff) + ret 0xfff) {
-td.cbp = 0xfff;
-td.cbp |= td.be ~0xfff;
+td.cbp = (td.be ~0xfff) + ((td.cbp + ret) 0xfff);
+} else {
+td.cbp += ret;
}
}
td.flags |= OHCI_TD_T1;
--
Andriy Gapon
Re: [Qemu-devel] [Bug 883136] Re: qemu on ARM hosts aborts on startup because makecontext() always fails
On Wed, Dec 21, 2011 at 5:42 PM, Dr. David Alan Gilbert 883...@bugs.launchpad.net wrote: Attached is a 1st cut of a makecontext/setcontext/getcontext/swapcontext set for ARM - not ready to go into libc yet; currently it builds standalone and links (and passes) with a test of mine. Next stop libc and a lot of cleanup. Excellent. There is a stand-alone QEMU coroutine test which you can build with make test-coroutine. Stefan
Re: [Qemu-devel] VMDK: footer must take precedence over header when present
On Wed, Dec 21, 2011 at 11:34 PM, B Gordon bbgord...@fastmail.fm wrote: VMDK: footer must take precedence over header when present In e.g. streamOptimized VMDKs from VSphere 4 with this flag set the header l1_table is bogus and only the footer l1_table can be used to correctly read extents. Also reverts recent change to VMDK4Header so order of rgd_ and gd_offset matches the VMDK spec. Hi Fam, In commit bb45ded93115ad4303471c9a492579dc36716547 you moved the rgd_offset field after gd_offset. The VMDK spec has the rgd_offset field before gd_offset. Could you please review B.B. Gordon's patch which reverts this change and implements the header/footer precedence described in the Header and Footer section for Stream-Optimized Compressed Sparse Extents? If you still have the .vmdk files you tested against it would be interesting to verify that applying this new patch doesn't break them. http://patchwork.ozlabs.org/patch/132758/ Thanks, Stefan
Re: [Qemu-devel] Seem thread Competition
On Thu, Dec 22, 2011 at 05:42:29PM +0800, ZhouPeng wrote:
On Thu, Dec 22, 2011 at 4:42 PM, Alon Levy al...@redhat.com wrote:
On Thu, Dec 22, 2011 at 10:13:50AM +0800, ZhouPeng wrote:
Hi,
I meet the err:
# virsh dumpxml 63
error: internal error cannot parse json {timestamp: {seconds:
1323332828, microseco{timest35p:39}, econds:PICE_D 1CO3233TE828,
Dmicrosec dsdata52}, : {ser: SPrCE_DISONNEC{ED, port: {serve
: {6299: 62, famiamily: ipv:, hist: pv41 hos6:
182.168.12.231}, 2lient.: {p2rt: 3350196, faily: }, cl,
ho{sport:t35020, : 19y: i2.4, 168.1.: 19}: lexical error:
invalid string in json text.
ds: 1323332828, microseco{timest35p:39}, econds:PICE_D
This similar bug seems has been reported by:
https://bugzilla.redhat.com/show_bug.cgi?id=744105
The patch(http://cgit.freedesktop.org/spice/qemu/commit/?h=spice.v42)
seems be related with the competition.
But I searched the upstream qemu, it has not been merged in.
My qemu is qemu-kvm-0.15.1 on 3.1.2-1.fc16.x86_64
Is there any plan about this bug, it seems be some serious.
The patch Daniel Berrange mentioned wotrked around it in qemu and is in
qemu 1.0-rc0 and onward, still checking qemu-kvm. There is another patch
Yea, I searched in spice-core.c again and the patch is in qemu unstable
Sorry, I carelessly search by me but not me; before.
It is in qemu-kvm-1.0 as well. But like you said fedora carries 0.15.1
that doesn't have it.
in spice-0.10 and in 0.8, still need to check if it's in fedora. Which
version of spice are you using?
spice-server.x86_64 version 0.9.1
which doesn't have the spice side fix. but 0.10.0 has it, and it is
closest to 0.9.1. I assume this is from the fedora package as well since
you mentioned qemu-kvm is from a fedora package? seems the latest is
indeed 0.9.1-1, can you test
http://koji.fedoraproject.org/koji/buildinfo?buildID=273917
(spice-server-0.10.0-1)?
Thanks Alon,
--
Zhou Peng
Re: [Qemu-devel] [PATCH 3/9] arm: add missing v7 cp15 registers
On 12/21/2011 11:10 PM, Peter Maydell wrote: On 21 December 2011 16:37, Mark Langsdorf mark.langsd...@calxeda.com wrote: On 12/20/2011 01:48 PM, Peter Maydell wrote: This commit leaves the register with a reset value of 0, which isn't right (we only implement A9MP, not A9UP, so the reset value should be settable by the board at init time somehow depending where the a9mpcore_priv device is mapped. Not sure what the cleanest way to do that is.) I can add a DEFINE_PROP_UINT32 to a9mpcore_priv, which would give anyone who wants to set the property an easy way to do so. I'm not sure how to hook the a9mpcore_priv to the CPUARMState, though. They don't appear to reference each other. Yes, we don't really model the private peripherals very sensibly: they should be an integral part of the CPU but for historical reasons they've been done as a totally separate device. I don't think a property is the right thing, though -- ideally the a9mpcore device should be able to find out for itself where it was mapped. Avi: is there a way for a device (sysbus device in this case) to find out for one of its memory regions where it has been mapped in the address space? Where and if. The context here is that the Cortex-A9 has a cp15 register whose value is base address of the private peripherals, and it would be nice not to have to have boards saying both map mmio region at X and set property so register reads as X... [You could argue that hardware implementations have to do the equivalent of both of these things separately, I suppose, but it's still not very pretty.] I don't really follow, can you explain? Anyway, with the new MemoryListener API (not yet merged), you can register a callback to be called when MemoryRegions become visible or invisible. You can filter there for your pet region and get all the info about it. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH v2] w32: Build windows and console executables
System emulation executables with SDL are typically windows executables. Sometimes console executables are more useful, so create both variants if linker option -mwindows was detected. v2: This version uses QEMU_PROGW / QEMU_PROG instead of QEMU_PROG / QEMU_PROGC. Signed-off-by: Stefan Weil s...@weilnetz.de --- Makefile.target | 16 +++- 1 files changed, 15 insertions(+), 1 deletions(-) diff --git a/Makefile.target b/Makefile.target index 3261383..0182e41 100644 --- a/Makefile.target +++ b/Makefile.target @@ -27,10 +27,17 @@ ifdef CONFIG_USER_ONLY QEMU_PROG=qemu-$(TARGET_ARCH2) else # system emulator name +ifneq (,$(findstring -mwindows,$(LIBS))) +# Terminate program name with a 'w' because the linker builds a windows executable. +QEMU_PROGW=qemu-system-$(TARGET_ARCH2)w$(EXESUF) +endif # windows executable QEMU_PROG=qemu-system-$(TARGET_ARCH2)$(EXESUF) endif PROGS=$(QEMU_PROG) +ifdef QEMU_PROGW +PROGS+=$(QEMU_PROGW) +endif STPFILES= ifndef CONFIG_HAIKU @@ -403,9 +410,16 @@ endif # CONFIG_LINUX_USER obj-$(CONFIG_GDBSTUB_XML) += gdbstub-xml.o +ifdef QEMU_PROGW +# The linker builds a windows executable. Make also a console executable. +$(QEMU_PROGW): $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y) + $(call LINK,$^) +$(QEMU_PROG): $(QEMU_PROGW) + $(call quiet-command,$(OBJCOPY) --subsystem console $(QEMU_PROGW) $(QEMU_PROG), GEN $(TARGET_DIR)$(QEMU_PROG)) +else $(QEMU_PROG): $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y) $(call LINK,$^) - +endif gdbstub-xml.c: $(TARGET_XML_FILES) $(SRC_PATH)/scripts/feature_to_c.sh $(call quiet-command,rm -f $@ $(SHELL) $(SRC_PATH)/scripts/feature_to_c.sh $@ $(TARGET_XML_FILES), GEN $(TARGET_DIR)$@) -- 1.7.2.5
[Qemu-devel] [PATCH] configure: CONFIG_QEMU_INTERP_PREFIX only for user mode
Signed-off-by: Stefan Weil s...@weilnetz.de --- configure |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure b/configure index 640e815..af19391 100755 --- a/configure +++ b/configure @@ -3395,7 +3395,6 @@ echo # Automatically generated by configure - do not modify $config_target_m bflt=no target_nptl=no interp_prefix1=`echo $interp_prefix | sed s/%M/$target_arch2/g` -echo CONFIG_QEMU_INTERP_PREFIX=\$interp_prefix1\ $config_target_mak gdb_xml_files= target_short_alignment=2 target_int_alignment=4 @@ -3601,6 +3600,7 @@ if test $target_softmmu = yes ; then fi if test $target_user_only = yes ; then echo CONFIG_USER_ONLY=y $config_target_mak + echo CONFIG_QEMU_INTERP_PREFIX=\$interp_prefix1\ $config_target_mak fi if test $target_linux_user = yes ; then echo CONFIG_LINUX_USER=y $config_target_mak -- 1.7.2.5
[Qemu-devel] [PATCH 0/3] Trivial patches for 20 to 22 December 2011
The last trivial-patches pull request before I head off on vacation. I'll be back on the 30th of December. Happy holidays! The following changes since commit 03ecd2c80a64d030a22fe67cc7a60f24e17ff211: virtio-serial-bus: Ports are expected to implement 'have_data' callback (2011-12-21 15:00:29 -0600) are available in the git repository at: personal_github:stefanha/qemu.git trivial-patches Alon Levy (1): qemu-options.hx: fix tls-channel help text Markus Armbruster (2): Strip trailing '\n' from error_report()'s first argument (again) scsi virtio-blk usb-msd: Clean up device init error messages hw/scsi-disk.c|4 ++-- hw/scsi-generic.c |8 hw/usb-bus.c | 12 ++-- hw/usb-msd.c |2 +- hw/virtio-blk.c |2 +- qemu-options.hx |4 ++-- usb-redir.c |4 ++-- 7 files changed, 18 insertions(+), 18 deletions(-) -- 1.7.7.3
[Qemu-devel] [PATCH 1/3] qemu-options.hx: fix tls-channel help text
From: Alon Levy al...@redhat.com Remove the default compiled out tunnel channel, add the always available cursor channel. Optimally the man page would depend on compiled in options, but that's harder to do. RHBZ: 688586 Acked-by: Gerd Hoffmann kra...@redhat.com Signed-off-by: Alon Levy al...@redhat.com Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com --- qemu-options.hx |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/qemu-options.hx b/qemu-options.hx index a60191f..3c3bda8 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -857,8 +857,8 @@ The x509 file names can also be configured individually. @item tls-ciphers=list Specify which ciphers to use. -@item tls-channel=[main|display|inputs|record|playback|tunnel] -@item plaintext-channel=[main|display|inputs|record|playback|tunnel] +@item tls-channel=[main|display|cursor|inputs|record|playback] +@item plaintext-channel=[main|display|cursor|inputs|record|playback] Force specific channel to be used with or without TLS encryption. The options can be specified multiple times to configure multiple channels. The special name default can be used to set the default -- 1.7.7.3
[Qemu-devel] [PATCH 2/3] Strip trailing '\n' from error_report()'s first argument (again)
From: Markus Armbruster arm...@redhat.com
Commit 6daf194d got rid of them, but Hans and Gerd added some more
lately. Tracked down with this Coccinelle semantic patch:
@r@
expression fmt;
position p;
@@
error_report(fmt, ...)@p
@script:python@
fmt r.fmt;
p r.p;
@@
if \\n in str(fmt):
print %s:%s:%s:%s % (p[0].file, p[0].line, p[0].column, fmt)
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/usb-bus.c | 12 ++--
usb-redir.c |4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index 8203390..bd4afa7 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
@@ -137,7 +137,7 @@ USBDevice *usb_create(USBBus *bus, const char *name)
bus = usb_bus_find(-1);
if (!bus)
return NULL;
-error_report(%s: no bus specified, using \%s\ for \%s\\n,
+error_report(%s: no bus specified, using \%s\ for \%s\,
__FUNCTION__, bus-qbus.name, name);
}
#endif
@@ -152,12 +152,12 @@ USBDevice *usb_create_simple(USBBus *bus, const char
*name)
int rc;
if (!dev) {
-error_report(Failed to create USB device '%s'\n, name);
+error_report(Failed to create USB device '%s', name);
return NULL;
}
rc = qdev_init(dev-qdev);
if (rc 0) {
-error_report(Failed to initialize USB device '%s'\n, name);
+error_report(Failed to initialize USB device '%s', name);
return NULL;
}
return dev;
@@ -244,7 +244,7 @@ int usb_claim_port(USBDevice *dev)
}
}
if (port == NULL) {
-error_report(Error: usb port %s (bus %s) not found (in use?)\n,
+error_report(Error: usb port %s (bus %s) not found (in use?),
dev-port_path, bus-qbus.name);
return -1;
}
@@ -255,7 +255,7 @@ int usb_claim_port(USBDevice *dev)
}
if (bus-nfree == 0) {
error_report(Error: tried to attach usb device %s to a bus
- with no free ports\n, dev-product_desc);
+ with no free ports, dev-product_desc);
return -1;
}
port = QTAILQ_FIRST(bus-free);
@@ -302,7 +302,7 @@ int usb_device_attach(USBDevice *dev)
if (!(port-speedmask dev-speedmask)) {
error_report(Warning: speed mismatch trying to attach
- usb device %s to bus %s\n,
+ usb device %s to bus %s,
dev-product_desc, bus-qbus.name);
return -1;
}
diff --git a/usb-redir.c b/usb-redir.c
index a36f2a7..2b53cf3 100644
--- a/usb-redir.c
+++ b/usb-redir.c
@@ -174,7 +174,7 @@ static void usbredir_log(void *priv, int level, const char
*msg)
return;
}
-error_report(%s\n, msg);
+error_report(%s, msg);
}
static void usbredir_log_data(USBRedirDevice *dev, const char *desc,
@@ -193,7 +193,7 @@ static void usbredir_log_data(USBRedirDevice *dev, const
char *desc,
for (j = 0; j 8 i + j len; j++) {
n += sprintf(buf + n, %02X, data[i + j]);
}
-error_report(%s\n, buf);
+error_report(%s, buf);
}
}
--
1.7.7.3
[Qemu-devel] [PATCH 3/3] scsi virtio-blk usb-msd: Clean up device init error messages
From: Markus Armbruster arm...@redhat.com
Replace
error_report(DEVICE-NAME: MESSAGE);
by just
error_report(MESSAGE);
in block device init functions.
DEVICE-NAME is bogus in some cases: it's scsi-disk for device
scsi-hd and scsi-cd, virtio-blk-pci for virtio-blk-s390, and
usb-msd for usb-storage.
There is no real need to put a device name in the message, because
error_report() points to the offending command line option already:
$ qemu-system-x86_64 --nodefaults --enable-kvm -vnc :0 -S -monitor stdio -usb
-device virtio-blk-pci
upstream-qemu: -device virtio-blk-pci: virtio-blk-pci: drive property not set
upstream-qemu: -device virtio-blk-pci: Device 'virtio-blk-pci' could not be
initialized
And for a monitor command, it's obvious anyway:
$ qemu-system-x86_64 --nodefaults --enable-kvm -vnc :0 -S -monitor stdio -usb
(qemu) device_add virtio-blk-pci
virtio-blk-pci: drive property not set
Device 'virtio-blk-pci' could not be initialized
Reported-by: Amit Shah amit.s...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
hw/scsi-disk.c|4 ++--
hw/scsi-generic.c |8
hw/usb-msd.c |2 +-
hw/virtio-blk.c |2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 505accd..5d8bf53 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -1515,7 +1515,7 @@ static int scsi_initfn(SCSIDevice *dev)
DriveInfo *dinfo;
if (!s-qdev.conf.bs) {
-error_report(scsi-disk: drive property not set);
+error_report(drive property not set);
return -1;
}
@@ -1537,7 +1537,7 @@ static int scsi_initfn(SCSIDevice *dev)
}
if (bdrv_is_sg(s-qdev.conf.bs)) {
-error_report(scsi-disk: unwanted /dev/sg*);
+error_report(unwanted /dev/sg*);
return -1;
}
diff --git a/hw/scsi-generic.c b/hw/scsi-generic.c
index 6f7d3db..0aebcdd 100644
--- a/hw/scsi-generic.c
+++ b/hw/scsi-generic.c
@@ -374,13 +374,13 @@ static int scsi_generic_initfn(SCSIDevice *s)
struct sg_scsi_id scsiid;
if (!s-conf.bs) {
-error_report(scsi-generic: drive property not set);
+error_report(drive property not set);
return -1;
}
/* check we are really using a /dev/sg* file */
if (!bdrv_is_sg(s-conf.bs)) {
-error_report(scsi-generic: not /dev/sg*);
+error_report(not /dev/sg*);
return -1;
}
@@ -396,13 +396,13 @@ static int scsi_generic_initfn(SCSIDevice *s)
/* check we are using a driver managing SG_IO (version 3 and after */
if (bdrv_ioctl(s-conf.bs, SG_GET_VERSION_NUM, sg_version) 0 ||
sg_version 3) {
-error_report(scsi-generic: scsi generic interface too old);
+error_report(scsi generic interface too old);
return -1;
}
/* get LUN of the /dev/sg? */
if (bdrv_ioctl(s-conf.bs, SG_GET_SCSI_ID, scsiid)) {
-error_report(scsi-generic: SG_GET_SCSI_ID ioctl failed);
+error_report(SG_GET_SCSI_ID ioctl failed);
return -1;
}
diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index 4c06950..b87b929 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -517,7 +517,7 @@ static int usb_msd_initfn(USBDevice *dev)
DriveInfo *dinfo;
if (!bs) {
-error_report(usb-msd: drive property not set);
+error_report(drive property not set);
return -1;
}
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index ef27421..5e81f53 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -569,7 +569,7 @@ VirtIODevice *virtio_blk_init(DeviceState *dev, BlockConf
*conf,
DriveInfo *dinfo;
if (!conf-bs) {
-error_report(virtio-blk-pci: drive property not set);
+error_report(drive property not set);
return NULL;
}
if (!bdrv_is_inserted(conf-bs)) {
--
1.7.7.3
Re: [Qemu-devel] [Spice-devel] Seem thread Competition
On Thu, Dec 22, 2011 at 10:00:18AM +, Alon Levy wrote:
On Thu, Dec 22, 2011 at 05:42:29PM +0800, ZhouPeng wrote:
On Thu, Dec 22, 2011 at 4:42 PM, Alon Levy al...@redhat.com wrote:
On Thu, Dec 22, 2011 at 10:13:50AM +0800, ZhouPeng wrote:
Hi,
I meet the err:
# virsh dumpxml 63
error: internal error cannot parse json {timestamp: {seconds:
1323332828, microseco{timest35p:39}, econds:PICE_D 1CO3233TE828,
Dmicrosec dsdata52}, : {ser: SPrCE_DISONNEC{ED, port: {serve
: {6299: 62, famiamily: ipv:, hist: pv41 hos6:
182.168.12.231}, 2lient.: {p2rt: 3350196, faily: }, cl,
ho{sport:t35020, : 19y: i2.4, 168.1.: 19}: lexical error:
invalid string in json text.
ds: 1323332828, microseco{timest35p:39}, econds:PICE_D
This similar bug seems has been reported by:
https://bugzilla.redhat.com/show_bug.cgi?id=744105
The patch(http://cgit.freedesktop.org/spice/qemu/commit/?h=spice.v42)
seems be related with the competition.
But I searched the upstream qemu, it has not been merged in.
My qemu is qemu-kvm-0.15.1 on 3.1.2-1.fc16.x86_64
Is there any plan about this bug, it seems be some serious.
The patch Daniel Berrange mentioned wotrked around it in qemu and is in
qemu 1.0-rc0 and onward, still checking qemu-kvm. There is another patch
Yea, I searched in spice-core.c again and the patch is in qemu unstable
Sorry, I carelessly search by me but not me; before.
It is in qemu-kvm-1.0 as well. But like you said fedora carries 0.15.1
that doesn't have it.
in spice-0.10 and in 0.8, still need to check if it's in fedora. Which
version of spice are you using?
spice-server.x86_64 version 0.9.1
which doesn't have the spice side fix. but 0.10.0 has it, and it is
closest to 0.9.1. I assume this is from the fedora package as well since
you mentioned qemu-kvm is from a fedora package? seems the latest is
indeed 0.9.1-1, can you test
http://koji.fedoraproject.org/koji/buildinfo?buildID=273917
(spice-server-0.10.0-1)?
If you find it fixes your problem and doesn't introduce any new ones
please +1 spice-0.10.0-1.fc16 at
https://admin.fedoraproject.org/updates/spice-0.10.0-1.fc16
Thanks,
Alon
Thanks Alon,
--
Zhou Peng
___
Spice-devel mailing list
spice-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Qemu-devel] Seem thread Competition
On Thu, Dec 22, 2011 at 6:00 PM, Alon Levy al...@redhat.com wrote:
On Thu, Dec 22, 2011 at 05:42:29PM +0800, ZhouPeng wrote:
On Thu, Dec 22, 2011 at 4:42 PM, Alon Levy al...@redhat.com wrote:
On Thu, Dec 22, 2011 at 10:13:50AM +0800, ZhouPeng wrote:
Hi,
I meet the err:
# virsh dumpxml 63
error: internal error cannot parse json {timestamp: {seconds:
1323332828, microseco{timest35p:39}, econds:PICE_D 1CO3233TE828,
Dmicrosec dsdata52}, : {ser: SPrCE_DISONNEC{ED, port: {serve
: {6299: 62, famiamily: ipv:, hist: pv41 hos6:
182.168.12.231}, 2lient.: {p2rt: 3350196, faily: }, cl,
ho{sport:t35020, : 19y: i2.4, 168.1.: 19}: lexical error:
invalid string in json text.
ds: 1323332828, microseco{timest35p:39}, econds:PICE_D
This similar bug seems has been reported by:
https://bugzilla.redhat.com/show_bug.cgi?id=744105
The patch(http://cgit.freedesktop.org/spice/qemu/commit/?h=spice.v42)
seems be related with the competition.
But I searched the upstream qemu, it has not been merged in.
My qemu is qemu-kvm-0.15.1 on 3.1.2-1.fc16.x86_64
Is there any plan about this bug, it seems be some serious.
The patch Daniel Berrange mentioned wotrked around it in qemu and is in
qemu 1.0-rc0 and onward, still checking qemu-kvm. There is another patch
Yea, I searched in spice-core.c again and the patch is in qemu unstable
Sorry, I carelessly search by me but not me; before.
It is in qemu-kvm-1.0 as well. But like you said fedora carries 0.15.1
that doesn't have it.
in spice-0.10 and in 0.8, still need to check if it's in fedora. Which
version of spice are you using?
spice-server.x86_64 version 0.9.1
which doesn't have the spice side fix. but 0.10.0 has it, and it is
closest to 0.9.1. I assume this is from the fedora package as well since
you mentioned qemu-kvm is from a fedora package? seems the latest is
indeed 0.9.1-1, can you test
http://koji.fedoraproject.org/koji/buildinfo?buildID=273917
(spice-server-0.10.0-1)?
[root@localhost ~]# rpm -i spice-server-0.10.0-1.fc16.x86_64.rpm
file /usr/lib64/libspice-server.so.1.0.2 from install of
spice-server-0.10.0-1.fc16.x86_64 conflicts with file from package
spice-server-0.9.1-1.fc16.x86_64
So I force install
rpm -i --force spice-server-0.10.0-1.fc16.x86_64.rpm
yum list installed:
spice-server.x86_64 0.9.1-1.fc16 @anaconda-0
spice-server.x86_64 0.10.0-1.fc16installed
0.9.1-1.fc16 seems not be overrided.
So first, I am not sure qemu-kvm will use 0.10.0-1.fc16 or 0.9.1-1.fc16
Second, this is a random bug, I am not sure when it will appear again.
--
Zhou Peng
[Qemu-devel] [PATCH 3/5] usb-redir: Pre-fill our isoc input buffer before sending pkts to the host
This is something which should have been done from the first version of
usb-redir, but wasn't.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
usb-redir.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/usb-redir.c b/usb-redir.c
index 0a1157b..0658076 100644
--- a/usb-redir.c
+++ b/usb-redir.c
@@ -60,7 +60,9 @@ struct endp_data {
uint8_t iso_error; /* For reporting iso errors to the HC */
uint8_t interrupt_started;
uint8_t interrupt_error;
+uint8_t bufpq_prefilled;
QTAILQ_HEAD(, buf_packet) bufpq;
+int bufpq_size;
int bufpq_target_size;
};
@@ -306,6 +308,7 @@ static struct buf_packet *bufp_alloc(USBRedirDevice *dev,
bufp-len= len;
bufp-status = status;
QTAILQ_INSERT_TAIL(dev-endpoint[EP2I(ep)].bufpq, bufp, next);
+dev-endpoint[EP2I(ep)].bufpq_size++;
return bufp;
}
@@ -313,6 +316,7 @@ static void bufp_free(USBRedirDevice *dev, struct
buf_packet *bufp,
uint8_t ep)
{
QTAILQ_REMOVE(dev-endpoint[EP2I(ep)].bufpq, bufp, next);
+dev-endpoint[EP2I(ep)].bufpq_size--;
free(bufp-data);
g_free(bufp);
}
@@ -383,14 +387,26 @@ static int usbredir_handle_iso_data(USBRedirDevice *dev,
USBPacket *p,
usbredirparser_do_write(dev-parser);
DPRINTF(iso stream started ep %02X\n, ep);
dev-endpoint[EP2I(ep)].iso_started = 1;
+dev-endpoint[EP2I(ep)].bufpq_prefilled = 0;
}
if (ep USB_DIR_IN) {
struct buf_packet *isop;
+if (dev-endpoint[EP2I(ep)].iso_started
+!dev-endpoint[EP2I(ep)].bufpq_prefilled) {
+if (dev-endpoint[EP2I(ep)].bufpq_size
+dev-endpoint[EP2I(ep)].bufpq_target_size) {
+return usbredir_handle_status(dev, 0, 0);
+}
+dev-endpoint[EP2I(ep)].bufpq_prefilled = 1;
+}
+
isop = QTAILQ_FIRST(dev-endpoint[EP2I(ep)].bufpq);
if (isop == NULL) {
DPRINTF2(iso-token-in ep %02X, no isop\n, ep);
+/* Re-fill the buffer */
+dev-endpoint[EP2I(ep)].bufpq_prefilled = 0;
/* Check iso_error for stream errors, otherwise its an underrun */
status = dev-endpoint[EP2I(ep)].iso_error;
dev-endpoint[EP2I(ep)].iso_error = 0;
--
1.7.7.4
[Qemu-devel] [PATCH 2/5] usb-redir: Dynamically adjust iso buffering size based on ep interval
Note the bufpq_target_size id stored in the endpoint info struct,
even though it only used once. This is done because it will be
referenced from other code in a follow up patch.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
usb-redir.c | 52 +++-
1 files changed, 47 insertions(+), 5 deletions(-)
diff --git a/usb-redir.c b/usb-redir.c
index 477c609..0a1157b 100644
--- a/usb-redir.c
+++ b/usb-redir.c
@@ -61,6 +61,7 @@ struct endp_data {
uint8_t interrupt_started;
uint8_t interrupt_error;
QTAILQ_HEAD(, buf_packet) bufpq;
+int bufpq_target_size;
};
struct USBRedirDevice {
@@ -342,15 +343,41 @@ static int usbredir_handle_iso_data(USBRedirDevice *dev,
USBPacket *p,
uint8_t ep)
{
int status, len;
-
if (!dev-endpoint[EP2I(ep)].iso_started
!dev-endpoint[EP2I(ep)].iso_error) {
struct usb_redir_start_iso_stream_header start_iso = {
.endpoint = ep,
-/* TODO maybe do something with these depending on ep interval? */
-.pkts_per_urb = 32,
-.no_urbs = 3,
};
+int pkts_per_sec;
+
+if (dev-dev.speed == USB_SPEED_HIGH)
+pkts_per_sec = 8000 / dev-endpoint[EP2I(ep)].interval;
+else
+pkts_per_sec = 1000 / dev-endpoint[EP2I(ep)].interval;
+/* Testing has shown that we need circa 60 ms buffer */
+dev-endpoint[EP2I(ep)].bufpq_target_size = (pkts_per_sec * 60) / 1000;
+
+/* Aim for approx 100 interrupts / second on the client to
+ balance latency and interrupt load */
+start_iso.pkts_per_urb = pkts_per_sec / 100;
+if (start_iso.pkts_per_urb 1) {
+start_iso.pkts_per_urb = 1;
+} else if (start_iso.pkts_per_urb 32) {
+start_iso.pkts_per_urb = 32;
+}
+
+start_iso.no_urbs = (dev-endpoint[EP2I(ep)].bufpq_target_size +
+ start_iso.pkts_per_urb - 1) /
+start_iso.pkts_per_urb;
+/* Output endpoints pre-fill only 1/2 of the packets, keeping the rest
+ as overflow buffer. Also see the usbredir protocol documentation */
+if (!(ep USB_DIR_IN)) {
+start_iso.no_urbs *= 2;
+}
+if (start_iso.no_urbs 16) {
+start_iso.no_urbs = 16;
+}
+
/* No id, we look at the ep when receiving a status back */
usbredirparser_send_start_iso_stream(dev-parser, 0, start_iso);
usbredirparser_do_write(dev-parser);
@@ -988,9 +1015,24 @@ static void usbredir_ep_info(void *priv,
dev-endpoint[i].type = ep_info-type[i];
dev-endpoint[i].interval = ep_info-interval[i];
dev-endpoint[i].interface = ep_info-interface[i];
-if (dev-endpoint[i].type != usb_redir_type_invalid) {
+switch (dev-endpoint[i].type) {
+case usb_redir_type_invalid:
+break;
+case usb_redir_type_iso:
+case usb_redir_type_interrupt:
+if (dev-endpoint[i].interval == 0) {
+ERROR(Received 0 interval for isoc or irq endpoint\n);
+usbredir_device_disconnect(dev);
+}
+/* Fall through */
+case usb_redir_type_control:
+case usb_redir_type_bulk:
DPRINTF(ep: %02X type: %d interface: %d\n, I2EP(i),
dev-endpoint[i].type, dev-endpoint[i].interface);
+break;
+default:
+ERROR(Received invalid endpoint type\n);
+usbredir_device_disconnect(dev);
}
}
}
--
1.7.7.4
[Qemu-devel] [PATCH 1/5] usb-redir: Clear iso / irq error when stopping the stream
And ignore status messages from the client which arrive after stream
stop (the stream stop send to the client and an error status reported by
the client my cross each other due to network latency).
Signed-off-by: Hans de Goede hdego...@redhat.com
---
usb-redir.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/usb-redir.c b/usb-redir.c
index c232c7c..477c609 100644
--- a/usb-redir.c
+++ b/usb-redir.c
@@ -420,6 +420,7 @@ static void usbredir_stop_iso_stream(USBRedirDevice *dev,
uint8_t ep)
DPRINTF(iso stream stopped ep %02X\n, ep);
dev-endpoint[EP2I(ep)].iso_started = 0;
}
+dev-endpoint[EP2I(ep)].iso_error = 0;
usbredir_free_bufpq(dev, ep);
}
@@ -532,6 +533,7 @@ static void
usbredir_stop_interrupt_receiving(USBRedirDevice *dev,
DPRINTF(interrupt recv stopped ep %02X\n, ep);
dev-endpoint[EP2I(ep)].interrupt_started = 0;
}
+dev-endpoint[EP2I(ep)].interrupt_error = 0;
usbredir_free_bufpq(dev, ep);
}
@@ -1056,7 +1058,7 @@ static void usbredir_iso_stream_status(void *priv,
uint32_t id,
DPRINTF(iso status %d ep %02X id %u\n, iso_stream_status-status,
ep, id);
-if (!dev-dev.attached) {
+if (!dev-dev.attached || !dev-endpoint[EP2I(ep)].iso_started) {
return;
}
@@ -1077,7 +1079,7 @@ static void usbredir_interrupt_receiving_status(void
*priv, uint32_t id,
DPRINTF(interrupt recv status %d ep %02X id %u\n,
interrupt_receiving_status-status, ep, id);
-if (!dev-dev.attached) {
+if (!dev-dev.attached || !dev-endpoint[EP2I(ep)].interrupt_started) {
return;
}
--
1.7.7.4
Re: [Qemu-devel] memory: Why subpage is introduced?
On Wed, Dec 21, 2011 at 9:30 PM, Avi Kivity a...@redhat.com wrote: On 12/21/2011 02:09 PM, Zhi Yong Wu wrote: HI, For memory management, i have several questions as below: 1.) Why is subpage introduced? what is its goal? A TLB entry spans one page; a subpage is a way of dispatching accesses through that tlb entry to various memory regions. thanks. 2.) How to render MemoryRegion into one disjoint flatrange list? That rendering function is a bit difficult to understand. Can anyone simply explain it? What exactly don't you understand? 1.) e.g. some fields such as offset_in_region, terminates, offset in MemoryRegion struct. What are separately their meanings? 2.) render_memory_region(), how does it render one MemoryRegion into the global view flatview? Can you simply explain this function's algorithm logic? 3.) What are separately the meanings of these flags? such as IO_MEM_RAM, IO_MEM_ROM, IO_MEM_UNASSIGNED, IO_MEM_*, IO_MEM_ROMD, and IO_MEM_SUBPAGE. RAM = RAM ROM = ROM UNASSIGNED = nothing handles this range ROMD = ROM when read, device (i.e. callbacks) when written SUBPAGE = dispatch using the lower address bits to obtain final I/O handler. thanks. By the way, if you are available, can you simply explain what is the relationship among them and how they work together? such as MemoryRegion, RamBlock, PhysPageDesc, and MemorySlot. -- error compiling committee.c: too many arguments to function -- Regards, Zhi Yong Wu
[Qemu-devel] [PATCH 5/5] usb-redir: Improve some debugging messages
Signed-off-by: Hans de Goede hdego...@redhat.com
---
usb-redir.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/usb-redir.c b/usb-redir.c
index 4fada22..1289506 100644
--- a/usb-redir.c
+++ b/usb-redir.c
@@ -404,7 +404,8 @@ static int usbredir_handle_iso_data(USBRedirDevice *dev,
USBPacket *p,
/* No id, we look at the ep when receiving a status back */
usbredirparser_send_start_iso_stream(dev-parser, 0, start_iso);
usbredirparser_do_write(dev-parser);
-DPRINTF(iso stream started ep %02X\n, ep);
+DPRINTF(iso stream started pkts/sec %d pkts/urb %d urbs %d ep %02X\n,
+pkts_per_sec, start_iso.pkts_per_urb, start_iso.no_urbs, ep);
dev-endpoint[EP2I(ep)].iso_started = 1;
dev-endpoint[EP2I(ep)].bufpq_prefilled = 0;
dev-endpoint[EP2I(ep)].bufpq_dropping_packets = 0;
@@ -424,7 +425,8 @@ static int usbredir_handle_iso_data(USBRedirDevice *dev,
USBPacket *p,
isop = QTAILQ_FIRST(dev-endpoint[EP2I(ep)].bufpq);
if (isop == NULL) {
-DPRINTF2(iso-token-in ep %02X, no isop\n, ep);
+DPRINTF(iso-token-in ep %02X, no isop, iso_error: %d\n,
+ep, dev-endpoint[EP2I(ep)].iso_error);
/* Re-fill the buffer */
dev-endpoint[EP2I(ep)].bufpq_prefilled = 0;
/* Check iso_error for stream errors, otherwise its an underrun */
@@ -432,8 +434,8 @@ static int usbredir_handle_iso_data(USBRedirDevice *dev,
USBPacket *p,
dev-endpoint[EP2I(ep)].iso_error = 0;
return usbredir_handle_status(dev, status, 0);
}
-DPRINTF2(iso-token-in ep %02X status %d len %d\n, ep, isop-status,
- isop-len);
+DPRINTF2(iso-token-in ep %02X status %d len %d queue-size: %d\n, ep,
+ isop-status, isop-len, dev-endpoint[EP2I(ep)].bufpq_size);
status = isop-status;
if (status != usb_redir_success) {
@@ -443,7 +445,8 @@ static int usbredir_handle_iso_data(USBRedirDevice *dev,
USBPacket *p,
len = isop-len;
if (len p-iov.size) {
-ERROR(received iso data is larger then packet ep %02X\n, ep);
+ERROR(received iso data is larger then packet ep %02X (%d
%d)\n,
+ ep, len, (int)p-iov.size);
bufp_free(dev, isop, ep);
return USB_RET_NAK;
}
--
1.7.7.4
[Qemu-devel] [PATCH 4/5] usb-redir: Try to keep our buffer size near the target size
Before this patch we would allow the (iso) buffer to grow unlimited
(and it would under certain circumstances) leading to way too high
latencies for iso data streams.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
usb-redir.c | 30 +++---
1 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/usb-redir.c b/usb-redir.c
index 0658076..4fada22 100644
--- a/usb-redir.c
+++ b/usb-redir.c
@@ -61,6 +61,7 @@ struct endp_data {
uint8_t interrupt_started;
uint8_t interrupt_error;
uint8_t bufpq_prefilled;
+uint8_t bufpq_dropping_packets;
QTAILQ_HEAD(, buf_packet) bufpq;
int bufpq_size;
int bufpq_target_size;
@@ -300,16 +301,34 @@ static void usbredir_cancel_packet(USBDevice *udev,
USBPacket *p)
}
}
-static struct buf_packet *bufp_alloc(USBRedirDevice *dev,
+static void bufp_alloc(USBRedirDevice *dev,
uint8_t *data, int len, int status, uint8_t ep)
{
-struct buf_packet *bufp = g_malloc(sizeof(struct buf_packet));
+struct buf_packet *bufp;
+
+if (!dev-endpoint[EP2I(ep)].bufpq_dropping_packets
+dev-endpoint[EP2I(ep)].bufpq_size
+2 * dev-endpoint[EP2I(ep)].bufpq_target_size) {
+DPRINTF(bufpq overflow, dropping packets ep %02X\n, ep);
+dev-endpoint[EP2I(ep)].bufpq_dropping_packets = 1;
+}
+/* Since we're interupting the stream anyways, drop enough packets to get
+ back to our target buffer size */
+if (dev-endpoint[EP2I(ep)].bufpq_dropping_packets) {
+if (dev-endpoint[EP2I(ep)].bufpq_size
+dev-endpoint[EP2I(ep)].bufpq_target_size) {
+free(data);
+return;
+}
+dev-endpoint[EP2I(ep)].bufpq_dropping_packets = 0;
+}
+
+bufp = g_malloc(sizeof(struct buf_packet));
bufp-data = data;
bufp-len= len;
bufp-status = status;
QTAILQ_INSERT_TAIL(dev-endpoint[EP2I(ep)].bufpq, bufp, next);
dev-endpoint[EP2I(ep)].bufpq_size++;
-return bufp;
}
static void bufp_free(USBRedirDevice *dev, struct buf_packet *bufp,
@@ -388,6 +407,7 @@ static int usbredir_handle_iso_data(USBRedirDevice *dev,
USBPacket *p,
DPRINTF(iso stream started ep %02X\n, ep);
dev-endpoint[EP2I(ep)].iso_started = 1;
dev-endpoint[EP2I(ep)].bufpq_prefilled = 0;
+dev-endpoint[EP2I(ep)].bufpq_dropping_packets = 0;
}
if (ep USB_DIR_IN) {
@@ -514,6 +534,10 @@ static int usbredir_handle_interrupt_data(USBRedirDevice
*dev,
usbredirparser_do_write(dev-parser);
DPRINTF(interrupt recv started ep %02X\n, ep);
dev-endpoint[EP2I(ep)].interrupt_started = 1;
+/* We don't really want to drop interrupt packets ever, but
+ having some upper limit to how much we buffer is good. */
+dev-endpoint[EP2I(ep)].bufpq_target_size = 1000;
+dev-endpoint[EP2I(ep)].bufpq_dropping_packets = 0;
}
intp = QTAILQ_FIRST(dev-endpoint[EP2I(ep)].bufpq);
--
1.7.7.4
Re: [Qemu-devel] [PATCH v4 04/11] ARM: exynos4210: IRQ subsystem support.
On 22 December 2011 07:03, Evgeny Voevodin e.voevo...@samsung.com wrote: Second GIC (external) is represented as exynos4210.gic with splitted mapping for CPU (0x1048) and Distributer (0x1049) (we used arm_gic.c availability to split CPU and Distributer memories). The reason for creation of this device with it's own read/write functions is: CPU and Distributer registers which are banked per SMP Core in internal GIC are not banked in external GIC and their offsets could not be used as is with arm_gic.c. External GIC registers in comparison to Internal GIC registers are moved from base by offset n * 0x8000 for each SMP Core, where n is SMP Core index. Right, so just map each of the memory regions arm_gic exposes for core 0, core 1, ... to these addresses, and don't map the memory region corresponding to CPU interface for this core at all. -- PMM
Re: [Qemu-devel] [PATCH 3/9] arm: add missing v7 cp15 registers
On 22 December 2011 10:14, Avi Kivity a...@redhat.com wrote: On 12/21/2011 11:10 PM, Peter Maydell wrote: Avi: is there a way for a device (sysbus device in this case) to find out for one of its memory regions where it has been mapped in the address space? Where and if. The context here is that the Cortex-A9 has a cp15 register whose value is base address of the private peripherals, and it would be nice not to have to have boards saying both map mmio region at X and set property so register reads as X... [You could argue that hardware implementations have to do the equivalent of both of these things separately, I suppose, but it's still not very pretty.] I don't really follow, can you explain? So in real hardware, these devices (interrupt controller, timers, etc) are an integral part of the CPU. They appear in the memory map at an address which is configured by hardwiring the CPU's PERIPHBASE signals to specify that address. Since obviously software needs to know where the devices are, there is a coprocessor register which simply returns the value of PERIPHBASE. (So I was wrong that hardware does the mapping and the register separately -- sorry.) Part of the problem we have is that in QEMU we don't model the CPU as a single qdev device which includes both the core and its builtin devices -- the two are completely separate and the board model ends up having to do a lot of the work of wiring things up, and in cases like this where one bit of config affects both the core CPU and the builtin devices you end up having to specify it twice. Anyway, with the new MemoryListener API (not yet merged), you can register a callback to be called when MemoryRegions become visible or invisible. You can filter there for your pet region and get all the info about it. Mmm, that would work. -- PMM
Re: [Qemu-devel] memory: Why subpage is introduced?
On 12/22/2011 01:24 PM, Zhi Yong Wu wrote: 2.) How to render MemoryRegion into one disjoint flatrange list? That rendering function is a bit difficult to understand. Can anyone simply explain it? What exactly don't you understand? 1.) e.g. some fields such as offset_in_region, terminates, offset in MemoryRegion struct. What are separately their meanings? Well, read the code, it's not that complicated. Afterwards you can add documentation based on your findings. 2.) render_memory_region(), how does it render one MemoryRegion into the global view flatview? Can you simply explain this function's algorithm logic? Again, what can I say that the code doesn't? It recursively descends the hierarchy and finds out which region goes where. Also read docs/memory.txt 3.) What are separately the meanings of these flags? such as IO_MEM_RAM, IO_MEM_ROM, IO_MEM_UNASSIGNED, IO_MEM_*, IO_MEM_ROMD, and IO_MEM_SUBPAGE. RAM = RAM ROM = ROM UNASSIGNED = nothing handles this range ROMD = ROM when read, device (i.e. callbacks) when written SUBPAGE = dispatch using the lower address bits to obtain final I/O handler. thanks. By the way, if you are available, can you simply explain what is the relationship among them and how they work together? such as MemoryRegion, RamBlock, PhysPageDesc, and MemorySlot. Sorry, it's a long and complicated story that is changing now. You'll have to educate yourself mostly. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 3/9] arm: add missing v7 cp15 registers
On 12/22/2011 02:37 PM, Peter Maydell wrote: On 22 December 2011 10:14, Avi Kivity a...@redhat.com wrote: On 12/21/2011 11:10 PM, Peter Maydell wrote: Avi: is there a way for a device (sysbus device in this case) to find out for one of its memory regions where it has been mapped in the address space? Where and if. The context here is that the Cortex-A9 has a cp15 register whose value is base address of the private peripherals, and it would be nice not to have to have boards saying both map mmio region at X and set property so register reads as X... [You could argue that hardware implementations have to do the equivalent of both of these things separately, I suppose, but it's still not very pretty.] I don't really follow, can you explain? So in real hardware, these devices (interrupt controller, timers, etc) are an integral part of the CPU. They appear in the memory map at an address which is configured by hardwiring the CPU's PERIPHBASE signals to specify that address. Since obviously software needs to know where the devices are, there is a coprocessor register which simply returns the value of PERIPHBASE. (So I was wrong that hardware does the mapping and the register separately -- sorry.) Part of the problem we have is that in QEMU we don't model the CPU as a single qdev device which includes both the core and its builtin devices -- the two are completely separate and the board model ends up having to do a lot of the work of wiring things up, and in cases like this where one bit of config affects both the core CPU and the builtin devices you end up having to specify it twice. Sounds like a qom LinkBlah or some other magic should handle it? #include cc/aliguori. Anyway, with the new MemoryListener API (not yet merged), you can register a callback to be called when MemoryRegions become visible or invisible. You can filter there for your pet region and get all the info about it. Mmm, that would work. Now that I better understand the issue, I think it's overkill. You just want to replicate a register between devices. The MemoryListener API is designed to allow you to see the memory map from the cpu's side, after a region has been transformed by overlapping regions, address transformation by bridges, enables/disables, etc. You just want to copy a value from one object to another, you don't care about any of this. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 20/23] vhost: avoid cpu_get_physical_page_desc()
On Mon, Dec 19, 2011 at 04:13:41PM +0200, Avi Kivity wrote:
@@ -871,7 +899,10 @@ void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice
*vdev)
hdev-vqs + i,
i);
}
-vhost_sync_dirty_bitmap(hdev, 0, (target_phys_addr_t)~0x0ull);
+for (i = 0; i hdev-n_mem_sections; ++i) {
+vhost_sync_dirty_bitmap(hdev, hdev-mem_sections[i],
+0, (target_phys_addr_t)~0x0ull);
+}
r = vdev-binding-set_guest_notifiers(vdev-binding_opaque, false);
if (r 0) {
fprintf(stderr, vhost guest notifier cleanup failed: %d\n, r);
diff --git a/hw/vhost.h b/hw/vhost.h
index d1824ec..80e64df 100644
--- a/hw/vhost.h
+++ b/hw/vhost.h
@@ -30,6 +30,8 @@ struct vhost_dev {
MemoryListener memory_listener;
int control;
struct vhost_memory *mem;
+int n_mem_sections;
+MemoryRegionSection *mem_sections;
struct vhost_virtqueue *vqs;
int nvqs;
unsigned long long features;
This adds need to track all sections which is unfortunate.
Couldn't the memory API get an extension e.g. to scan them all?
--
1.7.7.1
Re: [Qemu-devel] [PATCH 14/23] vhost: convert to MemoryListener API
On Mon, Dec 19, 2011 at 04:13:35PM +0200, Avi Kivity wrote:
+static void vhost_log_start(MemoryListener *listener,
+MemoryRegionSection *section)
+{
+/* FIXME: implement */
+}
+
+static void vhost_log_stop(MemoryListener *listener,
+ MemoryRegionSection *section)
+{
+/* FIXME: implement */
+}
+
What exactly do we need to fix here?
Re: [Qemu-devel] [PATCH 20/23] vhost: avoid cpu_get_physical_page_desc()
On 12/22/2011 02:48 PM, Michael S. Tsirkin wrote:
On Mon, Dec 19, 2011 at 04:13:41PM +0200, Avi Kivity wrote:
@@ -871,7 +899,10 @@ void vhost_dev_stop(struct vhost_dev *hdev,
VirtIODevice *vdev)
hdev-vqs + i,
i);
}
-vhost_sync_dirty_bitmap(hdev, 0, (target_phys_addr_t)~0x0ull);
+for (i = 0; i hdev-n_mem_sections; ++i) {
+vhost_sync_dirty_bitmap(hdev, hdev-mem_sections[i],
+0, (target_phys_addr_t)~0x0ull);
+}
r = vdev-binding-set_guest_notifiers(vdev-binding_opaque, false);
if (r 0) {
fprintf(stderr, vhost guest notifier cleanup failed: %d\n, r);
diff --git a/hw/vhost.h b/hw/vhost.h
index d1824ec..80e64df 100644
--- a/hw/vhost.h
+++ b/hw/vhost.h
@@ -30,6 +30,8 @@ struct vhost_dev {
MemoryListener memory_listener;
int control;
struct vhost_memory *mem;
+int n_mem_sections;
+MemoryRegionSection *mem_sections;
struct vhost_virtqueue *vqs;
int nvqs;
unsigned long long features;
This adds need to track all sections which is unfortunate.
Couldn't the memory API get an extension e.g. to scan them all?
I thought about it, it makes sense.
We even have memory_region_find() which can be used to implement it,
just need a FOR_EACH wrapper.
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [Spice-devel] Seem thread Competition
On Thu, Dec 22, 2011 at 6:53 PM, Alon Levy al...@redhat.com wrote:
On Thu, Dec 22, 2011 at 10:00:18AM +, Alon Levy wrote:
On Thu, Dec 22, 2011 at 05:42:29PM +0800, ZhouPeng wrote:
On Thu, Dec 22, 2011 at 4:42 PM, Alon Levy al...@redhat.com wrote:
On Thu, Dec 22, 2011 at 10:13:50AM +0800, ZhouPeng wrote:
Hi,
I meet the err:
# virsh dumpxml 63
error: internal error cannot parse json {timestamp: {seconds:
1323332828, microseco{timest35p:39}, econds:PICE_D 1CO3233TE828,
Dmicrosec dsdata52}, : {ser: SPrCE_DISONNEC{ED, port: {serve
: {6299: 62, famiamily: ipv:, hist: pv41 hos6:
182.168.12.231}, 2lient.: {p2rt: 3350196, faily: }, cl,
ho{sport:t35020, : 19y: i2.4, 168.1.: 19}: lexical error:
invalid string in json text.
ds: 1323332828, microseco{timest35p:39}, econds:PICE_D
This similar bug seems has been reported by:
https://bugzilla.redhat.com/show_bug.cgi?id=744105
The patch(http://cgit.freedesktop.org/spice/qemu/commit/?h=spice.v42)
seems be related with the competition.
But I searched the upstream qemu, it has not been merged in.
My qemu is qemu-kvm-0.15.1 on 3.1.2-1.fc16.x86_64
Is there any plan about this bug, it seems be some serious.
The patch Daniel Berrange mentioned wotrked around it in qemu and is in
qemu 1.0-rc0 and onward, still checking qemu-kvm. There is another patch
Yea, I searched in spice-core.c again and the patch is in qemu unstable
Sorry, I carelessly search by me but not me; before.
It is in qemu-kvm-1.0 as well. But like you said fedora carries 0.15.1
that doesn't have it.
in spice-0.10 and in 0.8, still need to check if it's in fedora. Which
version of spice are you using?
spice-server.x86_64 version 0.9.1
which doesn't have the spice side fix. but 0.10.0 has it, and it is
closest to 0.9.1. I assume this is from the fedora package as well since
you mentioned qemu-kvm is from a fedora package? seems the latest is
indeed 0.9.1-1, can you test
http://koji.fedoraproject.org/koji/buildinfo?buildID=273917
(spice-server-0.10.0-1)?
If you find it fixes your problem and doesn't introduce any new ones
please +1 spice-0.10.0-1.fc16 at
https://admin.fedoraproject.org/updates/spice-0.10.0-1.fc16
After the steps below, I am sure it is spice-server-0.10.0-1.fc16.x86_64 works.
[root@localhost pkgconfig]# ldd /usr/bin/qemu-kvm
libspice-server.so.1 = /usr/lib64/libspice-server.so.1
(0x7f5f02799000)
[root@localhost ~]# rpm --erase spice-server-0.9.1-1.fc16.x86_64 --nodeps
[root@localhost ~]# rpm --erase spice-server-0.10.0-1.fc16.x86_64 --nodeps
[root@localhost ~]# ls /usr/lib64/libspice-server* -l
lrwxrwxrwx. 1 root root 24 Dec 20 06:43 /usr/lib64/libspice-server.so
- libspice-server.so.1.0.2
[root@localhost ~]# virsh restore 43.ckp
error: Failed to restore domain from 43.ckp
error: internal error Child process (LC_ALL=C
PATH=/sbin:/usr/sbin:/bin:/usr/bin /usr/bin/qemu-kvm -help) status
unexpected: exit status 127
//Note: libspice-server.so.1.0.2 doesn't exists
[root@localhost ~]# rpm -i spice-server-0.10.0-1.fc16.x86_64.rpm
[root@localhost ~]# ls /usr/lib64/libspice-server* -l
lrwxrwxrwx. 1 root root 24 Dec 20 06:43
/usr/lib64/libspice-server.so - libspice-server.so.1.0.2
lrwxrwxrwx 1 root root 24 Dec 22 07:21
/usr/lib64/libspice-server.so.1 - libspice-server.so.1.0.2
-rwxr-xr-x 1 root root 983600 Nov 14 08:08 /usr/lib64/libspice-server.so.1.0.2
[root@localhost ~]# virsh restore 43.ckp
Domain restored from 43.ckp
The software suits related:
spice-server x86_64
0.10.0-1.fc16 installed 993
k
qemu-kvm x86_64
2:0.15.1-3.fc16 @updates0.0
qemu-system-x86 x86_64
2:0.15.1-3.fc16 @updates 12 M
spice-server-develx86_64
0.9.1-1.fc16 @fedora 19 k
This random bug appears at least 2 time one day before fixing.
So in the coming 2 days, if this bug does't appear again, I will
assume spice-server-0.10.0-1.fc16.x86_64.rpm fix it :)
Thanks,
Alon
Thanks Alon,
--
Zhou Peng
___
Spice-devel mailing list
spice-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
--
Zhou Peng
Re: [Qemu-devel] [PATCH 14/23] vhost: convert to MemoryListener API
On 12/22/2011 02:50 PM, Michael S. Tsirkin wrote:
On Mon, Dec 19, 2011 at 04:13:35PM +0200, Avi Kivity wrote:
+static void vhost_log_start(MemoryListener *listener,
+MemoryRegionSection *section)
+{
+/* FIXME: implement */
+}
+
+static void vhost_log_stop(MemoryListener *listener,
+ MemoryRegionSection *section)
+{
+/* FIXME: implement */
+}
+
What exactly do we need to fix here?
Tell vhost to start tracking those regions?
I guess you don't often read packets into the framebuffer, or we'd have
a lot of bug reports.
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH v4 04/11] ARM: exynos4210: IRQ subsystem support.
On 12/22/2011 04:30 PM, Peter Maydell wrote: On 22 December 2011 07:03, Evgeny Voevodine.voevo...@samsung.com wrote: Second GIC (external) is represented as exynos4210.gic with splitted mapping for CPU (0x1048) and Distributer (0x1049) (we used arm_gic.c availability to split CPU and Distributer memories). The reason for creation of this device with it's own read/write functions is: CPU and Distributer registers which are banked per SMP Core in internal GIC are not banked in external GIC and their offsets could not be used as is with arm_gic.c. External GIC registers in comparison to Internal GIC registers are moved from base by offset n * 0x8000 for each SMP Core, where n is SMP Core index. Right, so just map each of the memory regions arm_gic exposes for core 0, core 1, ... to these addresses, and don't map the memory region corresponding to CPU interface for this core at all. -- PMM Do you mean to use s-gic.cpuiomem[NCPU+1] as in a9mpcore.c a9mp_priv_init() done? What should we use if we need the same for distributor which is represented as gic.iomem? Extend distributor in the same way? -- Kind regards, Evgeny Voevodin, Leading Software Engineer, ASWG, Moscow RD center, Samsung Electronics e-mail: e.voevo...@samsung.com
Re: [Qemu-devel] [PATCH 14/23] vhost: convert to MemoryListener API
On Thu, Dec 22, 2011 at 02:50:27PM +0200, Avi Kivity wrote:
On 12/22/2011 02:50 PM, Michael S. Tsirkin wrote:
On Mon, Dec 19, 2011 at 04:13:35PM +0200, Avi Kivity wrote:
+static void vhost_log_start(MemoryListener *listener,
+MemoryRegionSection *section)
+{
+/* FIXME: implement */
+}
+
+static void vhost_log_stop(MemoryListener *listener,
+ MemoryRegionSection *section)
+{
+/* FIXME: implement */
+}
+
What exactly do we need to fix here?
Tell vhost to start tracking those regions?
I guess you don't often read packets into the framebuffer, or we'd have
a lot of bug reports.
Yes, we currently simply don't pass these regions to vhost.
It currently signals an error if such is
observed, so we could handle framebuffer in userspace
if we wanted to.
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 14/23] vhost: convert to MemoryListener API
On 12/22/2011 02:57 PM, Michael S. Tsirkin wrote:
On Thu, Dec 22, 2011 at 02:50:27PM +0200, Avi Kivity wrote:
On 12/22/2011 02:50 PM, Michael S. Tsirkin wrote:
On Mon, Dec 19, 2011 at 04:13:35PM +0200, Avi Kivity wrote:
+static void vhost_log_start(MemoryListener *listener,
+MemoryRegionSection *section)
+{
+/* FIXME: implement */
+}
+
+static void vhost_log_stop(MemoryListener *listener,
+ MemoryRegionSection *section)
+{
+/* FIXME: implement */
+}
+
What exactly do we need to fix here?
Tell vhost to start tracking those regions?
I guess you don't often read packets into the framebuffer, or we'd have
a lot of bug reports.
Yes, we currently simply don't pass these regions to vhost.
It currently signals an error if such is
observed, so we could handle framebuffer in userspace
if we wanted to.
I see, thanks.
--
error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH] virtio-blk: add virtio_blk_handle_read trace event
There already exists a virtio_blk_handle_write trace event as well as
completion events. Add the virtio_blk_handle_read event so it's easy to
trace virtio-blk requests for both read and write operations.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
hw/virtio-blk.c |2 ++
trace-events|1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index ef27421..cf275e4 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -340,6 +340,8 @@ static void virtio_blk_handle_read(VirtIOBlockReq *req)
bdrv_acct_start(req-dev-bs, req-acct, req-qiov.size, BDRV_ACCT_READ);
+trace_virtio_blk_handle_read(req, sector, req-qiov.size / 512);
+
if (sector req-dev-sector_mask) {
virtio_blk_rw_complete(req, -EIO);
return;
diff --git a/trace-events b/trace-events
index 514849a..2875ea8f6 100644
--- a/trace-events
+++ b/trace-events
@@ -73,6 +73,7 @@ bdrv_co_copy_on_readv(void *bs, int64_t sector_num, int
nb_sectors, int64_t clus
virtio_blk_req_complete(void *req, int status) req %p status %d
virtio_blk_rw_complete(void *req, int ret) req %p ret %d
virtio_blk_handle_write(void *req, uint64_t sector, size_t nsectors) req %p
sector %PRIu64 nsectors %zu
+virtio_blk_handle_read(void *req, uint64_t sector, size_t nsectors) req %p
sector %PRIu64 nsectors %zu
# posix-aio-compat.c
paio_submit(void *acb, void *opaque, int64_t sector_num, int nb_sectors, int
type) acb %p opaque %p sector_num %PRId64 nb_sectors %d type %d
--
1.7.7.3
Re: [Qemu-devel] [PATCH] virtio-blk: add virtio_blk_handle_read trace event
On 12/22/2011 02:17 PM, Stefan Hajnoczi wrote:
There already exists a virtio_blk_handle_write trace event as well as
completion events. Add the virtio_blk_handle_read event so it's easy to
trace virtio-blk requests for both read and write operations.
Signed-off-by: Stefan Hajnoczistefa...@linux.vnet.ibm.com
---
hw/virtio-blk.c |2 ++
trace-events|1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index ef27421..cf275e4 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -340,6 +340,8 @@ static void virtio_blk_handle_read(VirtIOBlockReq *req)
bdrv_acct_start(req-dev-bs,req-acct, req-qiov.size, BDRV_ACCT_READ);
+trace_virtio_blk_handle_read(req, sector, req-qiov.size / 512);
+
if (sector req-dev-sector_mask) {
virtio_blk_rw_complete(req, -EIO);
return;
diff --git a/trace-events b/trace-events
index 514849a..2875ea8f6 100644
--- a/trace-events
+++ b/trace-events
@@ -73,6 +73,7 @@ bdrv_co_copy_on_readv(void *bs, int64_t sector_num, int
nb_sectors, int64_t clus
virtio_blk_req_complete(void *req, int status) req %p status %d
virtio_blk_rw_complete(void *req, int ret) req %p ret %d
virtio_blk_handle_write(void *req, uint64_t sector, size_t nsectors) req %p sector
%PRIu64 nsectors %zu
+virtio_blk_handle_read(void *req, uint64_t sector, size_t nsectors) req %p sector
%PRIu64 nsectors %zu
# posix-aio-compat.c
paio_submit(void *acb, void *opaque, int64_t sector_num, int nb_sectors, int type) acb %p
opaque %p sector_num %PRId64 nb_sectors %d type %d
Acked-by: Paolo Bonzini pbonz...@redhat.com
[Qemu-devel] [PATCH] qemu-test: add virtio-serial test
This is a pretty simple test that just confirms that virtio-serial shows up and
is writable. It also tests the alias for virtio-serial-pci.
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
tests/virtio-serial.sh | 52
1 files changed, 52 insertions(+), 0 deletions(-)
create mode 100755 tests/virtio-serial.sh
diff --git a/tests/virtio-serial.sh b/tests/virtio-serial.sh
new file mode 100755
index 000..e95ae6e
--- /dev/null
+++ b/tests/virtio-serial.sh
@@ -0,0 +1,52 @@
+#!/bin/sh
+
+canary=** waiting for... **
+
+in_host() {
+tmpchr=$tmpdir/chr.log
+
+# Also test alias
+devname=`choose virtio-serial virtio-serial-pci`
+
+qemu -nographic -enable-kvm -device $devname \
+-device virtserialport,name=org.qemu.test,chardev=chr0 \
+-chardev file,path=$tmpchr,id=chr0
+rc=$?
+
+if test $rc = 0; then
+ if ! grep $canary $tmpchr /dev/null; then
+ echo Failed to see output from guest!
+ rc=1
+ fi
+fi
+
+rm -f $tmpchr
+
+return $rc
+}
+
+in_guest() {
+sysfspath=/sys/bus/virtio/devices/virtio0/virtio-ports/vport0p1
+if ! test -e $sysfspath/name; then
+ echo Device not visible!
+ return 1
+fi
+
+name=`cat $sysfspath/name`
+
+if test $name != org.qemu.test; then
+ echo Device has wrong name!
+ echo Expected 'org.qemu.test', got '$name'
+ return 2
+fi
+
+echo $canary /dev/vport0p1
+
+return 0
+}
+
+if test $QEMU_TEST; then
+in_host
+else
+in_guest
+fi
--
1.7.4.1
Re: [Qemu-devel] [PATCH 3/9] arm: add missing v7 cp15 registers
On 12/22/2011 06:43 AM, Avi Kivity wrote: On 12/22/2011 02:37 PM, Peter Maydell wrote: On 22 December 2011 10:14, Avi Kivitya...@redhat.com wrote: On 12/21/2011 11:10 PM, Peter Maydell wrote: Avi: is there a way for a device (sysbus device in this case) to find out for one of its memory regions where it has been mapped in the address space? Where and if. The context here is that the Cortex-A9 has a cp15 register whose value is base address of the private peripherals, and it would be nice not to have to have boards saying both map mmio region at X and set property so register reads as X... [You could argue that hardware implementations have to do the equivalent of both of these things separately, I suppose, but it's still not very pretty.] I don't really follow, can you explain? So in real hardware, these devices (interrupt controller, timers, etc) are an integral part of the CPU. They appear in the memory map at an address which is configured by hardwiring the CPU's PERIPHBASE signals to specify that address. Since obviously software needs to know where the devices are, there is a coprocessor register which simply returns the value of PERIPHBASE. (So I was wrong that hardware does the mapping and the register separately -- sorry.) Part of the problem we have is that in QEMU we don't model the CPU as a single qdev device which includes both the core and its builtin devices -- the two are completely separate and the board model ends up having to do a lot of the work of wiring things up, and in cases like this where one bit of config affects both the core CPU and the builtin devices you end up having to specify it twice. Sounds like a qom LinkBlah or some other magic should handle it? #include cc/aliguori. First, we need to actually model the CPUs. The general trouble with that today is that everything needs to live on a bus after we get QOM merged, that requirement will be relaxed. Once the CPUs are objects, they can create children devices (builtin interrupt controller for instance) in their instance_init function. It would be a child property in this case. This is how I want to model the local apic, for instance. Regards, Anthony Liguori
Re: [Qemu-devel] [RFC PATCH] Exporting Guest RAM information for NUMA binding
On Thu, Dec 01, 2011 at 06:40:31PM +0100, Peter Zijlstra wrote: On Wed, 2011-11-23 at 16:03 +0100, Andrea Arcangeli wrote: snip From what I gather what you propose is to periodically unmap all user memory (or map it !r !w !x, which is effectively the same) and take the fault. This fault will establish a thread:page relation. One can just use that or involve some history as well. Once you have this thread:page relation set you want to group them on the same node. There's various problems with that, firstly of course the overhead, storing this thread:page relation set requires quite a lot of memory. Secondly I'm not quite sure I see how that works for threads that share a working set. Suppose you have 4 threads and 2 working sets, how do you make sure to keep the 2 groups together. I don't think that's evident from the simple thread:page relation data [*]. Thirdly I immensely dislike all these background scanner things, they make it very hard to account time to those who actually use it. Picture yourself as the administrator of a virtualized host, with a given workload of guests doing their tasks. All it takes is to understand from a high level what the algorithms of ksm (collapsing of equal content-pages into same physical RAM) and khugepaged (collapsing of 4k pages in 2MB pages, good for TLB) are doing (and that should be documented), and infer from that what is happening. The same is valid for the guy who is writing management tools and exposing the statistics to the system administrator.
Re: [Qemu-devel] [RFC PATCH] Exporting Guest RAM information for NUMA binding
On Thu, Dec 01, 2011 at 06:40:31PM +0100, Peter Zijlstra wrote: On Wed, 2011-11-23 at 16:03 +0100, Andrea Arcangeli wrote: Hi! On Mon, Nov 21, 2011 at 07:51:21PM -0600, Anthony Liguori wrote: Fundamentally, the entity that should be deciding what memory should be present and where it should located is the kernel. I'm fundamentally opposed to trying to make QEMU override the scheduler/mm by using cpu or memory pinning in QEMU. From what I can tell about ms_mbind(), it just uses process knowledge to bind specific areas of memory to a memsched group and let's the kernel decide what to do with that knowledge. This is exactly the type of interface that QEMU should be using. QEMU should tell the kernel enough information such that the kernel can make good decisions. QEMU should not be the one making the decisions. True, QEMU won't have to decide where the memory and vcpus should be located (but hey it wouldn't need to decide that even if you use cpusets, you can use relative mbind with cpusets, the admin or a cpuset job scheduler could decide) but it's still QEMU making the decision of what memory and which vcpus threads to ms_mbind/ms_tbind. Think how you're going to create the input of those syscalls... If it wasn't qemu to decide that, qemu wouldn't be required to scan the whole host physical numa (cpu/memory) topology in order to create the input arguments of ms_mbind/ms_tbind. That's a plain falsehood, you don't need to scan host physcal topology in order to create useful ms_[mt]bind arguments. You can use physical topology to optimize for particular hardware, but its not a strict requirement. And when you migrate the VM to another host, the whole vtopology may be counter-productive because the kernel isn't automatically detecting the numa affinity between threads and the guest vtopology will stick to whatever numa _physical_ topology that was seen on the first node where the VM was created. This doesn't make any sense at all. I doubt that the assumption that all cloud nodes will have the same physical numa topology is reasonable. So what? If you want to be very careful you can make sure you vnodes are small enough they fit any any physical node in your cloud (god I f*king hate that word). If you're slightly less careful, things will still work, you might get less max parallelism, but typically (from what I understood) these VM hosting thingies are overloaded so you never get your max cpu anyway, so who cares. Things is, whatever you set-up it will always work, it might not be optimal, but the one guarantee: [threads,vrange] will stay on the same node will be kept true, no matter where you run it. Also, migration between non-identical hosts is always 'tricky'. You're always stuck with some minimally supported subset or average case thing. Really, why do you think NUMA would be any different. Furthermore to get the same benefits that qemu gets on host by using ms_mbind/ms_tbind, every single guest application should be modified to scan the guest vtopology and call ms_mbind/ms_tbind too (or use the hard bindings which is what we try to avoid). No! ms_[tm]bind() is just part of the solution, the other part is what to do for simple programs, and like I wrote in my email earlier, and what we talked about in Prague, is that for normal simple proglets we simply pick a numa node and stick to it. Much like: http://home.arcor.de/efocht/sched/ Except we could actually migrate the whole thing if needed. Basically you give each task its own 1 vnode and assign all threads to it. Only big programs that need to span multiple nodes need to be modified to get best advantage of numa. But that has always been true. In my view the trouble of the numa hard bindings is not the fact they're hard and qemu has to also decide the location (in fact it doesn't need to decide the location if you use cpusets and relative mbinds). The bigger problem is the fact either the admin or the app developer has to explicitly scan the numa physical topology (both cpus and memory) and tell the kernel how much memory to bind to each thread. ms_mbind/ms_tbind only partially solve that problem. They're similar to the mbind MPOL_F_RELATIVE_NODES with cpusets, except you don't need an admin or a cpuset-job-scheduler (or a perl script) to redistribute the hardware resources. You're full of crap Andrea. Yes you need some clue as to your actual topology, but that's life, you can't get SMP for free either, you need to have some clue. Just like with regular SMP where you need to be aware of data sharing, NUMA just makes it worse. If your app decomposes well enough to create a vnode per thread, that's excellent, if you want to scale your app to fit your machine that's fine too, heck, every multi-threaded app out there worth using already
Re: [Qemu-devel] [PATCH v4 04/11] ARM: exynos4210: IRQ subsystem support.
On 22 December 2011 12:50, Evgeny Voevodin e.voevo...@samsung.com wrote: Do you mean to use s-gic.cpuiomem[NCPU+1] as in a9mpcore.c a9mp_priv_init() done? It depends what you want. If you need a memory region which behaves like CPU interface for whatever the core making this read/write is, that is cpuiomem[0]. If you need a memory region which behaves like CPU interface for core 0 regardless of which core accesses it, that is cpuiomem[1]. For CPU interface for core 1, cpuiomem[2]. 11MPCore uses all of these. A9MP's built in GIC only needs cpuiomem[0]. If you need any of these at more than one address in the memory map, you need to create a memory region alias. What should we use if we need the same for distributor which is represented as gic.iomem? Extend distributor in the same way? Your current wrapper functions for the distributor read/write routines don't do anything to pass a specific CPU number into the underlying GIC distributor read/write functions. So it should be sufficient to just map the distributor's existing memory region (again, if you need it in more than one place in the address space then create an alias memory region for it). -- PMM
Re: [Qemu-devel] [PATCH 3/9] arm: add missing v7 cp15 registers
On 22 December 2011 14:25, Anthony Liguori anth...@codemonkey.ws wrote: First, we need to actually model the CPUs. The general trouble with that today is that everything needs to live on a bus after we get QOM merged, that requirement will be relaxed. Once the CPUs are objects, they can create children devices (builtin interrupt controller for instance) in their instance_init function. It would be a child property in this case. So, in summary to Mark, if always reads as zero is sufficient for your purposes, I'll accept this as a patch which implements that (if you fix the other issues and add a comment that it ought to be the base address of the private peripheral region). We can implement it properly when we have enough object model infrastructure to do so. -- PMM
Re: [Qemu-devel] [PATCH] qemu-test: add virtio-serial test
On 22 December 2011 14:23, Anthony Liguori aligu...@us.ibm.com wrote:
This is a pretty simple test that just confirms that virtio-serial shows up
and
is writable. It also tests the alias for virtio-serial-pci.
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
tests/virtio-serial.sh | 52
1 files changed, 52 insertions(+), 0 deletions(-)
create mode 100755 tests/virtio-serial.sh
diff --git a/tests/virtio-serial.sh b/tests/virtio-serial.sh
new file mode 100755
index 000..e95ae6e
--- /dev/null
+++ b/tests/virtio-serial.sh
@@ -0,0 +1,52 @@
+#!/bin/sh
+
+canary=** waiting for... **
+
+in_host() {
+ tmpchr=$tmpdir/chr.log
By far the most common error likely to appear in any of these test
scripts is insufficient shell quoting causing e.g. breakages when the
scripts are run from a directory with spaces. Having looked at
qemu-test, I see that $tmpdir is set to .tmp-$$ and so can never
contain spaces, and so it's fine to not quote the variable expansion.
That said, perhaps it would make it easier to review scripts and less
likely for these issues to creep in to the codebase if there was a
blanket rule that all variable expansions be quoted?
Alex
Re: [Qemu-devel] [PATCH v6 4/4] Add support for net bridge
On 12/20/2011 11:13 AM, Corey Bryant wrote:
On 12/19/2011 06:15 PM, Anthony Liguori wrote:
On 12/19/2011 04:55 PM, Corey Bryant wrote:
diff --git a/net.c b/net.c
index f7bebf8..9296224 100644
--- a/net.c
+++ b/net.c
@@ -952,6 +952,14 @@ static const struct {
.type = QEMU_OPT_STRING,
.help = script to shut down the interface,
}, {
+ .name = br,
+ .type = QEMU_OPT_STRING,
+ .help = bridge name,
+ }, {
I don't think passing br= makes a whole of sense for -net tap. I think
it would make more sense to make sure that helper could take a shell
string so you could do:
-netdev tap,helper=/usr/libexec/qemu-bridge-helper --br=br0
Regards,
Anthony Liguori
Ok but do you think the -net bridge options should remain as-is? It
seems like
execution of the helper should be consistent. Here are the current
options for
-net bridge:
-net bridge,helper=/usr/local/libexec/qemu-bridge-helper,br=br0
Yes. -net bridge is syntactic sugar for -net tap with specific knowledge
of the qemu-bridge-helper.
If someone wrote a 'qemu-openvswitch-helper' then you could imagine a
'-net openvswitch' option that passed a bunch of openvswitch specific
arguments.
Regards,
Anthony Liguori
It seems like the helper should accept the following arguments:
--vnet-hdr --br=bridge name --fd=unix fd
(It already accept these, but the --br= and --fd= syntax aren't required at the
moment.)
Then QEMU would only allow the following to be specified for -netdev tap:
-netdev tap,helper=/usr/libexec/qemu-bridge-helper
or
-netdev tap,helper=/usr/libexec/qemu-bridge-helper --br=bridge
and would ignore or reject --vnet-hdr and --fd=. --vnet-hdr and --fd= would
always be specified internally when the helper is exec'd.
I don't know what you mean by ignore or reject. Just take whatever the helper
string is, concat --vnet-hdr --fd= as appropriate, and execute it via /bin/sh.
Regards,
Anthony Liguori
Re: [Qemu-devel] [PATCH] qemu-test: add virtio-serial test
On 12/22/2011 08:46 AM, Alex Bradbury wrote:
+
+in_host() {
+tmpchr=$tmpdir/chr.log
By far the most common error likely to appear in any of these test
scripts is insufficient shell quoting causing e.g. breakages when the
scripts are run from a directory with spaces.
Shell assignments do not need quoting, since they are not subject to
argument splitting or filename expansion in the first place.
Blindly requiring double-quoting of all shell variables and command
substitutions can actually introduce problems if you care about
portability to ancient shells, since constructs like:
var=`command with quotes`
are actually MORE portable than:
var=`command with quotes`
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] qemu-test: add virtio-serial test
On 22 December 2011 15:58, Eric Blake ebl...@redhat.com wrote: Shell assignments do not need quoting, since they are not subject to argument splitting or filename expansion in the first place. You're right, that was an incorrectly chosen example. Blindly requiring double-quoting of all shell variables and command substitutions can actually introduce problems if you care about portability to ancient shells Is there really a need to care about anything but POSIX compliant shells? Alex
Re: [Qemu-devel] [PATCH] qemu-test: add virtio-serial test
On 12/22/2011 09:46 AM, Alex Bradbury wrote:
On 22 December 2011 14:23, Anthony Liguorialigu...@us.ibm.com wrote:
This is a pretty simple test that just confirms that virtio-serial shows up and
is writable. It also tests the alias for virtio-serial-pci.
Signed-off-by: Anthony Liguorialigu...@us.ibm.com
---
tests/virtio-serial.sh | 52
1 files changed, 52 insertions(+), 0 deletions(-)
create mode 100755 tests/virtio-serial.sh
diff --git a/tests/virtio-serial.sh b/tests/virtio-serial.sh
new file mode 100755
index 000..e95ae6e
--- /dev/null
+++ b/tests/virtio-serial.sh
@@ -0,0 +1,52 @@
+#!/bin/sh
+
+canary=** waiting for... **
+
+in_host() {
+tmpchr=$tmpdir/chr.log
By far the most common error likely to appear in any of these test
scripts is insufficient shell quoting causing e.g. breakages when the
scripts are run from a directory with spaces. Having looked at
qemu-test, I see that $tmpdir is set to .tmp-$$ and so can never
contain spaces, and so it's fine to not quote the variable expansion.
That said, perhaps it would make it easier to review scripts and less
likely for these issues to creep in to the codebase if there was a
blanket rule that all variable expansions be quoted?
In general, I try to be very careful about that. The only time tests ever refer
to filenames is relative to tmpdir and as you've noted, tmpdir purposefully
cannot have a space in it.
So I don't think it's going to be a problem. I can't see an immediate reason
why tests should use anything outside of tmpdir.
Regards,
Anthony Liguori
Alex
Re: [Qemu-devel] [RFC PATCH] Exporting Guest RAM information for NUMA binding
On 12/22/2011 05:01 AM, Marcelo Tosatti wrote: On Thu, Dec 01, 2011 at 06:40:31PM +0100, Peter Zijlstra wrote: No virt is crap, it needs to die, its horrid, and any solution aimed squarely at virt only is shit and not worth considering, that simple. Removing this phrase from context (feel free to object on that basis to the following inquiry), what are your concerns with virtualization itself? Is it the fact that having an unknownable operating system under your feet uncomfortable only, or is there something else? Because virt is green, it saves silicon. Oh man, if you say virt solves global warming, I think I'm going to have to jump off a bridge to end the madness... Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 01/27] qom: add the base Object class
On Wed, Dec 21, 2011 at 08:35:16AM -0600, Anthony Liguori wrote:
On 12/21/2011 07:35 AM, Paolo Bonzini wrote:
What's the need for Type? You can use simply the TypeImpl * and drop
type_get_instance. Outside object.h it can be an opaque pointer.
It's a bit nicer for type_register to return a handle that can later
be unregistered (although that's not currently implemented).
You could have it return TypeImpl * of course. GObject uses a
simpler GType but they don't have the notion of a symbolic type
name.
I used a symbolic type name to avoid the problem of dependencies.
In order to create a type in gobject, you have to reference the
parent's GType which usually means you have to call the _get_type()
function which acts as a singleton which registers the type.
Since you have to specify the parent via a function call, you can't
define the type in a unit-level static structure which I viewed as a
critical requirement.
Why not declare types with something like the following:
TypeInfo my_device_info = {
.name = my-device,
.parentinfo = device_info,
.instance_size = sizeof(MyDevice),
};
That is, instead of looking up the TypeImpl via a string, lookup the
TypeImpl via the address of the TypeInfo. (Or possibly store a
pointer to TypeImpl in TypeInfo during registration.)
Module order shouldn't matter - all the info needed to register the
parent is there so it can be registered during first use. Indeed,
pass a TypeInfo* to object_new() and one should be able to skip the
registration step - if the type hasn't been registered the code can
detect that and automatically register it.
-Kevin
Re: [Qemu-devel] [PATCH 01/27] qom: add the base Object class
On 12/22/2011 11:25 AM, Kevin O'Connor wrote:
On Wed, Dec 21, 2011 at 08:35:16AM -0600, Anthony Liguori wrote:
On 12/21/2011 07:35 AM, Paolo Bonzini wrote:
What's the need for Type? You can use simply the TypeImpl * and drop
type_get_instance. Outside object.h it can be an opaque pointer.
It's a bit nicer for type_register to return a handle that can later
be unregistered (although that's not currently implemented).
You could have it return TypeImpl * of course. GObject uses a
simpler GType but they don't have the notion of a symbolic type
name.
I used a symbolic type name to avoid the problem of dependencies.
In order to create a type in gobject, you have to reference the
parent's GType which usually means you have to call the _get_type()
function which acts as a singleton which registers the type.
Since you have to specify the parent via a function call, you can't
define the type in a unit-level static structure which I viewed as a
critical requirement.
Why not declare types with something like the following:
TypeInfo my_device_info = {
.name = my-device,
.parentinfo =device_info,
.instance_size = sizeof(MyDevice),
};
That is, instead of looking up the TypeImpl via a string, lookup the
TypeImpl via the address of the TypeInfo. (Or possibly store a
pointer to TypeImpl in TypeInfo during registration.)
Module order shouldn't matter - all the info needed to register the
parent is there so it can be registered during first use.
The only problem with this is that if a .so implements the type, it means that
you have to have a way to figure out the dependency order as you load the modules.
OTOH, with the current approach, you can dlopen() all of the modules and
register the types, and then when the first object is instantiated, that's when
the type resolution will happen.
This way, modules can be very simple instead of having to encode dependency info
in a special elf section.
Indeed,
pass a TypeInfo* to object_new() and one should be able to skip the
registration step - if the type hasn't been registered the code can
detect that and automatically register it.
Yes, I did think of this, the problem is you want to be able to enumerate all of
the registered types before any objects may be instantiated. For instance, if
you did qemu -device ?
Regards,
Anthony Liguori
-Kevin
Re: [Qemu-devel] [PATCH 01/27] qom: add the base Object class
On Thu, Dec 22, 2011 at 11:41:08AM -0600, Anthony Liguori wrote:
On 12/22/2011 11:25 AM, Kevin O'Connor wrote:
On Wed, Dec 21, 2011 at 08:35:16AM -0600, Anthony Liguori wrote:
I used a symbolic type name to avoid the problem of dependencies.
In order to create a type in gobject, you have to reference the
parent's GType which usually means you have to call the _get_type()
function which acts as a singleton which registers the type.
Since you have to specify the parent via a function call, you can't
define the type in a unit-level static structure which I viewed as a
critical requirement.
Why not declare types with something like the following:
TypeInfo my_device_info = {
.name = my-device,
.parentinfo =device_info,
.instance_size = sizeof(MyDevice),
};
That is, instead of looking up the TypeImpl via a string, lookup the
TypeImpl via the address of the TypeInfo. (Or possibly store a
pointer to TypeImpl in TypeInfo during registration.)
Module order shouldn't matter - all the info needed to register the
parent is there so it can be registered during first use.
The only problem with this is that if a .so implements the type, it
means that you have to have a way to figure out the dependency order
as you load the modules.
OTOH, with the current approach, you can dlopen() all of the modules
and register the types, and then when the first object is
instantiated, that's when the type resolution will happen.
If device_info is a symbol in basedevice.so and mymodule.so has a
reference to device_info, wont dlopen(mymodule.so) automatically
bring in basedevice.so?
If not, then it seems like things would get sticky anyway - if the
underlying struct in mymodule.so is defined as:
typedef struct MyDevice
{
DeviceState parent;
int reg0, reg1, reg2;
} MyDevice;
it would seem likely that mymodule.so would have assorted references
to basedevice.so for calls on mydev.parent.
I think maybe I'm not understanding the use case.
Cheers,
-Kevin
[Qemu-devel] [PATCH v2 4/9] arm: add dummy gic security registers
From: Rob Herring rob.herr...@calxeda.com
Implement handling for the RAZ/WI gic security registers.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Mark Langsdorf mark.langsd...@calxeda.com
---
Changes from v1
Moved handling back inside the 0-0x100 block
Added more clarifying comments
hw/arm_gic.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/hw/arm_gic.c b/hw/arm_gic.c
index 9b52119..0339cf5 100644
--- a/hw/arm_gic.c
+++ b/hw/arm_gic.c
@@ -282,6 +282,10 @@ static uint32_t gic_dist_readb(void *opaque,
target_phys_addr_t offset)
return ((GIC_NIRQ / 32) - 1) | ((NUM_CPU(s) - 1) 5);
if (offset 0x08)
return 0;
+if (offset = 0x80) {
+/* Interrupt Security , RAZ/WI */
+return 0;
+}
#endif
goto bad_reg;
} else if (offset 0x200) {
@@ -413,6 +417,8 @@ static void gic_dist_writeb(void *opaque,
target_phys_addr_t offset,
DPRINTF(Distribution %sabled\n, s-enabled ? En : Dis);
} else if (offset 4) {
/* ignored. */
+} else if (offset = 0x80) {
+/* Interrupt Security Registers, RAZ/WI */
} else {
goto bad_reg;
}
--
1.7.5.4
[Qemu-devel] [PATCH v2 2/9] arm: Set frequencies for arm_timer
Use qdev properties to allow board modelers to set the frequencies
for the sp804 timer. Each of the sp804's timers can have an
individual frequency. The timers default to 1MHz.
Signed-off-by: Mark Langsdorf mark.langsd...@calxeda.com
---
Changes from v1
Simplified multiple timer frequency handling
Removed the shared default
hw/arm_timer.c | 26 +-
1 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/hw/arm_timer.c b/hw/arm_timer.c
index 0a5b9d2..d2738c7 100644
--- a/hw/arm_timer.c
+++ b/hw/arm_timer.c
@@ -9,6 +9,8 @@
#include sysbus.h
#include qemu-timer.h
+#include qemu-common.h
+#include qdev.h
/* Common timer implementation. */
@@ -178,6 +180,7 @@ typedef struct {
SysBusDevice busdev;
MemoryRegion iomem;
arm_timer_state *timer[2];
+int freq0, freq1;
int level[2];
qemu_irq irq;
} sp804_state;
@@ -269,10 +272,13 @@ static int sp804_init(SysBusDevice *dev)
qi = qemu_allocate_irqs(sp804_set_irq, s, 2);
sysbus_init_irq(dev, s-irq);
-/* ??? The timers are actually configurable between 32kHz and 1MHz, but
- we don't implement that. */
-s-timer[0] = arm_timer_init(100);
-s-timer[1] = arm_timer_init(100);
+/* The timers are configurable between 32kHz and 1MHz
+ * defaulting to 1MHz but overrideable as a property
+ * They can be configured individually as a property
+ * but default is shared frequency */
+s-timer[0] = arm_timer_init(s-freq0);
+s-timer[1] = arm_timer_init(s-freq1);
+
s-timer[0]-irq = qi[0];
s-timer[1]-irq = qi[1];
memory_region_init_io(s-iomem, sp804_ops, s, sp804, 0x1000);
@@ -281,6 +287,16 @@ static int sp804_init(SysBusDevice *dev)
return 0;
}
+static SysBusDeviceInfo sp804_info = {
+.init = sp804_init,
+.qdev.name = sp804,
+.qdev.size = sizeof(sp804_state),
+.qdev.props = (Property[]) {
+DEFINE_PROP_INT32(freq0, sp804_state, freq0, 100),
+DEFINE_PROP_INT32(freq1, sp804_state, freq1, 100),
+DEFINE_PROP_END_OF_LIST(),
+}
+};
/* Integrator/CP timer module. */
@@ -349,7 +365,7 @@ static int icp_pit_init(SysBusDevice *dev)
static void arm_timer_register_devices(void)
{
sysbus_register_dev(integrator_pit, sizeof(icp_pit_state), icp_pit_init);
-sysbus_register_dev(sp804, sizeof(sp804_state), sp804_init);
+sysbus_register_withprop(sp804_info);
}
device_init(arm_timer_register_devices)
--
1.7.5.4
[Qemu-devel] [PATCH v2 0/9] various ARM fixes
This is a collection of fixes and additions to the models for various ARM devices. These changes are needed to support the forthcoming Calxeda Highbank SoC model. Makefile.target |2 + hw/a9mpcore.c | 36 - hw/arm_gic.c|6 + hw/arm_l2x0.c | 173 + hw/arm_timer.c | 26 +++- hw/ide/ahci.c | 49 +- hw/ide/ich.c|4 +- hw/xgmac.c | 418 +++ target-arm/cpu.h|1 + target-arm/helper.c | 14 ++ 10 files changed, 712 insertions(+), 17 deletions(-)
[Qemu-devel] [PATCH 6/9] ahci: add support for non-PCI based controllers
From: Rob Herring rob.herr...@calxeda.com
Add support for ahci on sysbus.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Mark Langsdorf mark.langsd...@calxeda.com
---
hw/ide/ahci.c | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 135d0ee..8b56509 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -25,6 +25,7 @@
#include hw/msi.h
#include hw/pc.h
#include hw/pci.h
+#include hw/sysbus.h
#include monitor.h
#include dma.h
@@ -1214,3 +1215,37 @@ void ahci_reset(void *opaque)
ahci_reset_port(s, i);
}
}
+
+typedef struct PlatAHCIState {
+SysBusDevice busdev;
+AHCIState ahci;
+} PlatAHCIState;
+
+static int plat_ahci_init(SysBusDevice *dev)
+{
+PlatAHCIState *s = FROM_SYSBUS(PlatAHCIState, dev);
+ahci_init(s-ahci, dev-qdev, 1);
+
+sysbus_init_mmio(dev, s-ahci.mem);
+sysbus_init_irq(dev, s-ahci.irq);
+
+qemu_register_reset(ahci_reset, s-ahci);
+return 0;
+}
+
+static SysBusDeviceInfo plat_ahci_info[] = {
+{
+.qdev.name= plat-ahci,
+.qdev.size= sizeof(PlatAHCIState),
+.init = plat_ahci_init,
+},{
+/* end of list */
+}
+};
+
+static void plat_ahci_register(void)
+{
+sysbus_register_withprop(plat_ahci_info);
+}
+device_init(plat_ahci_register);
+
--
1.7.5.4
[Qemu-devel] [PATCH v2 8/9] Add xgmac ethernet model
This adds very basic support for XG-mac ethernet core from Synopsis and others. Missing things include: - statistics counters - WoL support - rx checksum offload - chained descriptors (only linear descriptor ring) - broadcast and multicast handling Signed-off-by: Rob Herring rob.herr...@calxeda.com Signed-off-by: Mark Langsdorf mark.langsd...@calxeda.com --- Changes from v1 Reformated most lines to fit within 80 columns Removed a bunch of unused variables in the state structures Got rid of some camelcase structure names Added vmstate support Makefile.target |1 + hw/xgmac.c | 418 +++ 2 files changed, 419 insertions(+), 0 deletions(-) create mode 100644 hw/xgmac.c diff --git a/Makefile.target b/Makefile.target index db5e44c..94cb9ff 100644 --- a/Makefile.target +++ b/Makefile.target @@ -340,6 +340,7 @@ obj-arm-y += arm_l2x0.o obj-arm-y += arm_mptimer.o obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o obj-arm-y += pl061.o +obj-arm-y += xgmac.o obj-arm-y += arm-semi.o obj-arm-y += pxa2xx.o pxa2xx_pic.o pxa2xx_gpio.o pxa2xx_timer.o pxa2xx_dma.o obj-arm-y += pxa2xx_lcd.o pxa2xx_mmci.o pxa2xx_pcmcia.o pxa2xx_keypad.o diff --git a/hw/xgmac.c b/hw/xgmac.c new file mode 100644 index 000..a496b31 --- /dev/null +++ b/hw/xgmac.c @@ -0,0 +1,418 @@ +/* + * QEMU model of XGMAC Ethernet. + * + * derived from the Xilinx AXI-Ethernet by Edgar E. Iglesias. + * + * Copyright (c) 2011 Calxeda, Inc. + * + * 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 ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN + * THE SOFTWARE. + */ + +#include sysbus.h +#include qemu-char.h +#include qemu-log.h +#include net.h +#include net/checksum.h + +#define XGMAC_CONTROL 0x /* MAC Configuration */ +#define XGMAC_FRAME_FILTER 0x0001 /* MAC Frame Filter */ +#define XGMAC_FLOW_CTRL 0x0006 /* MAC Flow Control */ +#define XGMAC_VLAN_TAG 0x0007 /* VLAN Tags */ +#define XGMAC_VERSION 0x0008 /* Version */ +/* VLAN tag for insertion or replacement into tx frames */ +#define XGMAC_VLAN_INCL 0x0009 +#define XGMAC_LPI_CTRL 0x000a /* LPI Control and Status */ +#define XGMAC_LPI_TIMER 0x000b /* LPI Timers Control */ +#define XGMAC_TX_PACE 0x000c /* Transmit Pace and Stretch */ +#define XGMAC_VLAN_HASH 0x000d /* VLAN Hash Table */ +#define XGMAC_DEBUG 0x000e /* Debug */ +#define XGMAC_INT_STATUS0x000f /* Interrupt and Control */ +/* HASH table registers */ +#define XGMAC_HASH(n) ((0x0300/4) + (n)) +#define XGMAC_NUM_HASH 16 +/* Operation Mode */ +#define XGMAC_OPMODE(0x0400/4) +/* Remote Wake-Up Frame Filter */ +#define XGMAC_REMOTE_WAKE (0x0700/4) +/* PMT Control and Status */ +#define XGMAC_PMT (0x0704/4) + +#define XGMAC_ADDR_HIGH(reg)(0x0010+((reg) * 2)) +#define XGMAC_ADDR_LOW(reg) (0x0011+((reg) * 2)) + +#define DMA_BUS_MODE0x03c0 /* Bus Mode */ +#define DMA_XMT_POLL_DEMAND 0x03c1 /* Transmit Poll Demand */ +#define DMA_RCV_POLL_DEMAND 0x03c2 /* Received Poll Demand */ +#define DMA_RCV_BASE_ADDR 0x03c3 /* Receive List Base */ +#define DMA_TX_BASE_ADDR0x03c4 /* Transmit List Base */ +#define DMA_STATUS 0x03c5 /* Status Register */ +#define DMA_CONTROL 0x03c6 /* Ctrl (Operational Mode) */ +#define DMA_INTR_ENA0x03c7 /* Interrupt Enable */ +#define DMA_MISSED_FRAME_CTR0x03c8 /* Missed Frame Counter */ +/* Receive Interrupt Watchdog Timer */ +#define DMA_RI_WATCHDOG_TIMER 0x03c9 +#define DMA_AXI_BUS 0x03ca /* AXI Bus Mode */ +#define DMA_AXI_STATUS 0x03cb /* AXI Status */ +#define DMA_CUR_TX_DESC_ADDR0x03d2 /* Current Host Tx Descriptor */
[Qemu-devel] [PATCH v2 1/9] arm: add missing scu registers
From: Rob Herring rob.herr...@calxeda.com
Add power control and non-secure access ctrl registers
Signed-off-by: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Mark Langsdorf mark.langsd...@calxeda.com
---
Changes from v1:
Added VMState support
Checked alignment of writes to the power control register
hw/a9mpcore.c | 34 --
1 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/hw/a9mpcore.c b/hw/a9mpcore.c
index cd2985f..875ae98 100644
--- a/hw/a9mpcore.c
+++ b/hw/a9mpcore.c
@@ -29,6 +29,7 @@ gic_get_current_cpu(void)
typedef struct a9mp_priv_state {
gic_state gic;
uint32_t scu_control;
+uint32_t scu_status;
uint32_t old_timer_status[8];
uint32_t num_cpu;
qemu_irq *timer_irq;
@@ -48,7 +49,13 @@ static uint64_t a9_scu_read(void *opaque, target_phys_addr_t
offset,
case 0x04: /* Configuration */
return (((1 s-num_cpu) - 1) 4) | (s-num_cpu - 1);
case 0x08: /* CPU Power Status */
-return 0;
+return s-scu_status;
+case 0x09: /* CPU status. */
+return s-scu_status 8;
+case 0x0a: /* CPU status. */
+return s-scu_status 16;
+case 0x0b: /* CPU status. */
+return s-scu_status 24;
case 0x0c: /* Invalidate All Registers In Secure State */
return 0;
case 0x40: /* Filtering Start Address Register */
@@ -73,6 +80,29 @@ static void a9_scu_write(void *opaque, target_phys_addr_t
offset,
break;
case 0x4: /* Configuration: RO */
break;
+case 0x08: /* Power Control */
+s-scu_status = value;
+break;
+case 0x09: /* Power Control */
+s-scu_status = ~(0xff 8);
+s-scu_status |= (value 0xff) 8;
+break;
+case 0x0A: /* Power Control */
+if (size == 1) {
+s-scu_status = ~(0xff 16);
+s-scu_status |= (value 0xff) 16;
+} else if (size == 2) {
+s-scu_status = ~(0x 16);
+s-scu_status |= (value 0x) 16;
+} else {
+/* illegal number of bytes */
+break;
+}
+break;
+case 0x0B: /* Power Control */
+s-scu_status = ~(0xff 24);
+s-scu_status |= (value 0xff) 24;
+break;
case 0x0c: /* Invalidate All Registers In Secure State */
/* no-op as we do not implement caches */
break;
@@ -80,7 +110,6 @@ static void a9_scu_write(void *opaque, target_phys_addr_t
offset,
case 0x44: /* Filtering End Address Register */
/* RAZ/WI, like an implementation with only one AXI master */
break;
-case 0x8: /* CPU Power Status */
case 0x50: /* SCU Access Control Register */
case 0x54: /* SCU Non-secure Access Control Register */
/* unimplemented, fall through */
@@ -173,6 +202,7 @@ static const VMStateDescription vmstate_a9mp_priv = {
.minimum_version_id = 1,
.fields = (VMStateField[]) {
VMSTATE_UINT32(scu_control, a9mp_priv_state),
+VMSTATE_UINT32(scu_status, a9mp_priv_state),
VMSTATE_UINT32_ARRAY(old_timer_status, a9mp_priv_state, 8),
VMSTATE_END_OF_LIST()
}
--
1.7.5.4
[Qemu-devel] [PATCH 9/9] arm: increase a9mp interrupts to 160
From: Rob Herring rob.herr...@calxeda.com Signed-off-by: Rob Herring rob.herr...@calxeda.com Signed-off-by: Mark Langsdorf mark.langsd...@calxeda.com --- hw/a9mpcore.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/a9mpcore.c b/hw/a9mpcore.c index 875ae98..93b0498 100644 --- a/hw/a9mpcore.c +++ b/hw/a9mpcore.c @@ -13,7 +13,7 @@ /* Configuration for arm_gic.c: * number of external IRQ lines, max number of CPUs, how to ID current CPU */ -#define GIC_NIRQ 96 +#define GIC_NIRQ 160 #define NCPU 4 static inline int -- 1.7.5.4
[Qemu-devel] [PATCH v2 3/9] arm: add dummy v7 cp15 config_base_register
Add a cp15 config_base_register that currently defaults to 0.
After the QOM CPU support is added, the value will be properly
set to the periphal base value.
Signed-off-by: Mark Langsdorf mark.langsd...@calxeda.com
---
Changes from v1
renamed the register
added comments about how it will change when QOM CPUs are added
target-arm/cpu.h|1 +
target-arm/helper.c | 14 ++
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index c4d742f..449e620 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -149,6 +149,7 @@ typedef struct CPUARMState {
uint32_t c15_i_max; /* Maximum D-cache dirty line index. */
uint32_t c15_i_min; /* Minimum D-cache dirty line index. */
uint32_t c15_threadid; /* TI debugger thread-ID. */
+uint32_t c15_config_base_address; /* SCU base address. */
} cp15;
struct {
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 65f4fbf..3899a43 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -2111,6 +2111,20 @@ uint32_t HELPER(get_cp15)(CPUState *env, uint32_t insn)
* 0x200 ($rn 0xfff), when MMU is off. */
goto bad_reg;
}
+if (ARM_CPUID(env) == ARM_CPUID_CORTEXA9) {
+switch (crm) {
+case 0:
+/* The config_base_address should hold the value of
+ * the peripheral base. ARM should get this from a CPU
+ * object property, but that support isn't available in
+ * December 2011. Default to 0 for now and board models
+ * that care can set it by a private hook */
+if (op1 == 4) {
+return env-cp15.c15_config_base_address;
+}
+}
+goto bad_reg;
+}
return 0;
}
bad_reg:
--
1.7.5.4
[Qemu-devel] [PATCH 5/9] ahci: convert ahci_reset to use AHCIState
From: Rob Herring rob.herr...@calxeda.com
Use AHCIState instead of AHCIPCIState so the function can be used for
non-PCI based AHCI controllers.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Mark Langsdorf mark.langsd...@calxeda.com
---
hw/ide/ahci.c | 14 +++---
hw/ide/ich.c |4 ++--
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index 0af201d..135d0ee 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -336,7 +336,7 @@ static void ahci_mem_write(void *opaque, target_phys_addr_t
addr,
case HOST_CTL: /* R/W */
if (val HOST_CTL_RESET) {
DPRINTF(-1, HBA Reset\n);
-ahci_reset(container_of(s, AHCIPCIState, ahci));
+ahci_reset(s);
} else {
s-control_regs.ghc = (val 0x3) | HOST_CTL_AHCI_EN;
ahci_check_irq(s);
@@ -1199,18 +1199,18 @@ void ahci_uninit(AHCIState *s)
void ahci_reset(void *opaque)
{
-struct AHCIPCIState *d = opaque;
+struct AHCIState *s = opaque;
AHCIPortRegs *pr;
int i;
-d-ahci.control_regs.irqstatus = 0;
-d-ahci.control_regs.ghc = 0;
+s-control_regs.irqstatus = 0;
+s-control_regs.ghc = 0;
-for (i = 0; i d-ahci.ports; i++) {
-pr = d-ahci.dev[i].port_regs;
+for (i = 0; i s-ports; i++) {
+pr = s-dev[i].port_regs;
pr-irq_stat = 0;
pr-irq_mask = 0;
pr-scr_ctl = 0;
-ahci_reset_port(d-ahci, i);
+ahci_reset_port(s, i);
}
}
diff --git a/hw/ide/ich.c b/hw/ide/ich.c
index 3f7510f..44363ec 100644
--- a/hw/ide/ich.c
+++ b/hw/ide/ich.c
@@ -102,7 +102,7 @@ static int pci_ich9_ahci_init(PCIDevice *dev)
/* XXX Software should program this register */
d-card.config[0x90] = 1 6; /* Address Map Register - AHCI mode */
-qemu_register_reset(ahci_reset, d);
+qemu_register_reset(ahci_reset, d-ahci);
msi_init(dev, 0x50, 1, true, false);
d-ahci.irq = d-card.irq[0];
@@ -133,7 +133,7 @@ static int pci_ich9_uninit(PCIDevice *dev)
d = DO_UPCAST(struct AHCIPCIState, card, dev);
msi_uninit(dev);
-qemu_unregister_reset(ahci_reset, d);
+qemu_unregister_reset(ahci_reset, d-ahci);
ahci_uninit(d-ahci);
return 0;
--
1.7.5.4
Re: [Qemu-devel] [RFC PATCH] Exporting Guest RAM information for NUMA binding
On Thu, 2011-12-22 at 09:01 -0200, Marcelo Tosatti wrote: No virt is crap, it needs to die, its horrid, and any solution aimed squarely at virt only is shit and not worth considering, that simple. Removing this phrase from context (feel free to object on that basis to the following inquiry), what are your concerns with virtualization itself? Is it the fact that having an unknownable operating system under your feet uncomfortable only, or is there something else? Because virt is green, it saves silicon. No, you're going the wrong way around that argument. Resource control would save the planet in that case. That's an entirely separate concept from virtualization. Look how much cgroup crap you still need on top of the whole virt thing. Virt deals with running legacy OSs, mostly because you're in a bind and for a host of reasons can't get this super critical application you really must have running on your new and improved platform. So you emulate hardware to run the old os, to run the old app or somesuch nonsense. Virt really is mostly a technical solution to a mostly non-technical problem. There's of course the debug angle, but I've never really found it reliable enough to use in that capacity, give me real hardware with a serial port any day of the week. Also, it just really offends me, we work really hard to make stuff go as fast as possible and then you stick a gigantic emulation layer in between and complain that shit is slow again. Don't do that!!
[Qemu-devel] [PATCH v2 7/9] add L2x0/PL310 cache controller device
From: Rob Herring rob.herr...@calxeda.com
This is just a dummy device for ARM L2 cache controllers, based on the
pl310. The cache type parameter can be defined by a property value
and has a meaningful default.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Mark Langsdorf mark.langsd...@calxeda.com
---
Changes from v1
Corrected formatting
Clarified the copyrights
Clarified GPL revision
Clarified model version
Removed hw_error() calls
Added a reset function
Restructed everything as switch/case statements
Added a type cache property
Makefile.target |1 +
hw/arm_l2x0.c | 173 +++
2 files changed, 174 insertions(+), 0 deletions(-)
create mode 100644 hw/arm_l2x0.c
diff --git a/Makefile.target b/Makefile.target
index 3261383..db5e44c 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -336,6 +336,7 @@ obj-arm-y = integratorcp.o versatilepb.o arm_pic.o
arm_timer.o
obj-arm-y += arm_boot.o pl011.o pl031.o pl050.o pl080.o pl110.o pl181.o pl190.o
obj-arm-y += versatile_pci.o
obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o
+obj-arm-y += arm_l2x0.o
obj-arm-y += arm_mptimer.o
obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o
obj-arm-y += pl061.o
diff --git a/hw/arm_l2x0.c b/hw/arm_l2x0.c
new file mode 100644
index 000..84f6c5a
--- /dev/null
+++ b/hw/arm_l2x0.c
@@ -0,0 +1,173 @@
+/*
+ * ARM dummy L210, L220, PL310 cache controller.
+ *
+ * Copyright (c) 2010-2012 Calxeda
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ *
+ */
+
+#include sysbus.h
+
+/* L2C-310 r3p1 */
+#define CACHE_ID 0x41c6
+#define DEFAULT_CACHE_TYPE 0x19080800
+
+typedef struct l2x0_state {
+SysBusDevice busdev;
+MemoryRegion iomem;
+uint32_t cache_type;
+uint32_t ctrl;
+uint32_t aux_ctrl;
+uint32_t data_ctrl;
+uint32_t tag_ctrl;
+uint32_t filter_start;
+uint32_t filter_end;
+} l2x0_state;
+
+static const VMStateDescription vmstate_l2x0 = {
+.name = l2x0,
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(ctrl, l2x0_state),
+VMSTATE_UINT32(aux_ctrl, l2x0_state),
+VMSTATE_UINT32(data_ctrl, l2x0_state),
+VMSTATE_UINT32(tag_ctrl, l2x0_state),
+VMSTATE_UINT32(filter_start, l2x0_state),
+VMSTATE_UINT32(filter_end, l2x0_state),
+VMSTATE_END_OF_LIST()
+}
+};
+
+
+static uint64_t l2x0_priv_read(void *opaque, target_phys_addr_t offset,
unsigned size)
+{
+l2x0_state *s = (l2x0_state *)opaque;
+offset = 0xfff;
+if (offset = 0x730 offset 0x800) {
+return 0; /* cache ops complete */
+}
+switch (offset) {
+case 0:
+return CACHE_ID;
+case 0x4:
+return s-cache_type;
+case 0x100:
+return s-ctrl;
+case 0x104:
+return s-aux_ctrl;
+case 0x108:
+return s-tag_ctrl;
+case 0x10C:
+return s-data_ctrl;
+case 0xC00:
+return s-filter_start;
+case 0xC04:
+return s-filter_end;
+case 0xF40:
+return 0;
+case 0xF60:
+return 0;
+case 0xF80:
+return 0;
+default:
+fprintf(stderr, l2x0_priv_read: Bad offset %x\n, (int)offset);
+break;
+}
+return 0;
+}
+
+static void l2x0_priv_write(void *opaque, target_phys_addr_t offset, uint64_t
value, unsigned size)
+{
+l2x0_state *s = (l2x0_state *)opaque;
+offset = 0xfff;
+if (offset = 0x730 offset 0x800) {
+/* ignore */
+return;
+}
+switch (offset) {
+case 0x100:
+s-ctrl = value 1;
+break;
+case 0x104:
+s-aux_ctrl = value;
+break;
+case 0x108:
+s-tag_ctrl = value;
+break;
+case 0x10C:
+s-data_ctrl = value;
+break;
+case 0xC00:
+s-filter_start = value;
+break;
+case 0xC04:
+s-filter_end = value;
+break;
+case 0xF40:
+return;
+case 0xF60:
+return;
+case 0xF80:
+return;
+default:
+fprintf(stderr, l2x0_priv_write: Bad offset %x\n, (int)offset);
+break;
+}
+}
+
+static int l2x0_priv_reset(SysBusDevice *dev)
+{
+l2x0_state *s = FROM_SYSBUS(l2x0_state, dev);
+
+s-aux_ctrl = 0x0002;
+return 0;
+}
+
+static const MemoryRegionOps
Re: [Qemu-devel] [PATCH 01/27] qom: add the base Object class
On 12/22/2011 12:00 PM, Kevin O'Connor wrote:
On Thu, Dec 22, 2011 at 11:41:08AM -0600, Anthony Liguori wrote:
On 12/22/2011 11:25 AM, Kevin O'Connor wrote:
On Wed, Dec 21, 2011 at 08:35:16AM -0600, Anthony Liguori wrote:
I used a symbolic type name to avoid the problem of dependencies.
In order to create a type in gobject, you have to reference the
parent's GType which usually means you have to call the _get_type()
function which acts as a singleton which registers the type.
Since you have to specify the parent via a function call, you can't
define the type in a unit-level static structure which I viewed as a
critical requirement.
Why not declare types with something like the following:
TypeInfo my_device_info = {
.name = my-device,
.parentinfo =device_info,
.instance_size = sizeof(MyDevice),
};
That is, instead of looking up the TypeImpl via a string, lookup the
TypeImpl via the address of the TypeInfo. (Or possibly store a
pointer to TypeImpl in TypeInfo during registration.)
Module order shouldn't matter - all the info needed to register the
parent is there so it can be registered during first use.
The only problem with this is that if a .so implements the type, it
means that you have to have a way to figure out the dependency order
as you load the modules.
OTOH, with the current approach, you can dlopen() all of the modules
and register the types, and then when the first object is
instantiated, that's when the type resolution will happen.
If device_info is a symbol in basedevice.so and mymodule.so has a
reference to device_info, wont dlopen(mymodule.so) automatically
bring in basedevice.so?
If not, then it seems like things would get sticky anyway - if the
underlying struct in mymodule.so is defined as:
typedef struct MyDevice
{
DeviceState parent;
int reg0, reg1, reg2;
} MyDevice;
it would seem likely that mymodule.so would have assorted references
to basedevice.so for calls on mydev.parent.
Yes, thinking about it, I think you're correct that .parent could refer to some
sort of type handle.
But I think it's a bit nicer to have a string identify the parent type than an
extern struct. I guess it's more a matter of taste than anything else :-)
Regards,
Anthony Liguori
I think maybe I'm not understanding the use case.
Cheers,
-Kevin
[Qemu-devel] [PATCH 2/5] kvm: x86: Avoid runtime allocation of xsave buffer
From: Jan Kiszka jan.kis...@siemens.com
Keep a per-VCPU xsave buffer for kvm_put/get_xsave instead of
continuously allocating and freeing it on state sync.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
---
target-i386/cpu.h |3 ++-
target-i386/kvm.c | 15 +++
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index a08ce9d..37dde79 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -751,7 +751,8 @@ typedef struct CPUX86State {
uint32_t cpuid_svm_features;
bool tsc_valid;
int tsc_khz;
-
+void *kvm_xsave_buf;
+
/* in order to simplify APIC support, we leave this pointer to the
user */
struct DeviceState *apic_state;
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index d2f70f9..06f4401 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -516,6 +516,10 @@ int kvm_arch_init_vcpu(CPUState *env)
}
}
+if (kvm_has_xsave()) {
+env-kvm_xsave_buf = qemu_memalign(4096, sizeof(struct kvm_xsave));
+}
+
return 0;
}
@@ -771,15 +775,14 @@ static int kvm_put_fpu(CPUState *env)
static int kvm_put_xsave(CPUState *env)
{
-int i, r;
-struct kvm_xsave* xsave;
+struct kvm_xsave* xsave = env-kvm_xsave_buf;
uint16_t cwd, swd, twd;
+int i, r;
if (!kvm_has_xsave()) {
return kvm_put_fpu(env);
}
-xsave = qemu_memalign(4096, sizeof(struct kvm_xsave));
memset(xsave, 0, sizeof(struct kvm_xsave));
twd = 0;
swd = env-fpus ~(7 11);
@@ -801,7 +804,6 @@ static int kvm_put_xsave(CPUState *env)
memcpy(xsave-region[XSAVE_YMMH_SPACE], env-ymmh_regs,
sizeof env-ymmh_regs);
r = kvm_vcpu_ioctl(env, KVM_SET_XSAVE, xsave);
-g_free(xsave);
return r;
}
@@ -978,7 +980,7 @@ static int kvm_get_fpu(CPUState *env)
static int kvm_get_xsave(CPUState *env)
{
-struct kvm_xsave* xsave;
+struct kvm_xsave* xsave = env-kvm_xsave_buf;
int ret, i;
uint16_t cwd, swd, twd;
@@ -986,10 +988,8 @@ static int kvm_get_xsave(CPUState *env)
return kvm_get_fpu(env);
}
-xsave = qemu_memalign(4096, sizeof(struct kvm_xsave));
ret = kvm_vcpu_ioctl(env, KVM_GET_XSAVE, xsave);
if (ret 0) {
-g_free(xsave);
return ret;
}
@@ -1013,7 +1013,6 @@ static int kvm_get_xsave(CPUState *env)
env-xstate_bv = *(uint64_t *)xsave-region[XSAVE_XSTATE_BV];
memcpy(env-ymmh_regs, xsave-region[XSAVE_YMMH_SPACE],
sizeof env-ymmh_regs);
-g_free(xsave);
return 0;
}
--
1.7.6.4
[Qemu-devel] [PATCH 5/5] enable architectural PMU cpuid leaf for kvm
From: Gleb Natapov g...@redhat.com
Signed-off-by: Gleb Natapov g...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
---
target-i386/cpuid.c | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index 0b3af90..91a104b 100644
--- a/target-i386/cpuid.c
+++ b/target-i386/cpuid.c
@@ -1180,10 +1180,19 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
break;
case 0xA:
/* Architectural Performance Monitoring Leaf */
-*eax = 0;
-*ebx = 0;
-*ecx = 0;
-*edx = 0;
+if (kvm_enabled()) {
+KVMState *s = env-kvm_state;
+
+*eax = kvm_arch_get_supported_cpuid(s, 0xA, count, R_EAX);
+*ebx = kvm_arch_get_supported_cpuid(s, 0xA, count, R_EBX);
+*ecx = kvm_arch_get_supported_cpuid(s, 0xA, count, R_ECX);
+*edx = kvm_arch_get_supported_cpuid(s, 0xA, count, R_EDX);
+} else {
+*eax = 0;
+*ebx = 0;
+*ecx = 0;
+*edx = 0;
+}
break;
case 0xD:
/* Processor Extended State */
--
1.7.6.4
[Qemu-devel] [PATCH 3/5] kvm: x86: Drop redundant apic base and tpr update from kvm_get_sregs
From: Jan Kiszka jan.kis...@siemens.com The latter was already commented out, the former is redundant as well. We always get the latest changes after return from the guest via kvm_arch_post_run. Signed-off-by: Jan Kiszka jan.kis...@siemens.com Signed-off-by: Marcelo Tosatti mtosa...@redhat.com --- target-i386/kvm.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/target-i386/kvm.c b/target-i386/kvm.c index 06f4401..d206852 100644 --- a/target-i386/kvm.c +++ b/target-i386/kvm.c @@ -1082,10 +1082,9 @@ static int kvm_get_sregs(CPUState *env) env-cr[3] = sregs.cr3; env-cr[4] = sregs.cr4; -cpu_set_apic_base(env-apic_state, sregs.apic_base); - env-efer = sregs.efer; -//cpu_set_apic_tpr(env-apic_state, sregs.cr8); + +/* changes to apic base and cr8/tpr are read back via kvm_arch_post_run */ #define HFLAG_COPY_MASK \ ~( HF_CPL_MASK | HF_PE_MASK | HF_MP_MASK | HF_EM_MASK | \ -- 1.7.6.4
Re: [Qemu-devel] [PATCH 01/27] qom: add the base Object class
On 12/22/2011 06:25 PM, Kevin O'Connor wrote:
Why not declare types with something like the following:
TypeInfo my_device_info = {
.name = my-device,
.parentinfo =device_info,
.instance_size = sizeof(MyDevice),
};
That is, instead of looking up the TypeImpl via a string, lookup the
TypeImpl via the address of the TypeInfo. (Or possibly store a
pointer to TypeImpl in TypeInfo during registration.)
This requires all modules to provide a header file just for the TypeInfo
or TypeImpl. It doesn't let you use work purely through introspection.
Paolo
[Qemu-devel] [PATCH 4/5] Set numa topology for max_cpus
From: Vasilis Liaskovitis vasilis.liaskovi...@profitbricks.com
qemu-kvm passes numa/SRAT topology information for smp_cpus to SeaBIOS. However
SeaBIOS always expects to setup max_cpus number of SRAT cpu entries
(MaxCountCPUs variable in build_srat function of Seabios). When qemu-kvm runs
with smp_cpus != max_cpus (e.g. -smp 2,maxcpus=4), Seabios will mistakenly use
memory SRAT info for setting up CPU SRAT entries for the offline CPUs. Wrong
SRAT memory entries are also created. This breaks NUMA in a guest.
Fix by setting up SRAT info for max_cpus in qemu-kvm.
Signed-off-by: Vasilis Liaskovitis vasilis.liaskovi...@profitbricks.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
---
hw/pc.c |8
vl.c|2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/hw/pc.c b/hw/pc.c
index 3a71992..f51afa8 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -624,9 +624,9 @@ static void *bochs_bios_init(void)
* of nodes, one word for each VCPU-node and one word for each node to
* hold the amount of memory.
*/
-numa_fw_cfg = g_malloc0((1 + smp_cpus + nb_numa_nodes) * 8);
+numa_fw_cfg = g_malloc0((1 + max_cpus + nb_numa_nodes) * 8);
numa_fw_cfg[0] = cpu_to_le64(nb_numa_nodes);
-for (i = 0; i smp_cpus; i++) {
+for (i = 0; i max_cpus; i++) {
for (j = 0; j nb_numa_nodes; j++) {
if (node_cpumask[j] (1 i)) {
numa_fw_cfg[i + 1] = cpu_to_le64(j);
@@ -635,10 +635,10 @@ static void *bochs_bios_init(void)
}
}
for (i = 0; i nb_numa_nodes; i++) {
-numa_fw_cfg[smp_cpus + 1 + i] = cpu_to_le64(node_mem[i]);
+numa_fw_cfg[max_cpus + 1 + i] = cpu_to_le64(node_mem[i]);
}
fw_cfg_add_bytes(fw_cfg, FW_CFG_NUMA, (uint8_t *)numa_fw_cfg,
- (1 + smp_cpus + nb_numa_nodes) * 8);
+ (1 + max_cpus + nb_numa_nodes) * 8);
return fw_cfg;
}
diff --git a/vl.c b/vl.c
index c03abb6..d925424 100644
--- a/vl.c
+++ b/vl.c
@@ -3305,7 +3305,7 @@ int main(int argc, char **argv, char **envp)
* real machines which also use this scheme.
*/
if (i == nb_numa_nodes) {
-for (i = 0; i smp_cpus; i++) {
+for (i = 0; i max_cpus; i++) {
node_cpumask[i % nb_numa_nodes] |= 1 i;
}
}
--
1.7.6.4
Re: [Qemu-devel] [RFC PATCH] Exporting Guest RAM information for NUMA binding
On Thu, Dec 22, 2011 at 11:13:15AM -0600, Anthony Liguori wrote: On 12/22/2011 05:01 AM, Marcelo Tosatti wrote: On Thu, Dec 01, 2011 at 06:40:31PM +0100, Peter Zijlstra wrote: No virt is crap, it needs to die, its horrid, and any solution aimed squarely at virt only is shit and not worth considering, that simple. Removing this phrase from context (feel free to object on that basis to the following inquiry), what are your concerns with virtualization itself? Is it the fact that having an unknownable operating system under your feet uncomfortable only, or is there something else? Because virt is green, it saves silicon. Oh man, if you say virt solves global warming, I think I'm going to have to jump off a bridge to end the madness... I said it is green (saves energy) and it saves silicon (therefore saves fuel?). The rest of conclusions are your own.
[Qemu-devel] Lingerie Sale - Limited Time Offer
This email newsletter was sent to you in graphical HTML format. If you're seeing this version, your email program prefers plain text emails. You can read the original version online: http://ymlp223.net/zTi0Mw Dear Customer HAPPY HOLIDAYS AND A GREAT NEW YEAR!!! DUE TO THE GREAT SUCCESS OF OUR BLACK FRIDAY FREE SHIPPING SALE WE HAVE DECIDED TO RENEW OUR FREE SHIPPING THRU THE NEW YEAR TILL TUESDAY JANUARY 3rd 2012!!! THAT'S RIGHT! HOSIERYSTREET.com IS OFFERING FREE SHIPPING on all orders over $25 in contiguous US TILL TUESDAY JANUARY 3rd!!! This is our way of saying THANK YOU to all of our loyal customers for making us the GREATEST HOSIERY and LINGERIE website on the net. As in every email we would like to remind you first and foremost that if you don't want to be on our sale list please click below to unsubscribe and you will be removed from the email list immediately. We do not want to SPAM anyone. PLEASE DO NOT REPORT THIS AS SPAM. HAPPY HOLIDAYS!!! ( http://hosierystreet.com/refer=em_1222i ) The following is a few of our HOTTEST items you may be interested in: 5 HOTTEST DEALS FROM BESTFORM ( http://www.hosierystreet.com/system/scripts/search.cgi?p=1Company=BestformSubmit2=Searchaction=searchper_page=90sort_by=Brand#Searchrefer=em_1222i ). NOW ONLY: $7.99 Bestform Soft Cup Wide, camisole top band bottom . #6825 Click here for more info ( http://www.hosierystreet.com/system/scripts/results_big.cgi?product=bf6825refer=em_1222i )NOW ONLY: $6.99 Bestform BodyCottons Underwire # 6826 Click here for more info ( http://www.hosierystreet.com/system/scripts/results_big.cgi?product=bf6826refer=em_1222i ) NOW ONLY: $7.56 Bestform Relax Wear # 6088 Click here for more info ( http://www.hosierystreet.com/system/scripts/results_big.cgi?product=bf6088refer=em_1222i )NOW ONLY: $8.99 Bestform Shirred Front Sport Bra. #6040 Click here for more info ( http://www.hosierystreet.com/system/scripts/results_big.cgi?product=bef6040refer=em_1222i )NOW ONLY: $9.99 Bestform Posture back sport bra with double lined front Cris-Cross Click here for more info ( http://www.hosierystreet.com/system/scripts/results_big.cgi?product=bef6092xrefer=em_1222i ) or click here for more BestForm Bras at Greatly Discounted Prices... ( http://www.hosierystreet.com/system/scripts/search.cgi?p=1Company=BestformSubmit2=Searchaction=searchper_page=90sort_by=Brand#Searchrefer=em_1222i ) DUE TO POULAR DEMAND NOW BACK IN STOCK!!! 2 HOT DEALS FROM Round the Clock ( http://www.hosierystreet.com/system/scripts/search.cgi?Company=Round+The+ClockSubmit2=Searchaction=searchrefer=em_1222i )! NOW ONLY: $12.99 Round The Clock Classic Sheer, Girdle at the Top # 135 Click here for more info ( http://www.hosierystreet.com/system/scripts/results_big.cgi?product=rtc135refer=em_1222i )NOW ONLY: $13.99 Round The Clock Girdle at the Top, Lycra Silky Sheer Leg Pantyhose # 137 Click here for more info ( http://www.hosierystreet.com/system/scripts/results_big.cgi?product=rtc137refer=em_1222i ) or click here for more Round The Clock Deals... ( http://www.hosierystreet.com/system/scripts/search.cgi?Company=Round+The+ClockSubmit2=Searchaction=searchrefer=em_1222i ) 6 MORE GREAT DEALS FROM VASSARETTE ( http://www.hosierystreet.com/system/scripts/search.cgi?p=1txtSearch=search_type=in_allcategory=21Company=Vassaretteprice_from=price_to=command=advance_searchaction=searchcmdGetCustomers=Get+Resultper_page=90sort_by=Brand#Searchrefer=em_1222i ). NOW ONLY: $3.49 Vassarette Light Control Hi-Cut Brief Click here for more info ( http://www.hosierystreet.com/system/scripts/results_big.cgi?product=48-001refer=em_1222i )NOW ONLY: $3.99 Vassarette Light Control Brief Click here for more info ( http://www.hosierystreet.com/system/scripts/results_big.cgi?product=40-001refer=em_1222i )NOW ONLY: $5.99 Vassarette Soft Simple Bright Lines Soft Cup. #70-177 Click here for more info ( http://www.hosierystreet.com/system/scripts/results_big.cgi?product=70-177refer=em_1222i ) NOW ONLY: $9.89 Vassarette BodyCurves Microfiber Wireless Contour Click here for more info ( http://www.hosierystreet.com/system/scripts/results_big.cgi?product=72-239refer=em_1222i )NOW ONLY: $10.99 Vassarette RealSexy Her Secret Push Up UW Click here for more info ( http://www.hosierystreet.com/system/scripts/results_big.cgi?product=75-320refer=em_1222i ) NOW ONLY: $12.89 Vassarette BodyCurves Flir-T FF Contour UW. #75-818 Click here for more info ( http://www.hosierystreet.com/system/scripts/results_big.cgi?product=75-818refer=em_1222i ) or click here for more ON SALE Vassarette Bras... (
Re: [Qemu-devel] [PATCH] iSCSI: add configuration variables for iSCSI
Hi, You mean using the '-S' mode and setting the key after qemu has initialized all devices but before it actually starts booting the guest? That would not be easy and would probably require some intrusive in qemu itself that might affect other device types, so I am unsure. The difference between qcow2 and iscsi and the problem is that .open() is called for all devices before the monitor is started, so .open() is called before we would have a chance to even hand the password to qemu. For qcow2 this is not a problem since even if the file is password protected the file header is not, so you can still open the file and read the header (to discover it is password protected) without knowing the password. So qcow2 can still open the file and do all the sanity checks it needs without yet knowing the password. You only need the password at a much later at the stage when you want to actually start doing I/O to the device. iSCSI is different because the username/password is not really associated with the LUN or doing I/O, the password is required to connect to the iscsi target itself, so without the password we can not even connect to the target, much less run REPORTLUNS or TESTUNITREADY to check if the LUN even exists. We cant even check if the target iqn name even exists at all without the password. So to pass the password similarly to how qcow2 does it, I see three options, neither of which are especially attractive : 1, Change iscsi_open() to become a NOOP, dont even try to connect to the target until the CPU is started (and -S has passed the password) and do the connect on first i/o instead of .open() This would mean that if the target or the LUN does not even exist at all, we wont get an early failure where QEMU would fail to start due to the device does not exist, instead the error would be postponed until much later and cause qemu to error out on first i/o. This looks like a horrible kludge. 2, Change -S so that it is called before qemu calls any of the .open() functions for block devices. I am not sure what impact this would have and if -S users would be surprised if the monitor is open but the block devices have not yet been scanned. This looks difficult to easily integrate with the command line parsing anyway. This too sounds like a horrible kludge. 3, Add a new block device method .open_post_start() which is just like .open() but invoked after the CPU has been started. So .open() is called like today before -S monitor is started, then the new .open_post_start() would be called once -S has started the CPU with the 'c' command. In this case for iscsi, .open() could be changed to just create a context for the device and establish the TCP connection to the target but it would not log in to the target. .open_post_start() which could be called for all block devices once the CPU has been started would then use the context and connection from .open() and perform the actual login and discover the LUN. 3 would still be a little bit ugly since a whole set of error conditions such as target iqn does not exist, lun does not exist, wrong type of LUN, incorrect password ... would not be detected until once the guest CPU is actually started. Would be less ugly than options 1,2 though. But even with something like option 3, to make it possible to use -S to provide the password, this is mainly for addressing the case when running via libvirt ? I still want to provide a mechanism for setting the password directly in a configuration file for users that run qemu directly from the command line and are not using -S. comments ? regards ronnie sahlberg On Mon, Dec 19, 2011 at 12:48 AM, Paolo Bonzini pbonz...@redhat.com wrote: On 12/18/2011 05:48 AM, Ronnie Sahlberg wrote: This patch adds configuration variables for iSCSI to set initiator-name to use when logging in to the target, which type of header-digest to negotiate with the target and username and password for CHAP authentication. This allows specifying a initiator-name either from the command line -iscsi initiator-name=iqn.2004-01.com.example:test or from a configuration file included with -readconfig [iscsi] initiator-name = iqn.2004-01.com.example:test header-digest = CRC32C|CRC32C-NONE|NONE-CRC32C|NONE user = CHAP username password = CHAP password header digest and user look like they should be options to the block driver. For the password you can reuse the system used by qcow2 perhaps? Paolo
[Qemu-devel] [PATCH 0/5] [PULL] qemu-kvm.git uq/master queue
The following changes since commit 03ecd2c80a64d030a22fe67cc7a60f24e17ff211: virtio-serial-bus: Ports are expected to implement 'have_data' callback (2011-12-21 15:00:29 -0600) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master Gleb Natapov (1): enable architectural PMU cpuid leaf for kvm Jan Kiszka (3): kvm: x86: Use symbols for all xsave field kvm: x86: Avoid runtime allocation of xsave buffer kvm: x86: Drop redundant apic base and tpr update from kvm_get_sregs Vasilis Liaskovitis (1): Set numa topology for max_cpus hw/pc.c |8 target-i386/cpu.h |3 ++- target-i386/cpuid.c | 17 + target-i386/kvm.c | 34 +- vl.c|2 +- 5 files changed, 37 insertions(+), 27 deletions(-)
[Qemu-devel] [PATCH 1/5] kvm: x86: Use symbols for all xsave field
From: Jan Kiszka jan.kis...@siemens.com
Field 0 (FCW+FSW) and 1 (FTW+FOP) were hard-coded so far.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
---
target-i386/kvm.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 5bfc21f..d2f70f9 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -759,6 +759,8 @@ static int kvm_put_fpu(CPUState *env)
return kvm_vcpu_ioctl(env, KVM_SET_FPU, fpu);
}
+#define XSAVE_FCW_FSW 0
+#define XSAVE_FTW_FOP 1
#define XSAVE_CWD_RIP 2
#define XSAVE_CWD_RDP 4
#define XSAVE_MXCSR 6
@@ -786,8 +788,8 @@ static int kvm_put_xsave(CPUState *env)
for (i = 0; i 8; ++i) {
twd |= (!env-fptags[i]) i;
}
-xsave-region[0] = (uint32_t)(swd 16) + cwd;
-xsave-region[1] = (uint32_t)(env-fpop 16) + twd;
+xsave-region[XSAVE_FCW_FSW] = (uint32_t)(swd 16) + cwd;
+xsave-region[XSAVE_FTW_FOP] = (uint32_t)(env-fpop 16) + twd;
memcpy(xsave-region[XSAVE_CWD_RIP], env-fpip, sizeof(env-fpip));
memcpy(xsave-region[XSAVE_CWD_RDP], env-fpdp, sizeof(env-fpdp));
memcpy(xsave-region[XSAVE_ST_SPACE], env-fpregs,
@@ -991,10 +993,10 @@ static int kvm_get_xsave(CPUState *env)
return ret;
}
-cwd = (uint16_t)xsave-region[0];
-swd = (uint16_t)(xsave-region[0] 16);
-twd = (uint16_t)xsave-region[1];
-env-fpop = (uint16_t)(xsave-region[1] 16);
+cwd = (uint16_t)xsave-region[XSAVE_FCW_FSW];
+swd = (uint16_t)(xsave-region[XSAVE_FCW_FSW] 16);
+twd = (uint16_t)xsave-region[XSAVE_FTW_FOP];
+env-fpop = (uint16_t)(xsave-region[XSAVE_FTW_FOP] 16);
env-fpstt = (swd 11) 7;
env-fpus = swd;
env-fpuc = cwd;
--
1.7.6.4
Re: [Qemu-devel] [PATCH] hw/9pfs: Add new security model mapped-file.
On 19 December 2011 13:50, Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
This enable us to do passthrough equivalent security model on NFS directory.
NFS server mostly do root squashing and don't support xattr. Hence we cannot
use 'passthrough' or 'mapped' security model
Also added mapped-xattr security to indicate earlier mapped security model
Older name is still supported.
Out of interest, did you do any performance comparison with mapped-xattr?
@@ -404,6 +578,10 @@ static int local_fstat(FsContext *fs_ctx, int fid_type,
tmp_dev, sizeof(dev_t)) 0) {
stbuf-st_rdev = tmp_dev;
}
+#if 0
+ } else if (fs_ctx-export_flags V9FS_SM_MAPPED_FILE) {
+ /* FIXME!! how to implement that for MAPPED_FILE */
+#endif
Lacking an implementation of fstat seems like a pretty major omission
that isn't mentioned in the commit message.
Alex
[Qemu-devel] [PATCH] PPC: Add description for the Freescale e500mc core.
From: Varun Sethi varun.se...@freescale.com
This core is found on chips such as p4080, p3041, p2040, and p5020.
More needs to be done to make this viable for TCG (such as missing SPRs
and instructions), but this suffices to get KVM running with appropriate
kernel support.
Signed-off-by: Varun Sethi varun.se...@freescale.com
[scottw...@freescale.com: tweak some flags]
Signed-off-by: Scott Wood scottw...@freescale.com
---
Kernel support for e500mc KVM was recently posted as an RFC patchset.
For now, use the mpc8544ds platform, pass -cpu e500mc, and edit the
device tree to have a top-level compatible that Linux will accept (such
as fsl,P4080DS).
target-ppc/translate_init.c | 56 ++
1 files changed, 50 insertions(+), 6 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 8a7233f..e312121 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -2,6 +2,7 @@
* PowerPC CPU initialization for qemu.
*
* Copyright (c) 2003-2007 Jocelyn Mayer
+ * Copyright 2011 Freescale Semiconductor, Inc.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
@@ -4399,6 +4400,33 @@ static void init_proc_e300 (CPUPPCState *env)
#define check_pow_e500v2 check_pow_hid0
#define init_proc_e500v2 init_proc_e500v2
+/* e500mc core */
+#define POWERPC_INSNS_e500mc (PPC_INSNS_BASE | PPC_ISEL | \
+PPC_WRTEE | PPC_RFDI | PPC_RFMCI | \
+PPC_CACHE | PPC_CACHE_LOCK | PPC_CACHE_ICBI | \
+PPC_CACHE_DCBZ | PPC_CACHE_DCBA | \
+PPC_FLOAT | PPC_FLOAT_FRES |\
+PPC_FLOAT_FRSQRTE | PPC_FLOAT_FSEL |\
+PPC_FLOAT_STFIWX | PPC_WAIT | \
+PPC_MEM_TLBSYNC | PPC_TLBIVAX)
+#define POWERPC_INSNS2_e500mc (PPC2_BOOKE206)
+#define POWERPC_MSRM_e500mc(0x1402FB36ULL)
+#define POWERPC_MMU_e500mc (POWERPC_MMU_BOOKE206)
+#define POWERPC_EXCP_e500mc(POWERPC_EXCP_BOOKE)
+#define POWERPC_INPUT_e500mc (PPC_FLAGS_INPUT_BookE)
+/* Fixme: figure out the correct flag for e500mc */
+#define POWERPC_BFDM_e500mc(bfd_mach_ppc_e500)
+#define POWERPC_FLAG_e500mc(POWERPC_FLAG_CE | POWERPC_FLAG_DE | \
+POWERPC_FLAG_PMM | POWERPC_FLAG_BUS_CLK)
+#define check_pow_e500mc check_pow_none
+#define init_proc_e500mc init_proc_e500mc
+
+enum fsl_e500_version {
+fsl_e500v1,
+fsl_e500v2,
+fsl_e500mc,
+};
+
static void init_proc_e500 (CPUPPCState *env, int version)
{
uint32_t tlbncfg[2];
@@ -4430,15 +4458,26 @@ static void init_proc_e500 (CPUPPCState *env, int
version)
env-nb_ways = 2;
env-id_tlbs = 0;
switch (version) {
-case 1:
+case fsl_e500v1:
/* e500v1 */
tlbncfg[0] = gen_tlbncfg(2, 1, 1, 0, 256);
tlbncfg[1] = gen_tlbncfg(16, 1, 9, TLBnCFG_AVAIL | TLBnCFG_IPROT, 16);
+env-dcache_line_size = 32;
+env-icache_line_size = 32;
break;
-case 2:
+case fsl_e500v2:
/* e500v2 */
tlbncfg[0] = gen_tlbncfg(4, 1, 1, 0, 512);
tlbncfg[1] = gen_tlbncfg(16, 1, 12, TLBnCFG_AVAIL | TLBnCFG_IPROT, 16);
+env-dcache_line_size = 32;
+env-icache_line_size = 32;
+break;
+case fsl_e500mc:
+/* e500mc */
+tlbncfg[0] = gen_tlbncfg(4, 1, 1, 0, 512);
+tlbncfg[1] = gen_tlbncfg(64, 1, 12, TLBnCFG_AVAIL | TLBnCFG_IPROT, 64);
+env-dcache_line_size = 64;
+env-icache_line_size = 64;
break;
default:
cpu_abort(env, Unknown CPU: TARGET_FMT_lx \n, env-spr[SPR_PVR]);
@@ -4522,20 +4561,23 @@ static void init_proc_e500 (CPUPPCState *env, int
version)
#endif
init_excp_e200(env);
-env-dcache_line_size = 32;
-env-icache_line_size = 32;
/* Allocate hardware IRQ controller */
ppce500_irq_init(env);
}
static void init_proc_e500v1(CPUPPCState *env)
{
-init_proc_e500(env, 1);
+init_proc_e500(env, fsl_e500v1);
}
static void init_proc_e500v2(CPUPPCState *env)
{
-init_proc_e500(env, 2);
+init_proc_e500(env, fsl_e500v2);
+}
+
+static void init_proc_e500mc(CPUPPCState *env)
+{
+init_proc_e500(env, fsl_e500mc);
}
/* Non-embedded PowerPC */
@@ -7070,6 +7112,7 @@ enum {
CPU_POWERPC_e500v2_v21 = 0x80210021,
CPU_POWERPC_e500v2_v22 = 0x80210022,
CPU_POWERPC_e500v2_v30 = 0x80210030,
+CPU_POWERPC_e500mc = 0x80230020,
/* MPC85xx microcontrollers */
#define CPU_POWERPC_MPC8533 CPU_POWERPC_MPC8533_v11
#define
[Qemu-devel] [PATCH] Fix KVM dirty logging with 32-bit qemu 32-bit physical addresses
We were using the wrong types in kvm_get_dirty_pages_log_range().
This would break dirty logging if the region to log resides at a
physical address above 32-bit, which can happen with 64-bit guest
but also with 32-bit guests that support 32-bit physical addresses
such as ppc BookE.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
kvm-all.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 4c466d6..91b0694 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -328,13 +328,14 @@ static int kvm_set_migration_log(int enable)
}
/* get kvm's dirty pages bitmap and update qemu's */
-static int kvm_get_dirty_pages_log_range(unsigned long start_addr,
+static int kvm_get_dirty_pages_log_range(target_phys_addr_t start_addr,
unsigned long *bitmap,
- unsigned long offset,
+ target_phys_addr_t offset,
unsigned long mem_size)
{
unsigned int i, j;
-unsigned long page_number, addr, addr1, c;
+unsigned long page_number, c;
+target_phys_addr_t addr, addr1;
ram_addr_t ram_addr;
unsigned int len = ((mem_size / TARGET_PAGE_SIZE) + HOST_LONG_BITS - 1) /
HOST_LONG_BITS;
Re: [Qemu-devel] [PATCH v2] w32: Build windows and console executables
On Thu, Dec 22, 2011 at 18:20, Stefan Weil s...@weilnetz.de wrote: System emulation executables with SDL are typically windows executables. Sometimes console executables are more useful, so create both variants if linker option -mwindows was detected. v2: This version uses QEMU_PROGW / QEMU_PROG instead of QEMU_PROG / QEMU_PROGC. Signed-off-by: Stefan Weil s...@weilnetz.de --- Makefile.target | 16 +++- 1 files changed, 15 insertions(+), 1 deletions(-) diff --git a/Makefile.target b/Makefile.target index 3261383..0182e41 100644 --- a/Makefile.target +++ b/Makefile.target @@ -27,10 +27,17 @@ ifdef CONFIG_USER_ONLY QEMU_PROG=qemu-$(TARGET_ARCH2) else # system emulator name +ifneq (,$(findstring -mwindows,$(LIBS))) +# Terminate program name with a 'w' because the linker builds a windows executable. +QEMU_PROGW=qemu-system-$(TARGET_ARCH2)w$(EXESUF) +endif # windows executable QEMU_PROG=qemu-system-$(TARGET_ARCH2)$(EXESUF) endif PROGS=$(QEMU_PROG) +ifdef QEMU_PROGW +PROGS+=$(QEMU_PROGW) +endif STPFILES= ifndef CONFIG_HAIKU @@ -403,9 +410,16 @@ endif # CONFIG_LINUX_USER obj-$(CONFIG_GDBSTUB_XML) += gdbstub-xml.o +ifdef QEMU_PROGW +# The linker builds a windows executable. Make also a console executable. +$(QEMU_PROGW): $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y) + $(call LINK,$^) +$(QEMU_PROG): $(QEMU_PROGW) + $(call quiet-command,$(OBJCOPY) --subsystem console $(QEMU_PROGW) $(QEMU_PROG), GEN $(TARGET_DIR)$(QEMU_PROG)) +else $(QEMU_PROG): $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y) $(call LINK,$^) - +endif gdbstub-xml.c: $(TARGET_XML_FILES) $(SRC_PATH)/scripts/feature_to_c.sh $(call quiet-command,rm -f $@ $(SHELL) $(SRC_PATH)/scripts/feature_to_c.sh $@ $(TARGET_XML_FILES), GEN $(TARGET_DIR)$@) -- 1.7.2.5 Failed to make: Makefile:416: *** multiple target patterns. Stop.
[Qemu-devel] [help] QEMUFile's format
Hi, Is anyone clear about the format of qemu file for savevm or loadvm? bruce
[Qemu-devel] [Bug 907994] [NEW] converting VDI to IMG
Public bug reported: I'm so close to moving away from VrtualBox to using Qemu. However I've run into some issues converting my existing virtual machine from VirtualBox to Qemu. I'm running Qemu on Fedora 16. I took my windows_xp.vdi and tried to convert it to qemu. The conversion goes well without any errors but then when I import the converted file to Qemu, it won't start. Here is the info on the file that I'm trying to convert: INFO = $ qemu-img info windows_xp.vdi image: windows_xp.vdi file format: vdi virtual size: 21G (22020096000 bytes) disk size: 9.4G cluster_size: 1048576 CONVERT COMMAND == qemu-img convert windows_xp.vdi windows_xp.img I created a new virtual machine and used the converted machine created (from the above step). When I try to start the newly created virtual machine, it keeps failing. There is a blue screen of death that goes away too soon. and I'm stuck with the windows start menu safe mode, start normally etc.. but no matter what I do I can't seem to start the vm. Any help much appreciated. Thanks ** 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/907994 Title: converting VDI to IMG Status in QEMU: New Bug description: I'm so close to moving away from VrtualBox to using Qemu. However I've run into some issues converting my existing virtual machine from VirtualBox to Qemu. I'm running Qemu on Fedora 16. I took my windows_xp.vdi and tried to convert it to qemu. The conversion goes well without any errors but then when I import the converted file to Qemu, it won't start. Here is the info on the file that I'm trying to convert: INFO = $ qemu-img info windows_xp.vdi image: windows_xp.vdi file format: vdi virtual size: 21G (22020096000 bytes) disk size: 9.4G cluster_size: 1048576 CONVERT COMMAND == qemu-img convert windows_xp.vdi windows_xp.img I created a new virtual machine and used the converted machine created (from the above step). When I try to start the newly created virtual machine, it keeps failing. There is a blue screen of death that goes away too soon. and I'm stuck with the windows start menu safe mode, start normally etc.. but no matter what I do I can't seem to start the vm. Any help much appreciated. Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/907994/+subscriptions
Re: [Qemu-devel] [help] QEMUFile's format
Do you mean the file format? qcow2, qed, raw? Or the content layout in the file image? On 2011-12-23 13:17, ¤終於aware wrote: Hi, Is anyone clear about the format of qemu file for savevm or loadvm? bruce -- Shu Mingshum...@linux.vnet.ibm.com IBM China Systems and Technology Laboratory
Re: [Qemu-devel] [PATCH] hw/9pfs: Add new security model mapped-file.
On Thu, 22 Dec 2011 21:45:51 +, Alex Bradbury a...@asbradbury.org wrote:
On 19 December 2011 13:50, Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
This enable us to do passthrough equivalent security model on NFS directory.
NFS server mostly do root squashing and don't support xattr. Hence we cannot
use 'passthrough' or 'mapped' security model
Also added mapped-xattr security to indicate earlier mapped security
model
Older name is still supported.
Out of interest, did you do any performance comparison with mapped-xattr?
No, I was mostly looking at making virtFS usable on an NFS setup
@@ -404,6 +578,10 @@ static int local_fstat(FsContext *fs_ctx, int fid_type,
tmp_dev, sizeof(dev_t)) 0) {
stbuf-st_rdev = tmp_dev;
}
+#if 0
+ } else if (fs_ctx-export_flags V9FS_SM_MAPPED_FILE) {
+ /* FIXME!! how to implement that for MAPPED_FILE */
+#endif
Lacking an implementation of fstat seems like a pretty major omission
that isn't mentioned in the commit message.
If you look at where local_fstat get used currently, We do it only for
lock call, that too to check whether the file is present. We are not
using the stat value returned. So the patchset should be usable as it
is. What i am contemplating is should i add additional code in server
that fallback to path based stat if fs driver callback returned
EOPNOTSUPP error. May be i should do that in the next version.
-aneesh
Re: [Qemu-devel] [PATCH] spapr: Add support for -vga option
On Wed, 2011-12-14 at 20:22 +1100, Benjamin Herrenschmidt wrote:
The -vga option is a handy high level option for instanciating things
automatically. This adds support for it to the spapr (aka pseries)
machine.
Also instanciate the USB keyboard and mouse when that option is used
(you can still use -device to create individual devices without all
the defaults)
The default remains no VGA and no USB, and of course you can use -device
to manually instanciate individual devices.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
BTW. Don't apply this just yet. New version coming soon.
Cheers,
Ben.
Makefile.target |2 +-
hw/spapr.c | 47 ++-
2 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/Makefile.target b/Makefile.target
index 03e3c55..c78fc25 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -243,7 +243,7 @@ obj-i386-$(CONFIG_SPICE) += qxl.o qxl-logger.o
qxl-render.o
# shared objects
obj-ppc-y = ppc.o ppc_booke.o
-obj-ppc-y += vga.o
+obj-ppc-y += vga.o cirrus_vga.o
# PREP target
obj-ppc-y += mc146818rtc.o
obj-ppc-y += ppc_prep.o
diff --git a/hw/spapr.c b/hw/spapr.c
index c5353fb..3b9e576 100644
--- a/hw/spapr.c
+++ b/hw/spapr.c
@@ -49,6 +49,7 @@
#include pci.h
#include usb.h
#include usb-ohci.h
+#include pc.h
#include exec-memory.h
@@ -76,6 +77,7 @@
#define PHANDLE_XICP0x
sPAPREnvironment *spapr;
+static int spapr_has_graphics;
qemu_irq spapr_allocate_irq(uint32_t hint, uint32_t *irq_num)
{
@@ -318,6 +320,9 @@ static void *spapr_create_fdt_skel(const char *cpu_model,
_FDT((fdt_property(fdt, linux,initrd-end,
end_prop, sizeof(end_prop;
_FDT((fdt_property_string(fdt, qemu,boot-device, boot_device)));
+_FDT((fdt_property_cell(fdt, qemu,graphic-width, graphic_width)));
+_FDT((fdt_property_cell(fdt, qemu,graphic-height, graphic_height)));
+_FDT((fdt_property_cell(fdt, qemu,graphic-depth, graphic_depth)));
_FDT((fdt_end_node(fdt)));
@@ -563,7 +568,9 @@ static void spapr_finalize_fdt(sPAPREnvironment *spapr,
}
}
-spapr_populate_chosen_stdout(fdt, spapr-vio_bus);
+if (!spapr_has_graphics) {
+ spapr_populate_chosen_stdout(fdt, spapr-vio_bus);
+}
_FDT((fdt_pack(fdt)));
@@ -603,6 +610,26 @@ static void spapr_reset(void *opaque)
}
+static int spapr_vga_init(PCIBus *pci_bus)
+{
+/* Default is nothing */
+if (cirrus_vga_enabled) {
+pci_cirrus_vga_init(pci_bus);
+} else if (vmsvga_enabled) {
+ fprintf(stderr, Warning: vmware_vga not available,
+ using standard VGA instead\n);
+ pci_vga_init(pci_bus);
+#ifdef CONFIG_SPICE
+} else if (qxl_enabled) {
+pci_create_simple(pci_bus, -1, qxl-vga);
+#endif
+} else if (std_vga_enabled) {
+pci_vga_init(pci_bus);
+} else
+ return 0;
+return 1;
+}
+
/* pSeries LPAR / sPAPR hardware init */
static void ppc_spapr_init(ram_addr_t ram_size,
const char *boot_device,
@@ -746,9 +773,27 @@ static void ppc_spapr_init(ram_addr_t ram_size,
spapr_vscsi_create(spapr-vio_bus, 0x2000 + i);
}
+/* Graphics */
+if (spapr_vga_init(QLIST_FIRST(spapr-phbs)-host_state.bus)) {
+ spapr_has_graphics = 1;
+ usb_enabled = 1;
+}
+
+/* Default depth is 15 which is bad, SLOF only supports 8 so it should
+ * be the default (while we should still allow to specify 16 or 32)
+ * so I'm cheating and converting 15 to 8 here. Ideally we should have
+ * a way to set the defaults per machine.
+ */
+if (graphic_depth == 15)
+graphic_depth = 8;
+
/* USB */
if (usb_enabled) {
usb_ohci_init_pci(QLIST_FIRST(spapr-phbs)-host_state.bus, -1);
+ if (spapr_has_graphics) {
+ usbdevice_create(keyboard);
+ usbdevice_create(mouse);
+ }
}
if (kernel_filename) {
Re: [Qemu-devel] memory: Why subpage is introduced?
anyway, thanks. On Thu, Dec 22, 2011 at 8:38 PM, Avi Kivity a...@redhat.com wrote: On 12/22/2011 01:24 PM, Zhi Yong Wu wrote: 2.) How to render MemoryRegion into one disjoint flatrange list? That rendering function is a bit difficult to understand. Can anyone simply explain it? What exactly don't you understand? 1.) e.g. some fields such as offset_in_region, terminates, offset in MemoryRegion struct. What are separately their meanings? Well, read the code, it's not that complicated. Afterwards you can add documentation based on your findings. 2.) render_memory_region(), how does it render one MemoryRegion into the global view flatview? Can you simply explain this function's algorithm logic? Again, what can I say that the code doesn't? It recursively descends the hierarchy and finds out which region goes where. Also read docs/memory.txt 3.) What are separately the meanings of these flags? such as IO_MEM_RAM, IO_MEM_ROM, IO_MEM_UNASSIGNED, IO_MEM_*, IO_MEM_ROMD, and IO_MEM_SUBPAGE. RAM = RAM ROM = ROM UNASSIGNED = nothing handles this range ROMD = ROM when read, device (i.e. callbacks) when written SUBPAGE = dispatch using the lower address bits to obtain final I/O handler. thanks. By the way, if you are available, can you simply explain what is the relationship among them and how they work together? such as MemoryRegion, RamBlock, PhysPageDesc, and MemorySlot. Sorry, it's a long and complicated story that is changing now. You'll have to educate yourself mostly. -- error compiling committee.c: too many arguments to function -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [help] QEMUFile's format
On Fri, Dec 23, 2011 at 01:32:50PM +0800, Shu Ming wrote: Do you mean the file format? qcow2, qed, raw? Or the content layout in the file image? On 2011-12-23 13:17, ¤終於aware wrote: Hi, Is anyone clear about the format of qemu file for savevm or loadvm? ^^ savevm requires image's format to be qcow2. You can check http://en.wikipedia.org/wiki/Qcow for more information. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [help] QEMUFile's format
savevm requires image's format to be qcow2. You can check http://en.wikipedia.org/wiki/Qcow for more information. Plus this, http://www.linux-kvm.org/wiki/images/6/63/2011-forum-qcow2.pdf HTH, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] [help] QEMUFile's format
You could have a look at docs/specs directory. 2011/12/23 陳韋任 che...@iis.sinica.edu.tw On Fri, Dec 23, 2011 at 01:32:50PM +0800, Shu Ming wrote: Do you mean the file format? qcow2, qed, raw? Or the content layout in the file image? On 2011-12-23 13:17, ¤終於aware wrote: Hi, Is anyone clear about the format of qemu file for savevm or loadvm? ^^ savevm requires image's format to be qcow2. You can check http://en.wikipedia.org/wiki/Qcow for more information. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
Re: [Qemu-devel] OEM Windows in Qemu
My patch does not produce any SLIC at all. The instructions mentions using SLIC from your machine - my patch is just a way to _embed_ a given data into VM, not a way to produce anything. You get in your VM what you have outside, either in a file or in your own BIOS, depending on where you took that data from. Right, I meant to say simply that it did copy the SLIC in a recognizable form and embed it into the BIOS. Yes, the patch only changes RSDT to match SLIC - this is what win7 verifies, all other tables does not matter for win7. And yes, it might be different for winXP - you may try setting all tables in VM to be of DELL OEM and see what happens. I had high hopes for this, but no joy. All the DMI tables now read Dell Inc but XP refuses to activate. I think the key is those specific memory addresses I mentioned earlier. I tried raw write of Dell Inc into the specified address space, but there are 2 problems with this. First is that the address space already contains data so I overwrote something. Second even then Windows did not activate, I think the activation check only occurs at certain times, probably on boot, so I made my changes after it checked and it didn't check again and so didn't see the changes I made. I need to modify the BIOS to contain the string so it is visible on boot without me having to manually edit it. Is there a way to hardcode the string into a specific memory address when I compile the BIOS? Brian
Re: [Qemu-devel] OEM Windows in Qemu
Why not just buy a non-OEM version ? They are surely not tied to a specific piece of hardware and its licence should allow to run on arbitrary PC HW you happen to want to install/run it on once activated On Fri, Dec 23, 2011 at 5:11 PM, in...@expertcomputerrepair.com wrote: My patch does not produce any SLIC at all. The instructions mentions using SLIC from your machine - my patch is just a way to _embed_ a given data into VM, not a way to produce anything. You get in your VM what you have outside, either in a file or in your own BIOS, depending on where you took that data from. Right, I meant to say simply that it did copy the SLIC in a recognizable form and embed it into the BIOS. Yes, the patch only changes RSDT to match SLIC - this is what win7 verifies, all other tables does not matter for win7. And yes, it might be different for winXP - you may try setting all tables in VM to be of DELL OEM and see what happens. I had high hopes for this, but no joy. All the DMI tables now read Dell Inc but XP refuses to activate. I think the key is those specific memory addresses I mentioned earlier. I tried raw write of Dell Inc into the specified address space, but there are 2 problems with this. First is that the address space already contains data so I overwrote something. Second even then Windows did not activate, I think the activation check only occurs at certain times, probably on boot, so I made my changes after it checked and it didn't check again and so didn't see the changes I made. I need to modify the BIOS to contain the string so it is visible on boot without me having to manually edit it. Is there a way to hardcode the string into a specific memory address when I compile the BIOS? Brian
