Re: [Qemu-devel] Initializing PC from memory on reset?
On 23 November 2011 23:59, Andreas Färber wrote: > Unlike PowerPC, an architecture that I'm trying to emulate does not > store branch instructions in the reset vector but a memory address. I'm > therefore trying to read physical address 0x0 and store its value > into my env->pc. Have you looked at how M profile ARM does it? That has a similar "read memory for initial PC value". (There are some interesting wrinkles, not all of which we get quite right, regarding how this should interact with initial ELF image load and the user fiddling with PC and RAM in an attached debugger.) -- PMM
Re: [Qemu-devel] [libvirt] virDomainBlockJobAbort and block_job_cancel
On Wed, Nov 23, 2011 at 09:04:50AM -0700, Eric Blake wrote: > On 11/23/2011 07:48 AM, Stefan Hajnoczi wrote: > > This means that virDomainBlockJobAbort() returns to the client without > > a guarantee that the job has completed. If the client enumerates jobs > > it may still see a job that has not finished cancelling. The client > > must register a handler for the BLOCK_JOB_CANCELLED event if it wants > > to know when the job really goes away. The BLOCK_JOB_CANCELLED event > > has the same fields as the BLOCK_JOB_COMPLETED event, except it lacks > > the optional "error" message field. > > > > The impact on clients is that they need to add a BLOCK_JOB_CANCELLED > > handler if they really want to wait. Most clients today (not many > > exist) will be fine without waiting for cancellation. > > > > Any objections or thoughts on this? > > virDomainBlockJobAbort() thankfully has an 'unsigned int flags' > argument. For backwards-compatibility, I suggest we use it: > > calling virDomainBlockJobAbort(,0) maintains old blocking behavior, and > we document that blocking until things abort may render the rest of > interactions with the domain unresponsive. > > The new virDomainBlockJobAbort(,VIR_DOMAIN_BLOCK_JOB_ABORT_ASYNC) would > then implement your new proposed semantics of returning immediately once > the cancellation has been requested, even if it hasn't been acted on yet. > > Maybe you could convince me to swap the flags: have 0 change semantics > to non-blocking, and a new flag to request blocking, where callers that > care have to try the flag, and if the flag is unsupported then they know > they are talking to older libvirtd where the behavior is blocking by > default, but that's a bit riskier. Agreed, I would rather not change the current call semantic, but an ASYNC flag would be a really good addition. We can document the risk of not using it in the function description and suggest new applications use ASYNC flag. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
Re: [Qemu-devel] [PATCH V3 2/2] Add -f option to qemu-nbd
2011/11/23 Stefan Hajnoczi > On Wed, Nov 23, 2011 at 10:14 AM, Chunyan Liu wrote: > > V3: > > Remove file lock in main(). > > Try to find new free nbd device and connect to it if connecting to the > first > > first found free nbd device failed. > > > > Signed-off-by: Chunyan Liu > > --- > > qemu-nbd.c | 80 > +++- > > 1 files changed, 79 insertions(+), 1 deletions(-) > > I not seeing the part where you adjusted the ioctl order. > > The /proc/partitions scanning is unnecessary since we can just loop > over /dev/ndb%d and try to initialize. If a device is in use then > init will fail and we need to try the next one. If a device is free > we can continue with normal operation. I guess I'm saying that once > you fix the ioctl order then there's no need for another mechanism to > test whether or not a device is in use. > The way of scanning /proc/partitions to find an unused nbd device first can borrow the code for "qemu-nbd -c" to do the left things. . The way of loop over /dev/nbd%d and try to initialize, from the first thought, needs do all things in the loop, including handling -v, nbd_init, nbd_client, etc. That part of code is quite similar to "qemu-nbd -c". I don't know if that is better? > Also please use QEMU coding style, you can run > qemu/scripts/checkpatch.pl on your patches. > > Stefan > >
[Qemu-devel] Initializing PC from memory on reset?
Hi, Unlike PowerPC, an architecture that I'm trying to emulate does not store branch instructions in the reset vector but a memory address. I'm therefore trying to read physical address 0x0 and store its value into my env->pc. I've verified by running with -S that xp /xh 0x0 shows the expected value. When doing lduw_phys(0x0) or cpu_read_physical_memory() in the CPU reset function though, I just seem to read from uninitialized memory (0xbaba). I've taken care to reorder CPU initialization to after the BIOS file is loaded in the machine initialization function. What am I doing wrong? Thanks, Andreas
Re: [Qemu-devel] [PATCH v2] linux-user: fix wait* syscall status returns
On 23 November 2011 23:44, Alexander Graf wrote: > When calling wait4 or waitpid with a status pointer and WNOHANG, the > syscall can potentially not modify the status pointer input. Now if we > have guest code like: > > int status = 0; > waitpid(pid, &status, WNOHANG); > if (status) > > > then we have to make sure that in case status did not change we actually > return the guest's initialized status variable instead of our own > uninitialized. > We fail to do so today, as we proxy everything through an uninitialized status > variable which for me ended up always containing the last error code. > > This patch fixes some test cases when building yast2-core in OBS for ARM. > > Signed-off-by: Alexander Graf I'd have put both sets of checks on ret next to each other personally, but that's hardly worth doing a v3 for. Reviewed-by: Peter Maydell -- PMM
Re: [Qemu-devel] [PATCH] linux-user: fix wait* syscall status returns
On 23 November 2011 23:31, Alexander Graf wrote:
> If it was the same value before, it will still be the same value in guest
> memory.
>
> get_guest_s32(status, status_ptr);
> old_status = status;
> wait(...)
> if (old_status != status) {
> status = convert_status(status);
> put_guest_s32(status, status_ptr);
> }
Picking some concrete numbers as an illustration; obviously
they're not really sensible status values:
Suppose guest memory contains the value 1, and that
convert_status(1) == 2. Now if you come out of wait()
and status == 1 (ie old_status == status), then either:
(a) wait() didn't write to status => do nothing
(b) wait() did write to status => since convert_status(1) == 2
we need to write 2 to guest memory
For this approach to work you have to have a conversion
function from guest to host status, I think.
-- PMM
[Qemu-devel] [PATCH v2] linux-user: fix wait* syscall status returns
When calling wait4 or waitpid with a status pointer and WNOHANG, the
syscall can potentially not modify the status pointer input. Now if we
have guest code like:
int status = 0;
waitpid(pid, &status, WNOHANG);
if (status)
then we have to make sure that in case status did not change we actually
return the guest's initialized status variable instead of our own uninitialized.
We fail to do so today, as we proxy everything through an uninitialized status
variable which for me ended up always containing the last error code.
This patch fixes some test cases when building yast2-core in OBS for ARM.
Signed-off-by: Alexander Graf
---
v1 -> v2:
- take Peter's comment into account and just not write status back when
wait*'s return value is 0
---
linux-user/syscall.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 3e6f3bd..5810e2a 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -4835,7 +4835,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
{
int status;
ret = get_errno(waitpid(arg1, &status, arg3));
-if (!is_error(ret) && arg2
+if (!is_error(ret) && arg2 && ret
&& put_user_s32(host_to_target_waitstatus(status), arg2))
goto efault;
}
@@ -6391,7 +6391,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
rusage_ptr = NULL;
ret = get_errno(wait4(arg1, &status, arg3, rusage_ptr));
if (!is_error(ret)) {
-if (status_ptr) {
+if (status_ptr && ret) {
status = host_to_target_waitstatus(status);
if (put_user_s32(status, status_ptr))
goto efault;
--
1.6.0.2
Re: [Qemu-devel] cannot build qemu with "--static" configure option
>>> Is there any solution to this? >> Traditional: it may be fixed in the mainline already, F15 has version >> 2.28.8, whereas mainline tip is 2.31.2. >> However nothing in the git log suggests that. > > FWIW Ubuntu Oneiric has glib2 2.30.0 and doesn't seem to have this problem. Just compiled, built and installed the latest glib-2.0 from rawhide (2.31.2-1) - *no* use, the same error is popping up. Dead end? The bug report Max linked to previously suggests that bug is "CLOSED FIXED". How's that fixed then?
Re: [Qemu-devel] [PATCH 1/2] Reopen files after migration
On 11/23/2011 09:34 AM, Juan Quintela wrote:
We need to invalidate the Read Cache on the destination, otherwise we
have corruption. Easy way to reproduce it is:
- create an qcow2 images
- start qemu on destination of migration (qemu -incoming tcp:...)
- start qemu on source of migration and do one install.
- migrate at the end of install (when lot of disk IO has happened).
Have you actually tried this on the master? It should work because of:
commit 06d9260ffa9dfa0e96e015501e43480ab66f96f6
Author: Anthony Liguori
Date: Mon Nov 14 15:09:46 2011 -0600
qcow2: implement bdrv_invalidate_cache (v2)
Destination of migration has a local copy of the L1/L2 tables that existed
at the beginning, before the install started. We have disk corruption at
this point. The solution (for NFS) is to just re-open the file. Operations
have to happen in this order:
- source of migration: flush()
- destination: close(file);
- destination: open(file)
You cannot reliably coordinate this with this series. You never actually close
the file on the source so I can't see how it would even work with this series.
I thought we had a long discussion on this and all agreed that opening O_DIRECT
and fcntl()'ing it away was the best solution here?
Regards,
Anthony Liguori
it is not necesary that source of migration close the file.
Signed-off-by: Juan Quintela
---
blockdev.c | 43 ++-
blockdev.h |6 ++
migration.c |6 ++
3 files changed, 50 insertions(+), 5 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 0827bf7..a10de7a 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -182,6 +182,7 @@ static void drive_uninit(DriveInfo *dinfo)
qemu_opts_del(dinfo->opts);
bdrv_delete(dinfo->bdrv);
g_free(dinfo->id);
+g_free(dinfo->file);
QTAILQ_REMOVE(&drives, dinfo, next);
g_free(dinfo);
}
@@ -216,6 +217,37 @@ static int parse_block_error_action(const char *buf, int
is_read)
}
}
+static int drive_open(DriveInfo *dinfo)
+{
+int res = bdrv_open(dinfo->bdrv, dinfo->file,
+dinfo->bdrv_flags, dinfo->drv);
+
+if (res< 0) {
+fprintf(stderr, "qemu: could not open disk image %s: %s\n",
+dinfo->file, strerror(errno));
+}
+return res;
+}
+
+int drives_reinit(void)
+{
+DriveInfo *dinfo;
+
+QTAILQ_FOREACH(dinfo,&drives, next) {
+if (dinfo->opened&& !bdrv_is_read_only(dinfo->bdrv)) {
+int res;
+bdrv_close(dinfo->bdrv);
+res = drive_open(dinfo);
+if (res) {
+fprintf(stderr, "qemu: re-open of %s failed with error %d\n",
+dinfo->file, res);
+return res;
+}
+}
+}
+return 0;
+}
+
DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
{
const char *buf;
@@ -236,7 +268,6 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
const char *devaddr;
DriveInfo *dinfo;
int snapshot = 0;
-int ret;
translation = BIOS_ATA_TRANSLATION_AUTO;
media = MEDIA_DISK;
@@ -514,10 +545,12 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
bdrv_flags |= ro ? 0 : BDRV_O_RDWR;
-ret = bdrv_open(dinfo->bdrv, file, bdrv_flags, drv);
-if (ret< 0) {
-error_report("could not open disk image %s: %s",
- file, strerror(-ret));
+dinfo->file = g_strdup(file);
+dinfo->bdrv_flags = bdrv_flags;
+dinfo->drv = drv;
+dinfo->opened = 1;
+
+if (drive_open(dinfo)< 0) {
goto err;
}
diff --git a/blockdev.h b/blockdev.h
index 3587786..733eb72 100644
--- a/blockdev.h
+++ b/blockdev.h
@@ -38,6 +38,10 @@ struct DriveInfo {
char serial[BLOCK_SERIAL_STRLEN + 1];
QTAILQ_ENTRY(DriveInfo) next;
int refcount;
+int opened;
+int bdrv_flags;
+char *file;
+BlockDriver *drv;
};
DriveInfo *drive_get(BlockInterfaceType type, int bus, int unit);
@@ -53,6 +57,8 @@ QemuOpts *drive_add(BlockInterfaceType type, int index, const
char *file,
const char *optstr);
DriveInfo *drive_init(QemuOpts *arg, int default_to_scsi);
+extern int drives_reinit(void);
+
/* device-hotplug */
DriveInfo *add_init_drive(const char *opts);
diff --git a/migration.c b/migration.c
index 4b17566..764b233 100644
--- a/migration.c
+++ b/migration.c
@@ -17,6 +17,7 @@
#include "buffered_file.h"
#include "sysemu.h"
#include "block.h"
+#include "blockdev.h"
#include "qemu_socket.h"
#include "block-migration.h"
#include "qmp-commands.h"
@@ -89,6 +90,11 @@ void process_incoming_migration(QEMUFile *f)
qemu_announce_self();
DPRINTF("successfully loaded vm state\n");
+if (drives_reinit() != 0) {
+fprintf(stderr, "reopening of drives failed\n");
+exit(1);
+}
+
if (autostart) {
vm_start();
} else {
Re: [Qemu-devel] [PATCH] linux-user: fix wait* syscall status returns
On 24.11.2011, at 00:02, Peter Maydell wrote:
> On 23 November 2011 23:00, Alexander Graf wrote:
>>
>> On 23.11.2011, at 23:34, Peter Maydell wrote:
>>
>>> On 23 November 2011 22:03, Alexander Graf wrote:
Yes. Maybe we should add a check if input_state != output_state and
only then do the conversion?
>>>
>>> I'm not sure this works (unless you go to the effort of implementing
>>> target_to_host_waitstatus() which seems overkill to me) but I'm not
>>> entirely sure what you're proposing to compare to what.
>>
>> It's an integer. If the number is the same before and after the wait
>> syscall, we can safely assume that it's the same thing, so we don't
>> have to convert it, no?
>
> But you don't know whether it's the same before and after because
> wait() didn't write to it [=> don't write to guest memory] or if
> wait() did write to it but happened to write it as the same value
> it had before [=> do write to guest memory].
If it was the same value before, it will still be the same value in guest
memory.
get_guest_s32(status, status_ptr);
old_status = status;
wait(...)
if (old_status != status) {
status = convert_status(status);
put_guest_s32(status, status_ptr);
}
If the values are identical, it's safe to assume that we don't have to convert.
And the value will already be in guest memory :)
Alex
Re: [Qemu-devel] [PATCH 1.0 (resend)] eepro100: Fix alignment requirement for statistical counters
On 11/23/2011 04:26 PM, Michael S. Tsirkin wrote:
On Wed, Nov 23, 2011 at 10:20:30PM +0100, Stefan Weil wrote:
According to Intel's Open Source Software Developer Manual,
the dump counters address must be Dword aligned.
The new code enforces this alignment, so s->statsaddr may now
be used with stw_le_pci_dma() and stl_le_pci_dma().
Signed-off-by: Stefan Weil
Anthiny, coul you apply pls?
Yup.
Regards,
Anthony Liguori
---
hw/eepro100.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index 7d59e71..29ec5b4 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -976,7 +976,15 @@ static void eepro100_cu_command(EEPRO100State * s, uint8_t
val)
case CU_STATSADDR:
/* Load dump counters address. */
s->statsaddr = e100_read_reg4(s, SCBPointer);
-TRACE(OTHER, logout("val=0x%02x (status address)\n", val));
+TRACE(OTHER, logout("val=0x%02x (dump counters address)\n", val));
+if (s->statsaddr& 3) {
+/* Memory must be Dword aligned. */
+logout("unaligned dump counters address\n");
+/* Handling of misaligned addresses is undefined.
+ * Here we align the address by ignoring the lower bits. */
+/* TODO: Test unaligned dump counter address on real hardware. */
+s->statsaddr&= ~3;
+}
break;
case CU_SHOWSTATS:
/* Dump statistical counters. */
--
1.7.2.5
Re: [Qemu-devel] cannot build qemu with "--static" configure option
On 23 November 2011 23:15, Max Filippov wrote: >> >> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x24): >> >> undefined reference to `glib_mem__alloc_semaphore' >> >> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x7c): >> >> undefined reference to `glib_mem__alloc_semaphore' >> >> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0xd0): >> >> undefined reference to `glib_mem__alloc_semaphore' >> > ... >> > >> > It appears to be glib2 issue: >> > https://bugzilla.gnome.org/show_bug.cgi?id=654078 >> Spot on, unfortunately! This is what I now have after applying your patch >> (thank you!): > ... >> Is there any solution to this? > > Traditional: it may be fixed in the mainline already, F15 has version 2.28.8, > whereas mainline tip is 2.31.2. > However nothing in the git log suggests that. FWIW Ubuntu Oneiric has glib2 2.30.0 and doesn't seem to have this problem. -- PMM
Re: [Qemu-devel] cannot build qemu with "--static" configure option
> >> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x24): > >> undefined reference to `glib_mem__alloc_semaphore' > >> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x7c): > >> undefined reference to `glib_mem__alloc_semaphore' > >> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0xd0): > >> undefined reference to `glib_mem__alloc_semaphore' > > ... > > > > It appears to be glib2 issue: > > https://bugzilla.gnome.org/show_bug.cgi?id=654078 > Spot on, unfortunately! This is what I now have after applying your patch > (thank you!): ... > Is there any solution to this? Traditional: it may be fixed in the mainline already, F15 has version 2.28.8, whereas mainline tip is 2.31.2. However nothing in the git log suggests that. > > In the latest F15 it's not fixed. Mr-4, probably you will not escape > > re-compiling, if not even patching glib2. > I am not afraid of doing that as long as it works and helps me out. Should I > see/try whether it has been fixed in rawhide? Well, patching always helps AFAIK (: And rawhide -- give it a try if it's easy. Thanks. -- Max
Re: [Qemu-devel] [PATCH] linux-user: fix wait* syscall status returns
On 23 November 2011 23:00, Alexander Graf wrote: > > On 23.11.2011, at 23:34, Peter Maydell wrote: > >> On 23 November 2011 22:03, Alexander Graf wrote: >>> Yes. Maybe we should add a check if input_state != output_state and >>> only then do the conversion? >> >> I'm not sure this works (unless you go to the effort of implementing >> target_to_host_waitstatus() which seems overkill to me) but I'm not >> entirely sure what you're proposing to compare to what. > > It's an integer. If the number is the same before and after the wait > syscall, we can safely assume that it's the same thing, so we don't > have to convert it, no? But you don't know whether it's the same before and after because wait() didn't write to it [=> don't write to guest memory] or if wait() did write to it but happened to write it as the same value it had before [=> do write to guest memory]. -- PMM
Re: [Qemu-devel] cannot build qemu with "--static" configure option
>> $ make V=1 >> gcc -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 >> -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef >> -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing >> -fstack-protector-all -Wendif-labels -Wmissing-include-dirs -Wempty-body >> -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self >> -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition >> -Wtype-limits -I../linux-headers -I.. >> -I/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/target-i386 -DNEED_CPU_H -pthread >> -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include >> -I/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/linux-user/x86_64 >> -I/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/linux-user -O2 -g >> -Wl,--warn-common -m64 -static -g -Wl,-T../config-host.ld >> -Wl,-T,/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/x86_64.ld -o qemu-x86_64 >> ../libdis-user/i386-dis.o ../libuser/cache-utils.o ../libuser/cutils.o >> ../libuser/envlist.o ../libuser/host-utils.o ../libuser/path.o >> ../libuser/tcg-runtime.o ../lib user/trace.o ../libuser/trace/control.o ../libuser/trace/default.o cpu-exec.o cpu-uname.o cpuid.o disas.o elfload.o exec.o fpu/softfloat.o gdbstub.o helper.o ioport-user.o linuxload.o main.o mmap.o op_helper.o osdep.o oslib-posix.o qemu-thread-posix.o signal.o strace.o syscall.o tcg/optimize.o tcg/tcg.o thunk.o translate-all.o translate.o uaccess.o user-exec.o -lrt -pthread -pthread -lgthread-2.0 -lrt -lglib-2.0-lm >> >> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x24): >> undefined reference to `glib_mem__alloc_semaphore' >> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x7c): >> undefined reference to `glib_mem__alloc_semaphore' >> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0xd0): >> undefined reference to `glib_mem__alloc_semaphore' > ... > > It appears to be glib2 issue: > https://bugzilla.gnome.org/show_bug.cgi?id=654078 Spot on, unfortunately! This is what I now have after applying your patch (thank you!): gcc -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fstack-protector-all -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -I../linux-headers -I.. -I/home/gogo/t/qemu-1.0-rc3/target-arm -DNEED_CPU_H -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/home/gogo/t/qemu-1.0-rc3/linux-user/arm -I/home/gogo/t/qemu-1.0-rc3/linux-user -O2 -g -Wl,--warn-common -m64 -static -g -Wl,-T../config-host.ld -Wl,-T,/home/gogo/t/qemu-1.0-rc3/x86_64.ld -o qemu-arm ../libdis-user/arm-dis.o ../libdis-user/i386-dis.o ../libuser/cache-utils.o ../libuser/cutils.o ../libuser/envlist.o ../libuser/host-utils.o ../libuser/path.o ../libuser/tcg-runtime.o ../libuser/trace.o ../libuser/trace/control.o . ./libuser/trace/default.o arm-semi.o cpu-exec.o cpu-uname.o disas.o elfload.o exec.o flatload.o fpu/softfloat.o gdbstub-xml.o gdbstub.o helper.o iwmmxt_helper.o linuxload.o main.o mmap.o neon_helper.o nwfpe/double_cpdo.o nwfpe/extended_cpdo.o nwfpe/fpa11.o nwfpe/fpa11_cpdo.o nwfpe/fpa11_cpdt.o nwfpe/fpa11_cprt.o nwfpe/fpopcode.o nwfpe/single_cpdo.o op_helper.o osdep.o oslib-posix.o qemu-thread-posix.o signal.o strace.o syscall.o tcg/optimize.o tcg/tcg.o thunk.o translate-all.o translate.o uaccess.o user-exec.o -lrt -pthread -pthread -lgthread-2.0 -lrt -lglib-2.0-lm /usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../../../lib64/libglib-2.0.a(gutils.o): In function `g_get_any_init_do': (.text+0x11bc): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../../../lib64/libglib-2.0.a(gutils.o): In function `g_get_any_init_do': (.text+0x11b0): warning: Using 'setpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../../../lib64/libglib-2.0.a(gutils.o): In function `g_get_any_init_do': (.text+0x11c6): warning: Using 'endpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../../../lib64/libglib-2.0.a(gutils.o): In function `g_get_any_init_do': (.text+0xefa): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/gcc/x86_64-redhat-linux/4.4.5/../../../../lib64/libglib-2.0.a(gutils.o): In function `g_get_any_init_do': (.text+0xf36): warning: Using 'getpwuid_r
Re: [Qemu-devel] [PATCH] linux-user: fix wait* syscall status returns
On 23.11.2011, at 23:34, Peter Maydell wrote: > On 23 November 2011 22:03, Alexander Graf wrote: >> On 23.11.2011, at 22:55, Peter Maydell wrote: >>> If the problem is that waitpid() can return success without writing to >>> status, then this code is still not right because we will get the >>> initial target waitstatus into status, and then pass it through >>> host_to_target_waitstatus(), possibly modifying it, before writing >>> it back to guest memory. >> >> Yes. Maybe we should add a check if input_state != output_state and >> only then do the conversion? > > I'm not sure this works (unless you go to the effort of implementing > target_to_host_waitstatus() which seems overkill to me) but I'm not > entirely sure what you're proposing to compare to what. It's an integer. If the number is the same before and after the wait syscall, we can safely assume that it's the same thing, so we don't have to convert it, no? > >>> I think waitpid() will always and only write to status if the return >>> value is > 0 (ie it's a PID, not 0 or -1). So I think the right fix >>> for this problem is to have the if() protecting the put_user_s32() >>> read "if (ret && !is_error(ret) && ...". >>> >>> (ret == 0 is of course the WNOHANG-and-no-child-yet case you are hitting.) >> >> The man page wasn't really clear here. It sounded as if you can also >> get 0 as return value and still have status change. That's why I >> jumped through this hoop in the first place :) > > I think POSIX is clear enough. Either > * a child status is available, return pid and write to status > * WNOHANG & not ready, return 0 (don't write to status) > * -1 and set errno (don't write to status) > > (strictly, whether status is written for EINTR is unpredictable, but I > think we can assume nobody relies on this and I bet the kernel folks > wouldn't worry too much about changing that between versions...) Hrm, ok. I'll change it to your version then. Alex
Re: [Qemu-devel] [PATCH] linux-user: fix wait* syscall status returns
On 23 November 2011 22:03, Alexander Graf wrote: > On 23.11.2011, at 22:55, Peter Maydell wrote: >> If the problem is that waitpid() can return success without writing to >> status, then this code is still not right because we will get the >> initial target waitstatus into status, and then pass it through >> host_to_target_waitstatus(), possibly modifying it, before writing >> it back to guest memory. > > Yes. Maybe we should add a check if input_state != output_state and > only then do the conversion? I'm not sure this works (unless you go to the effort of implementing target_to_host_waitstatus() which seems overkill to me) but I'm not entirely sure what you're proposing to compare to what. >> I think waitpid() will always and only write to status if the return >> value is > 0 (ie it's a PID, not 0 or -1). So I think the right fix >> for this problem is to have the if() protecting the put_user_s32() >> read "if (ret && !is_error(ret) && ...". >> >> (ret == 0 is of course the WNOHANG-and-no-child-yet case you are hitting.) > > The man page wasn't really clear here. It sounded as if you can also > get 0 as return value and still have status change. That's why I > jumped through this hoop in the first place :) I think POSIX is clear enough. Either * a child status is available, return pid and write to status * WNOHANG & not ready, return 0 (don't write to status) * -1 and set errno (don't write to status) (strictly, whether status is written for EINTR is unpredictable, but I think we can assume nobody relies on this and I bet the kernel folks wouldn't worry too much about changing that between versions...) -- PMM
Re: [Qemu-devel] [PATCH 1.0 (resend)] eepro100: Fix alignment requirement for statistical counters
On Wed, Nov 23, 2011 at 10:20:30PM +0100, Stefan Weil wrote:
> According to Intel's Open Source Software Developer Manual,
> the dump counters address must be Dword aligned.
>
> The new code enforces this alignment, so s->statsaddr may now
> be used with stw_le_pci_dma() and stl_le_pci_dma().
>
> Signed-off-by: Stefan Weil
Anthiny, coul you apply pls?
> ---
> hw/eepro100.c | 10 +-
> 1 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/hw/eepro100.c b/hw/eepro100.c
> index 7d59e71..29ec5b4 100644
> --- a/hw/eepro100.c
> +++ b/hw/eepro100.c
> @@ -976,7 +976,15 @@ static void eepro100_cu_command(EEPRO100State * s,
> uint8_t val)
> case CU_STATSADDR:
> /* Load dump counters address. */
> s->statsaddr = e100_read_reg4(s, SCBPointer);
> -TRACE(OTHER, logout("val=0x%02x (status address)\n", val));
> +TRACE(OTHER, logout("val=0x%02x (dump counters address)\n", val));
> +if (s->statsaddr & 3) {
> +/* Memory must be Dword aligned. */
> +logout("unaligned dump counters address\n");
> +/* Handling of misaligned addresses is undefined.
> + * Here we align the address by ignoring the lower bits. */
> +/* TODO: Test unaligned dump counter address on real hardware. */
> +s->statsaddr &= ~3;
> +}
> break;
> case CU_SHOWSTATS:
> /* Dump statistical counters. */
> --
> 1.7.2.5
Re: [Qemu-devel] [PATCH] configure: avoid screening of --{en, dis}able-usb-redir options
On 23 November 2011 21:53, Max Filippov wrote:
> --*dir) option pattern precede --{en,dis}able-usb-redir) patterns in the
> option analysis switch, making the latter options have no effect.
>
> Signed-off-by: Max Filippov
I just said this in the other thread, but to repeat it in the
right place: I think we should expand out the case statement
to explicitly list the --thingydir options it is supposed to
be matching, and drop the wildcard: as this bug demonstrates
it's rather easy to accidentally shoot yourself in the foot
with it.
In fact, what cases is this supposed to be matching? All
the documented --thingydir options are handled explicitly
earlier in the case statement.
Paolo, you added this case in commit 6bde81cb0, but the
commit message doesn't give any rationale; what's it for?
-- PMM
Re: [Qemu-devel] cannot build qemu with "--static" configure option
On 23 November 2011 20:27, Mr Dash Four wrote: > Peter, I hope you would be able to advice me on the following, if you can > please: I have some ugly stuff in my qemu.spec file as follows: [delete huge spec file] > What parts do you think I should keep and should I delete, do you > have an idea? Sorry, I don't use RedHat and have no idea about specfiles. (It's a bit offtopic for qemu-devel really anyway.) -- PMM
Re: [Qemu-devel] cannot build qemu with "--static" configure option
On 23 November 2011 21:40, Max Filippov wrote: > --- a/configure > +++ b/configure > @@ -759,8 +759,6 @@ for opt do > ;; > --enable-opengl) opengl="yes" > ;; > - --*dir) > - ;; > --disable-rbd) rbd="no" > ;; > --enable-rbd) rbd="yes" Haha, nice catch. Incidentally I think that the proper fix for this should be to have a case statement that explicitly matches for the --thingydir options we accept, and drop the wildcard completely. -- PMM
Re: [Qemu-devel] [PATCH] linux-user: fix wait* syscall status returns
On 23.11.2011, at 22:55, Peter Maydell wrote:
> On 23 November 2011 20:38, Alexander Graf wrote:
>> When calling wait4 or waitpid with a status pointer and WNOHANG, the
>> syscall can potentially not modify the status pointer input. Now if we
>> have guest code like:
>>
>> int status = 0;
>> waitpid(pid, &status, WNOHANG);
>> if (status)
>>
>>
>> then we have to make sure that in case status did not change we actually
>> return the guest's initialized status variable instead of our own
>> uninitialized.
>> We fail to do so today, as we proxy everything through an uninitialized
>> status
>> variable which for me ended up always containing the last error code.
>>
>> This patch fixes some test cases when building yast2-core in OBS for ARM.
>>
>> Signed-off-by: Alexander Graf
>> ---
>> linux-user/syscall.c |8 +++-
>> 1 files changed, 7 insertions(+), 1 deletions(-)
>>
>> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
>> index 3e6f3bd..f86fe4a 100644
>> --- a/linux-user/syscall.c
>> +++ b/linux-user/syscall.c
>> @@ -4833,7 +4833,10 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
>> arg1,
>> #ifdef TARGET_NR_waitpid
>> case TARGET_NR_waitpid:
>> {
>> -int status;
>> +int status = 0;
>> +if (arg2) {
>> +get_user_s32(status, arg2);
>> +}
>> ret = get_errno(waitpid(arg1, &status, arg3));
>> if (!is_error(ret) && arg2
>> && put_user_s32(host_to_target_waitstatus(status), arg2))
>
> If the problem is that waitpid() can return success without writing to
> status, then this code is still not right because we will get the
> initial target waitstatus into status, and then pass it through
> host_to_target_waitstatus(), possibly modifying it, before writing
> it back to guest memory.
Yes. Maybe we should add a check if input_state != output_state and only then
do the conversion?
>
> I think waitpid() will always and only write to status if the return
> value is > 0 (ie it's a PID, not 0 or -1). So I think the right fix
> for this problem is to have the if() protecting the put_user_s32()
> read "if (ret && !is_error(ret) && ...".
>
> (ret == 0 is of course the WNOHANG-and-no-child-yet case you are hitting.)
The man page wasn't really clear here. It sounded as if you can also get 0 as
return value and still have status change. That's why I jumped through this
hoop in the first place :)
Alex
>
>> @@ -6389,6 +6392,9 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
>> arg1,
>> rusage_ptr = &rusage;
>> else
>> rusage_ptr = NULL;
>> +if (status_ptr) {
>> +get_user_s32(status, status_ptr);
>> +}
>> ret = get_errno(wait4(arg1, &status, arg3, rusage_ptr));
>> if (!is_error(ret)) {
>> if (status_ptr) {
>
> ...and similarly here.
>
> -- PMM
>
Re: [Qemu-devel] Status of the SH4 / ARM7 emulators
On 11/20/2011 12:51 PM, Andreas Färber wrote: > * Part of the problem is that common CPUState fields are not at the > start of the struct. I have therefore been playing with a > CPU_COMMON_PREFIX at the start of the struct and using a macro for > clearing on reset, which preserves part of the common prefix fields. Most of the RISC hosts have a limited displacement in their load and store instructions. E.g. 14 bits for Sparc, 12 bits for ARM, 10. We want to be able to load and store the target cpu registers very efficiently. If you move all the common fields to the beginning, that will include the (rather large) TLB tables, and overflow those small offsets. This change would almost certainly be a Large Mistake. r~
Re: [Qemu-devel] [PATCH] linux-user: fix wait* syscall status returns
On 23 November 2011 20:38, Alexander Graf wrote:
> When calling wait4 or waitpid with a status pointer and WNOHANG, the
> syscall can potentially not modify the status pointer input. Now if we
> have guest code like:
>
> int status = 0;
> waitpid(pid, &status, WNOHANG);
> if (status)
>
>
> then we have to make sure that in case status did not change we actually
> return the guest's initialized status variable instead of our own
> uninitialized.
> We fail to do so today, as we proxy everything through an uninitialized status
> variable which for me ended up always containing the last error code.
>
> This patch fixes some test cases when building yast2-core in OBS for ARM.
>
> Signed-off-by: Alexander Graf
> ---
> linux-user/syscall.c | 8 +++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 3e6f3bd..f86fe4a 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -4833,7 +4833,10 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
> arg1,
> #ifdef TARGET_NR_waitpid
> case TARGET_NR_waitpid:
> {
> - int status;
> + int status = 0;
> + if (arg2) {
> + get_user_s32(status, arg2);
> + }
> ret = get_errno(waitpid(arg1, &status, arg3));
> if (!is_error(ret) && arg2
> && put_user_s32(host_to_target_waitstatus(status), arg2))
If the problem is that waitpid() can return success without writing to
status, then this code is still not right because we will get the
initial target waitstatus into status, and then pass it through
host_to_target_waitstatus(), possibly modifying it, before writing
it back to guest memory.
I think waitpid() will always and only write to status if the return
value is > 0 (ie it's a PID, not 0 or -1). So I think the right fix
for this problem is to have the if() protecting the put_user_s32()
read "if (ret && !is_error(ret) && ...".
(ret == 0 is of course the WNOHANG-and-no-child-yet case you are hitting.)
> @@ -6389,6 +6392,9 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
> arg1,
> rusage_ptr = &rusage;
> else
> rusage_ptr = NULL;
> + if (status_ptr) {
> + get_user_s32(status, status_ptr);
> + }
> ret = get_errno(wait4(arg1, &status, arg3, rusage_ptr));
> if (!is_error(ret)) {
> if (status_ptr) {
...and similarly here.
-- PMM
[Qemu-devel] [PATCH] configure: avoid screening of --{en, dis}able-usb-redir options
--*dir) option pattern precede --{en,dis}able-usb-redir) patterns in the
option analysis switch, making the latter options have no effect.
Signed-off-by: Max Filippov
---
configure |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index f033438..e5566c8 100755
--- a/configure
+++ b/configure
@@ -759,8 +759,6 @@ for opt do
;;
--enable-opengl) opengl="yes"
;;
- --*dir)
- ;;
--disable-rbd) rbd="no"
;;
--enable-rbd) rbd="yes"
@@ -783,6 +781,8 @@ for opt do
;;
--disable-guest-agent) guest_agent="no"
;;
+ --*dir)
+ ;;
*) echo "ERROR: unknown option $opt"; show_help="yes"
;;
esac
--
1.7.6.4
Re: [Qemu-devel] cannot build qemu with "--static" configure option
> > Did configure reported 'usb net redir' as 'no'? > > Could you try configure and build in a clean directory? > [mr-4@test1 qemu-1.0-rc3]$ ./configure --target-list="arm-linux-user > armeb-linux-user" --disable-kvm --disable-strip --disable-xen --disable-spice > --disable-werror --disable-sdl --disable-vnc --disable-bluez > --disable-check-utests --disable-smartcard --disable-usb-redir --static ... > usb net redir yes > OpenGL supportno > libiscsi support no > build guest agent yes > > This is utterly bizarre! Why is "usb net redir" set as "yes" I have no idea! > Could you try configure with the following patch? diff --git a/configure b/configure index f033438..e5566c8 100755 --- a/configure +++ b/configure @@ -759,8 +759,6 @@ for opt do ;; --enable-opengl) opengl="yes" ;; - --*dir) - ;; --disable-rbd) rbd="no" ;; --enable-rbd) rbd="yes" @@ -783,6 +781,8 @@ for opt do ;; --disable-guest-agent) guest_agent="no" ;; + --*dir) + ;; *) echo "ERROR: unknown option $opt"; show_help="yes" ;; esac Thanks. -- Max
[Qemu-devel] [PATCH 1.0 (resend)] eepro100: Fix alignment requirement for statistical counters
According to Intel's Open Source Software Developer Manual,
the dump counters address must be Dword aligned.
The new code enforces this alignment, so s->statsaddr may now
be used with stw_le_pci_dma() and stl_le_pci_dma().
Signed-off-by: Stefan Weil
---
hw/eepro100.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index 7d59e71..29ec5b4 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -976,7 +976,15 @@ static void eepro100_cu_command(EEPRO100State * s, uint8_t
val)
case CU_STATSADDR:
/* Load dump counters address. */
s->statsaddr = e100_read_reg4(s, SCBPointer);
-TRACE(OTHER, logout("val=0x%02x (status address)\n", val));
+TRACE(OTHER, logout("val=0x%02x (dump counters address)\n", val));
+if (s->statsaddr & 3) {
+/* Memory must be Dword aligned. */
+logout("unaligned dump counters address\n");
+/* Handling of misaligned addresses is undefined.
+ * Here we align the address by ignoring the lower bits. */
+/* TODO: Test unaligned dump counter address on real hardware. */
+s->statsaddr &= ~3;
+}
break;
case CU_SHOWSTATS:
/* Dump statistical counters. */
--
1.7.2.5
Re: [Qemu-devel] [PATCH v3 1.0] configure: tighten pie toolchain support test for tls variables
On 23/11/11 4:24 AM, Avi Kivity wrote: Some toolchains don't support pie properly when tls variables are in use. Disallow pie when such toolchains are detected. Signed-off-by: Avi Kivity Thanks. Works as expected now. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [Qemu-devel] cannot build qemu with "--static" configure option
> Did configure reported 'usb net redir' as 'no'? > Could you try configure and build in a clean directory? [mr-4@test1 qemu-1.0-rc3]$ ./configure --target-list="arm-linux-user armeb-linux-user" --disable-kvm --disable-strip --disable-xen --disable-spice --disable-werror --disable-sdl --disable-vnc --disable-bluez --disable-check-utests --disable-smartcard --disable-usb-redir --static Install prefix/usr/local BIOS directory/usr/local/share/qemu binary directory /usr/local/bin library directory /usr/local/lib include directory /usr/local/include config directory /usr/local/etc Manual directory /usr/local/share/man ELF interp prefix /usr/gnemul/qemu-%M Source path /home/mr-4/qemu-1.0-rc3 C compilergcc Host C compiler gcc CFLAGS-O2 -g QEMU_CFLAGS -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fstack-protector-all -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits LDFLAGS -Wl,--warn-common -m64 -static -g make make install install pythonpython smbd /usr/sbin/smbd host CPU x86_64 host big endian no target list arm-linux-user armeb-linux-user tcg debug enabled no Mon debug enabled no gprof enabled no sparse enabledno strip binariesno profiler no static build yes -Werror enabled no SDL support no curses supportno curl support no check support no mingw32 support no Audio drivers oss Extra audio cards ac97 es1370 sb16 hda Block whitelist Mixer emulation no VNC support no xen support no brlapi supportno bluez supportno Documentation yes NPTL support yes GUEST_BASEyes PIE no vde support no Linux AIO support no ATTR/XATTR support yes Install blobs yes KVM support no TCG interpreter no fdt support no preadv supportyes fdatasync yes madvise yes posix_madvise yes uuid support no vhost-net support yes Trace backend nop Trace output file trace- spice support no rbd support no xfsctl supportno nss used no usb net redir yes OpenGL supportno libiscsi support no build guest agent yes This is utterly bizarre! Why is "usb net redir" set as "yes" I have no idea!
Re: [Qemu-devel] cannot build qemu with "--static" configure option
> Even though I executed "./configure --target-list="arm-linux-user > armeb-linux-user" --disable-kvm --disable-strip --disable-xen --disable-spice > --disable-werror --disable-sdl --disable-vnc --disable-bluez > --disable-check-utests --disable-smartcard --disable-usb-redir --static" the > -lusbredirparser is still pulled for some reason! Any ideas? > Did configure reported 'usb net redir' as 'no'? Could you try configure and build in a clean directory? Thanks. -- Max
Re: [Qemu-devel] cannot build qemu with "--static" configure option
> I don't get that - I get *SUCCESS*!!! I am going to run this through the > rpmbuild, so that I get a proper package done. I am an *idiot*. I just realised that I've ran ./configure the last time without the --static option. My build now fails with: gcc -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fstack-protector-all -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits-I../linux-headers -I.. -I/home/mr-4/qemu-1.0-rc3/target-arm -DNEED_CPU_H -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/home/mr-4/qemu-1.0-rc3/linux-user/arm -I/home/mr-4/qemu-1.0-rc3/linux-user -O2 -g -Wl,--warn-common -m64 -static -g -Wl,-T../config-host.ld -Wl,-T,/home/mr-4/qemu-1.0-rc3/x86_64.ld -o qemu-arm ../libdis-user/arm-dis.o ../libdis-user/i386-dis.o ../libuser/cache-utils.o ../libuser/cutils.o ../libuser/envlist.o ../libuser/host-utils.o ../libuser/path.o ../libuser/tcg-runtime.o ../libuser/trace.o ../libuser/trace/control.o ../libu ser/trace/default.o arm-semi.o cpu-exec.o cpu-uname.o disas.o elfload.o exec.o flatload.o fpu/softfloat.o gdbstub-xml.o gdbstub.o helper.o iwmmxt_helper.o linuxload.o main.o mmap.o neon_helper.o nwfpe/double_cpdo.o nwfpe/extended_cpdo.o nwfpe/fpa11.o nwfpe/fpa11_cpdo.o nwfpe/fpa11_cpdt.o nwfpe/fpa11_cprt.o nwfpe/fpopcode.o nwfpe/single_cpdo.o op_helper.o osdep.o oslib-posix.o qemu-thread-posix.o signal.o strace.o syscall.o tcg/optimize.o tcg/tcg.o thunk.o translate-all.o translate.o uaccess.o user-exec.o -lrt -pthread -pthread -lgthread-2.0 -lrt -lglib-2.0-lusbredirparser -lm /usr/bin/ld: cannot find -lusbredirparser collect2: ld returned 1 exit status make[1]: *** [qemu-arm] Error 1 make[1]: Leaving directory `/home/mr-4/qemu-1.0-rc3/arm-linux-user' make: *** [subdir-arm-linux-user] Error 2 Even though I executed "./configure --target-list="arm-linux-user armeb-linux-user" --disable-kvm --disable-strip --disable-xen --disable-spice --disable-werror --disable-sdl --disable-vnc --disable-bluez --disable-check-utests --disable-smartcard --disable-usb-redir --static" the -lusbredirparser is still pulled for some reason! Any ideas?
[Qemu-devel] [PATCH] linux-user: fix wait* syscall status returns
When calling wait4 or waitpid with a status pointer and WNOHANG, the
syscall can potentially not modify the status pointer input. Now if we
have guest code like:
int status = 0;
waitpid(pid, &status, WNOHANG);
if (status)
then we have to make sure that in case status did not change we actually
return the guest's initialized status variable instead of our own uninitialized.
We fail to do so today, as we proxy everything through an uninitialized status
variable which for me ended up always containing the last error code.
This patch fixes some test cases when building yast2-core in OBS for ARM.
Signed-off-by: Alexander Graf
---
linux-user/syscall.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 3e6f3bd..f86fe4a 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -4833,7 +4833,10 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
arg1,
#ifdef TARGET_NR_waitpid
case TARGET_NR_waitpid:
{
-int status;
+int status = 0;
+if (arg2) {
+get_user_s32(status, arg2);
+}
ret = get_errno(waitpid(arg1, &status, arg3));
if (!is_error(ret) && arg2
&& put_user_s32(host_to_target_waitstatus(status), arg2))
@@ -6389,6 +6392,9 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
rusage_ptr = &rusage;
else
rusage_ptr = NULL;
+if (status_ptr) {
+get_user_s32(status, status_ptr);
+}
ret = get_errno(wait4(arg1, &status, arg3, rusage_ptr));
if (!is_error(ret)) {
if (status_ptr) {
--
1.6.0.2
Re: [Qemu-devel] cannot build qemu with "--static" configure option
> In the latest F15 it's not fixed. Mr-4, probably you will not escape > re-compiling, if not even patching glib2. Nope, I've just built it successfully (see my previous post)!
Re: [Qemu-devel] cannot build qemu with "--static" configure option
> It fails some other way ):
>
> $ make V=1
> gcc -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
> -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef
> -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing
> -fstack-protector-all -Wendif-labels -Wmissing-include-dirs -Wempty-body
> -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self
> -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition
> -Wtype-limits -I../linux-headers -I..
> -I/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/target-i386 -DNEED_CPU_H -pthread
> -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
> -I/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/linux-user/x86_64
> -I/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/linux-user -O2 -g
> -Wl,--warn-common -m64 -static -g -Wl,-T../config-host.ld
> -Wl,-T,/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/x86_64.ld -o qemu-x86_64
> ../libdis-user/i386-dis.o ../libuser/cache-utils.o ../libuser/cutils.o
> ../libuser/envlist.o ../libuser/host-utils.o ../libuser/path.o
> ../libuser/tcg-runtime.o ../libu
ser/trace.o ../libuser/trace/control.o ../libuser/trace/default.o cpu-exec.o
cpu-uname.o cpuid.o disas.o elfload.o exec.o fpu/softfloat.o gdbstub.o helper.o
ioport-user.o linuxload.o main.o mmap.o op_helper.o osdep.o oslib-posix.o
qemu-thread-posix.o signal.o strace.o syscall.o tcg/optimize.o tcg/tcg.o
thunk.o translate-all.o translate.o uaccess.o user-exec.o -lrt -pthread
-pthread -lgthread-2.0 -lrt -lglib-2.0-lm
>
> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x24):
> undefined reference to `glib_mem__alloc_semaphore'
> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x7c):
> undefined reference to `glib_mem__alloc_semaphore'
> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0xd0):
> undefined reference to `glib_mem__alloc_semaphore'
> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x128):
> undefined reference to `glib_mem__alloc_semaphore'
> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x17c):
> undefined reference to `glib_mem__realloc_semaphore'
> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x1d8):
> undefined reference to `glib_mem__realloc_semaphore'
> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x230):
> undefined reference to `glib_mem__free_semaphore'
> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x274):
> undefined reference to `glib_mem__alloc_semaphore'
> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x2cc):
> undefined reference to `glib_mem__realloc_semaphore'
> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gslice.o):(.note.stapsdt+0x24):
> undefined reference to `glib_slice__alloc_semaphore'
> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gslice.o):(.note.stapsdt+0x70):
> undefined reference to `glib_slice__free_semaphore'
> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gdataset.o):(.note.stapsdt+0x24):
> undefined reference to `glib_quark__new_semaphore'
> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gdataset.o):(.note.stapsdt+0x70):
> undefined reference to `glib_quark__new_semaphore'
> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gdataset.o):(.note.stapsdt+0xbc):
> undefined reference to `glib_quark__new_semaphore'
> /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gdataset.o):(.note.stapsdt+0x108):
> undefined reference to `glib_quark__new_semaphore'
I don't get that - I get *SUCCESS*!!! I am going to run this through the
rpmbuild, so that I get a proper package done.
Peter, I hope you would be able to advice me on the following, if you can
please: I have some ugly stuff in my qemu.spec file as follows:
%build
# By default we build everything, but allow x86 to build a minimal version
# with only similar arch target support
%if %{with_x86only}
buildarch="i386-softmmu x86_64-softmmu i386-linux-user x86_64-linux-user"
%else
buildarch="i386-softmmu x86_64-softmmu arm-softmmu cris-softmmu
m68k-softmmu \
mips-softmmu mipsel-softmmu mips64-softmmu mips64el-softmmu \
sh4-softmmu sh4eb-softmmu \
i386-linux-user x86_64-linux-user alpha-linux-user arm-linux-user \
armeb-linux-user cris-linux-user m68k-linux-user mips-linux-user \
mipsel-linux-user sh4-linux-user sh4eb-linux-user" \
%endif
# --build-id option is used fedora 8 onwards for giving info to the debug
pa
Re: [Qemu-devel] [RFC PATCH] Exporting Guest RAM information for NUMA binding
On Wed, Nov 23, 2011 at 07:34:37PM +0100, Alexander Graf wrote: > So if you define "-numa node,mem=1G,cpus=0" then QEMU should be able to > tell the kernel that this GB of RAM actually is close to that vCPU thread. > Of course the admin still needs to decide how to split up memory. That's > the deal with emulating real hardware. You get the interfaces hardware > gets :). However, if you follow a reasonable default strategy such as The problem is how do you decide the parameter "-numa node,mem=1G,cpus=0". Real hardware exists when the VM starts. But then the VM can be migrated. Or the VM may have to be split in the middle of two nodes regardless of the -node node,mem=1G,cpus=0-1 to avoid swapping so there may be two 512M nodes with 1 cpu each instead of 1 NUMA node with 1G and 2 cpus. Especially by relaxing the hard bindings and using ms_mbind/tbind, the vtopology you create won't match real hardware because you don't know the real hardware that you will get. > numa splitting your RAM into equal chunks between guest vCPUs you're > probably close enough to optimal usage models. Or at least you could > have a close enough approximation of how this mapping could work for the > _guest_ regardless of the host and when you migrate it somewhere else it > should also work reasonably well. If you enforce these assumptions and the admin has still again to choose the "-numa node,mem=1G" parameters after checking the physical numa topology and make sure the vtopology can match the real physical topology and that the guest runs on "real hardware", it's not very different from using hard bindings, hard bindings enforces the "real hardware" so there's no way it can go wrong. I mean you still need some NUMA topology knowledge outside of QEMU to be sure you get "real hardware" out of the vtopology. Ok cpusets would restrict the availability of idle cpus, so there's a slight improvement in maximizing idle CPU usage (it's better to run 50% slower than not to run at all), but that could be achieved also by a relax of the cpuset semantics (if that's not already available). > So you want to basically dynamically create NUMA topologies from the > runtime behavior of the guest? What if it changes over time? Yes, just I wouldn't call it NUMA topologies or it looks like a vtopology, and the vtopology is something fixed at boot time, the sort of thing created by using a command line like "-numa node,mem=1G,cpu=0". I wouldn't try to give the guest any "memory" topology, just the vcpus are magic threads that don't behave like normal threads in memory affinity terms. So they need a paravirtualization layer to be dealt with. The fact vcpu0 accessed 10 pages right now, doesn't mean there's a real affinity between vcpu0 and those N pages if the guest scheduler is free to migrate anything anywhere. The guest thread running in the vcpu0 may be migrated to the vcpu7 which may belong to a different physical node. So if we want to automatically detect thread<->memory affinity between vcpus and guest memory, we also need to group the guest threads in certain vcpus and prevent those cpu migrations. The thread in the guest would better stick to vcpu0/1/2/3 (instead of migration to vcpu4/5/6/7) if vcpu0/1/2/3 have affinity with the same memory which fits in one node. That can only be told dynamically from KVM to the guest OS scheduler as we may migrate virtual machines or we may move the memory. Take the example of 3 VM of 2.5G ram each on a 8G system with 2 nodes (4G per node). Suppose one of the two VM that have all the 2.5G allocated in a single node quits. Then the VM that was split across the two nodes will "memory-migrated" to fit in one node. So far so good, but then KVM should tell the guest OS scheduler that it should stop grouping vcpus and all vcpus are equal and all guest threads can be migrated to any vcpu. I don't see a way to do those things with a vtopology fixed at boot. > I actually like the idea of just telling the kernel how close memory > will be to a thread. Sure, you can handle this basically by shoving your > scheduler into user space, but isn't managing processes what a kernel is > supposed to do in the first place? Assume you're not in virt and you just want to tell thread A uses memory range A and thread B uses memory range B. If the memory range A fits in one node you're ok. But if "memory A" now spans over two nodes (maybe to avoid swapping), you're still screwed and you won't give enough information to the kernel on the real runtime affinity that "thread A" has on the memory. Now if statistically the access to "memory a" are all equal, it won't make a difference but if you end up using half of "memory A" 99% of the time, it will not work as well. This is especially a problem for KVM because statistically the accesses to "memory a" given to vcpu0 won't be equal. 50% of it may not be used at all and just have pagecache sitting there, or even free memory, so we can do better if "memory a" is sp
Re: [Qemu-devel] cannot build qemu with "--static" configure option
> It fails some other way ): > > $ make V=1 > gcc -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 > -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef > -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing > -fstack-protector-all -Wendif-labels -Wmissing-include-dirs -Wempty-body > -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self > -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition > -Wtype-limits -I../linux-headers -I.. > -I/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/target-i386 -DNEED_CPU_H -pthread > -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include > -I/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/linux-user/x86_64 > -I/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/linux-user -O2 -g > -Wl,--warn-common -m64 -static -g -Wl,-T../config-host.ld > -Wl,-T,/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/x86_64.ld -o qemu-x86_64 > ../libdis-user/i386-dis.o ../libuser/cache-utils.o ../libuser/cutils.o > ../libuser/envlist.o ../libuser/host-utils.o ../libuser/path.o > ../libuser/tcg-runtime.o ../libuser/trace.o ../libuser/trace/control.o > ../libuser/trace/default.o cpu-exec.o cpu-uname.o cpuid.o disas.o elfload.o > exec.o fpu/softfloat.o gdbstub.o helper.o ioport-user.o linuxload.o main.o > mmap.o op_helper.o osdep.o oslib-posix.o qemu-thread-posix.o signal.o > strace.o syscall.o tcg/optimize.o tcg/tcg.o thunk.o translate-all.o > translate.o uaccess.o user-exec.o -lrt -pthread -pthread -lgthread-2.0 -lrt > -lglib-2.0-lm > > /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x24): > undefined reference to `glib_mem__alloc_semaphore' > /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x7c): > undefined reference to `glib_mem__alloc_semaphore' > /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0xd0): > undefined reference to `glib_mem__alloc_semaphore' ... It appears to be glib2 issue: https://bugzilla.gnome.org/show_bug.cgi?id=654078 In the latest F15 it's not fixed. Mr-4, probably you will not escape re-compiling, if not even patching glib2. Thanks. -- Max
Re: [Qemu-devel] cannot build qemu with "--static" configure option
>> That is what I just wrote in my previous post, didn't I? The "die die die"
>> comments were related to the glib package, not the glib2! Just open
>> glib.spec and see it for yourself.
>
> However it looks from Max's list of libraries like the glib2-static package
> contains all the static libraries qemu wants here [both libglib-2.0 and
> libgthread-2.0]so so you don't need to build anything yourself, just install
> that, right?
That's what I am doing now, *but* the strange thing is, I now get build failure
because of two *new* unpackaged files:
%{_datadir}/systemtap/tapset/glib.stp
%{_datadir}/systemtap/tapset/gobject.stp
I presume these are destined to be in the -devel package so I'll include them
there myself. Max is right though - indeed the -static package covers both
libglib-2.0 and libgthread-2.0, so I am just compiling the source rm at present
and will update the devel and static packages when it is done. Will let you
know how it goes.
Re: [Qemu-devel] cannot build qemu with "--static" configure option
> >>> So, somebody at Fedora doesn't like static (.a) files very much, it > >>> seems. I could easily correct this, enable static building and have these > >>> installed, I think. > >> > >> There's glib2-static in Fedora: > >> > >> $ rpm -ql glib2-static > >> /usr/lib64/libgio-2.0.a > >> /usr/lib64/libglib-2.0.a > >> /usr/lib64/libgmodule-2.0.a > >> /usr/lib64/libgobject-2.0.a > >> /usr/lib64/libgthread-2.0.a > > That is what I just wrote in my previous post, didn't I? The "die die die" > > comments were related to the glib package, not the glib2! Just open > > glib.spec and see it for yourself. > > However it looks from Max's list of libraries like the glib2-static package > contains all the static libraries qemu wants here [both libglib-2.0 and > libgthread-2.0]so so you don't need to build anything yourself, just install > that, right? It fails some other way ): $ make V=1 gcc -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fstack-protector-all -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -I../linux-headers -I.. -I/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/target-i386 -DNEED_CPU_H -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/linux-user/x86_64 -I/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/linux-user -O2 -g -Wl,--warn-common -m64 -static -g -Wl,-T../config-host.ld -Wl,-T,/home/jcmvbkbc/ws/m/awt/emu/xtensa/qemu/x86_64.ld -o qemu-x86_64 ../libdis-user/i386-dis.o ../libuser/cache-utils.o ../libuser/cutils.o ../libuser/envlist.o ../libuser/host-utils.o ../libuser/path.o ../libuser/tcg-runtime.o ../libuser/trace.o ../libuser/trace/control.o ../libuser/trace/default.o cpu-exec.o cpu-uname.o cpuid.o disas.o elfload.o exec.o fpu/softfloat.o gdbstub.o helper.o ioport-user.o linuxload.o main.o mmap.o op_helper.o osdep.o oslib-posix.o qemu-thread-posix.o signal.o strace.o syscall.o tcg/optimize.o tcg/tcg.o thunk.o translate-all.o translate.o uaccess.o user-exec.o -lrt -pthread -pthread -lgthread-2.0 -lrt -lglib-2.0 -lm /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x24): undefined reference to `glib_mem__alloc_semaphore' /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x7c): undefined reference to `glib_mem__alloc_semaphore' /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0xd0): undefined reference to `glib_mem__alloc_semaphore' /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x128): undefined reference to `glib_mem__alloc_semaphore' /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x17c): undefined reference to `glib_mem__realloc_semaphore' /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x1d8): undefined reference to `glib_mem__realloc_semaphore' /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x230): undefined reference to `glib_mem__free_semaphore' /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x274): undefined reference to `glib_mem__alloc_semaphore' /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gmem.o):(.note.stapsdt+0x2cc): undefined reference to `glib_mem__realloc_semaphore' /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gslice.o):(.note.stapsdt+0x24): undefined reference to `glib_slice__alloc_semaphore' /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gslice.o):(.note.stapsdt+0x70): undefined reference to `glib_slice__free_semaphore' /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gdataset.o):(.note.stapsdt+0x24): undefined reference to `glib_quark__new_semaphore' /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gdataset.o):(.note.stapsdt+0x70): undefined reference to `glib_quark__new_semaphore' /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gdataset.o):(.note.stapsdt+0xbc): undefined reference to `glib_quark__new_semaphore' /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../lib64/libglib-2.0.a(gdataset.o):(.note.stapsdt+0x108): undefined reference to `glib_quark__new_semaphore' Thanks. -- Max
Re: [Qemu-devel] cannot build qemu with "--static" configure option
On 23 November 2011 19:57, Mr Dash Four wrote: >>> So, somebody at Fedora doesn't like static (.a) files very much, it seems. >>> I could easily correct this, enable static building and have these >>> installed, I think. >> >> There's glib2-static in Fedora: >> >> $ rpm -ql glib2-static >> /usr/lib64/libgio-2.0.a >> /usr/lib64/libglib-2.0.a >> /usr/lib64/libgmodule-2.0.a >> /usr/lib64/libgobject-2.0.a >> /usr/lib64/libgthread-2.0.a > That is what I just wrote in my previous post, didn't I? The "die die die" > comments were related to the glib package, not the glib2! Just open glib.spec > and see it for yourself. However it looks from Max's list of libraries like the glib2-static package contains all the static libraries qemu wants here [both libglib-2.0 and libgthread-2.0]so so you don't need to build anything yourself, just install that, right? -- PMM
Re: [Qemu-devel] cannot build qemu with "--static" configure option
>> So, somebody at Fedora doesn't like static (.a) files very much, it seems. I >> could easily correct this, enable static building and have these installed, >> I think. > > There's glib2-static in Fedora: > > $ rpm -ql glib2-static > /usr/lib64/libgio-2.0.a > /usr/lib64/libglib-2.0.a > /usr/lib64/libgmodule-2.0.a > /usr/lib64/libgobject-2.0.a > /usr/lib64/libgthread-2.0.a That is what I just wrote in my previous post, didn't I? The "die die die" comments were related to the glib package, not the glib2! Just open glib.spec and see it for yourself.
Re: [Qemu-devel] cannot build qemu with "--static" configure option
> > Do you have a static libgthread-2.0? (ie /usr/lib/libgthread-2.0.a or
> > equivalent).
> Nope, this is what I have:
>
> /usr/lib64/libgthread.so
> /usr/lib64/libgthread-2.0.so
> /usr/lib64/libgthread-1.2.so.0
> /usr/lib64/libgthread-1.2.so.0.0.10
>
> *but*, just downloaded the source rpm and looked at the .spec file. It
> contains the following few lines in the %build section:
>
> %configure --disable-static
> [...]
> ## Unpackaged files
> # info
> %{__rm} -rf %{buildroot}%{_infodir}
> # .la fies... die die die.
> %{__rm} -rf %{buildroot}%{_libdir}/lib*.la
> # despite use of --disable-static, delete static libs that get built anyway
> %{__rm} -rf %{buildroot}%{_libdir}/lib*.a
>
>
> So, somebody at Fedora doesn't like static (.a) files very much, it seems. I
> could easily correct this, enable static building and have these installed, I
> think.
There's glib2-static in Fedora:
$ rpm -ql glib2-static
/usr/lib64/libgio-2.0.a
/usr/lib64/libglib-2.0.a
/usr/lib64/libgmodule-2.0.a
/usr/lib64/libgobject-2.0.a
/usr/lib64/libgthread-2.0.a
Thanks.
-- Max
Re: [Qemu-devel] cannot build qemu with "--static" configure option
> Do you have a static libgthread-2.0? (ie /usr/lib/libgthread-2.0.a or
> equivalent).
Nope, this is what I have:
/usr/lib64/libgthread.so
/usr/lib64/libgthread-2.0.so
/usr/lib64/libgthread-1.2.so.0
/usr/lib64/libgthread-1.2.so.0.0.10
*but*, just downloaded the source rpm and looked at the .spec file. It contains
the following few lines in the %build section:
%configure --disable-static
[...]
## Unpackaged files
# info
%{__rm} -rf %{buildroot}%{_infodir}
# .la fies... die die die.
%{__rm} -rf %{buildroot}%{_libdir}/lib*.la
# despite use of --disable-static, delete static libs that get built anyway
%{__rm} -rf %{buildroot}%{_libdir}/lib*.a
So, somebody at Fedora doesn't like static (.a) files very much, it seems. I
could easily correct this, enable static building and have these installed, I
think.
If not you need to install it. Similarly you'll need
> a static libglib-2.0.
Here, things are a bit easier - even though I do have the glib2-devel and glib2
packages installed, looking at the source rpm there is a separate package
called glib2-static, so I'll just install it and get on with it.
I presume after doing all this I need to rerun the stripped-down version of
./configure again, right? If so, I'll do just that and let you know how it goes.
[Qemu-devel] Latest QEMU does not support --enable-check-utests on Debian with --enable-pie (default)
This is my configuration and the output from configure: configure '--audio-card-list=ac97,es1370,sb16,cs4231a,adlib,gus,hda' '--audio-drv-list=alsa,sdl,oss,esd,pa' '--enable-mixemu' '--enable-check-utests' '--enable-vnc-thread' ERROR ERROR: User requested feature check ERROR: configure was not able to find it ERROR This is what configure does internally: gcc -fPIE -DPIE -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wmissing-format-attribute -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fstack-protector-all -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -I/usr/include/libpng12 -o /tmp/qemu-conf--4272-.exe /tmp/qemu-conf--4272-.c -Wl,-z,relro -Wl,-z,now -pie -m64 -g -lcheck /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/libcheck.a(check.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/libcheck.a: could not read symbols: Bad value When I add --disable-pie, configure works. Regards, Stefan Weil
Re: [Qemu-devel] cannot build qemu with "--static" configure option
On 23 November 2011 19:22, Mr Dash Four wrote: > >> OK. We don't explicitly try to link with ssl3 ourselves, so this only >> ever ends up in LDFLAGS because of some other library that has claimed >> it needs it as a dependency via pkg-config. Try adding >> --disable-sdl --disable-vnc --disable-bluez --disable-check-utests >> --disable-smartcard --disable-usb-redir >> >> to your configure argument. That turns off a lot of stuff that's irrelevant >> for linux-user and which might be pulling in this library. If that works >> then you can identify which particular switch is needed by process of >> elimination. > Different error this time: Good, we've got rid of the ssl3 link attempt. > /usr/bin/ld: cannot find -lgthread-2.0 Do you have a static libgthread-2.0? (ie /usr/lib/libgthread-2.0.a or equivalent). If not you need to install it. Similarly you'll need a static libglib-2.0. -- PMM
Re: [Qemu-devel] cannot build qemu with "--static" configure option
> Which binary are we trying to link when we fail? This is where it all fails: gcc -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fstack-protector-all -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -I/home/mr-4/qemu-1.0-rc3/libcacard -I/usr/include/nss3 -I/usr/include/nspr4 -I../linux-headers -I.. -I/home/mr-4/qemu-1.0-rc3/target-i386 -DNEED_CPU_H -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/home/mr-4/qemu-1.0-rc3/linux-user/x86_64 -I/home/mr-4/qemu-1.0-rc3/linux-user -O2 -g -Wl,--warn-common -m64 -static -g -Wl,-T../config-host.ld -Wl,-T,/home/mr-4/qemu-1.0-rc3/x86_64.ld -o qemu-x86_64 ../libdis-user/i386-dis.o ../libuser/cache-utils.o ../libuser/cutils.o ../libuser/envlist.o ../libuser/host-utils.o ../libuser/path.o ../libuser/tcg-ru ntime.o ../libuser/trace.o ../libuser/trace/control.o ../libuser/trace/default.o cpu-exec.o cpu-uname.o cpuid.o disas.o elfload.o exec.o fpu/softfloat.o gdbstub.o helper.o ioport-user.o linuxload.o main.o mmap.o op_helper.o osdep.o oslib-posix.o qemu-thread-posix.o signal.o strace.o syscall.o tcg/optimize.o tcg/tcg.o thunk.o translate-all.o translate.o uaccess.o user-exec.o -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lrt -pthread -pthread -lgthread-2.0 -lrt -lglib-2.0 -lusbredirparser -lm /usr/bin/ld: cannot find -lssl3 collect2: ld returned 1 exit status make[1]: *** [qemu-x86_64] Error 1 make[1]: Leaving directory `/home/mr-4/qemu-1.0-rc3/x86_64-linux-user' make: *** [subdir-x86_64-linux-user] Error 2 > OK. We don't explicitly try to link with ssl3 ourselves, so this only > ever ends up in LDFLAGS because of some other library that has claimed > it needs it as a dependency via pkg-config. Try adding > --disable-sdl --disable-vnc --disable-bluez --disable-check-utests > --disable-smartcard --disable-usb-redir > > to your configure argument. That turns off a lot of stuff that's irrelevant > for linux-user and which might be pulling in this library. If that works > then you can identify which particular switch is needed by process of > elimination. Different error this time: ./configure --target-list="x86_64-linux-user arm-linux-user armeb-linux-user" --disable-kvm --disable-strip --disable-xen --disable-spice --disable-werror --static --disable-sdl --disable-vnc --disable-bluez --disable-check-utests --disable-smartcard --disable-usb-redir make V=1 gcc -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fstack-protector-all -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits-I../linux-headers -I.. -I/home/mr-4/qemu-1.0-rc3/target-i386 -DNEED_CPU_H -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/home/mr-4/qemu-1.0-rc3/linux-user/x86_64 -I/home/mr-4/qemu-1.0-rc3/linux-user -O2 -g -Wl,--warn-common -m64 -static -g -Wl,-T../config-host.ld -Wl,-T,/home/mr-4/qemu-1.0-rc3/x86_64.ld -o qemu-x86_64 ../libdis-user/i386-dis.o ../libuser/cache-utils.o ../libuser/cutils.o ../libuser/envlist.o ../libuser/host-utils.o ../libuser/path.o ../libuser/tcg-runtime.o ../libuser/trace.o ../libuser/trace/control.o ../libuser/trace/default. o cpu-exec.o cpu-uname.o cpuid.o disas.o elfload.o exec.o fpu/softfloat.o gdbstub.o helper.o ioport-user.o linuxload.o main.o mmap.o op_helper.o osdep.o oslib-posix.o qemu-thread-posix.o signal.o strace.o syscall.o tcg/optimize.o tcg/tcg.o thunk.o translate-all.o translate.o uaccess.o user-exec.o -lrt -pthread -pthread -lgthread-2.0 -lrt -lglib-2.0-lusbredirparser -lm /usr/bin/ld: cannot find -lgthread-2.0 collect2: ld returned 1 exit status make[1]: *** [qemu-x86_64] Error 1 make[1]: Leaving directory `/home/mr-4/qemu-1.0-rc3/x86_64-linux-user' make: *** [subdir-x86_64-linux-user] Error 2
Re: [Qemu-devel] cannot build qemu with "--static" configure option
On 23 November 2011 19:02, Mr Dash Four wrote: > >> Sonuds like a good plan. > Nope, same error as before: > /usr/bin/ld: cannot find -lssl3 > collect2: ld returned 1 exit status Which binary are we trying to link when we fail? > I get exactly the same result if I just unpack the source and run ./configure > & > then make (not going through the rpmbuild source "preparation"), so something > is > definitely amiss! OK. We don't explicitly try to link with ssl3 ourselves, so this only ever ends up in LDFLAGS because of some other library that has claimed it needs it as a dependency via pkg-config. Try adding --disable-sdl --disable-vnc --disable-bluez --disable-check-utests --disable-smartcard --disable-usb-redir to your configure argument. That turns off a lot of stuff that's irrelevant for linux-user and which might be pulling in this library. If that works then you can identify which particular switch is needed by process of elimination. -- PMM
Re: [Qemu-devel] cannot build qemu with "--static" configure option
> Sonuds like a good plan. Nope, same error as before: /usr/bin/ld: cannot find -lssl3 collect2: ld returned 1 exit status The source was unpacked, I disabled all the patches in that .spec file, ran "rpmbuild -bp qemu.spec", then manually went to that directory (BUILD/qemu-1.0-rc3) and typed "./configure --target-list="x86_64-linux-user arm-linux-user armeb-linux-user" --disable-kvm --disable-strip --disable-xen --disable-spice --disable-werror --static", followed by "make V=1". I get exactly the same result if I just unpack the source and run ./configure & then make (not going through the rpmbuild source "preparation"), so something is definitely amiss!
Re: [Qemu-devel] cannot build qemu with "--static" configure option
On 23 November 2011 18:42, Mr Dash Four wrote: >> Can you retry this with one of the 1.0 release candidates >> or current head-of-git, please? > OK, I'll try with 1.0-rc3, but before that just a quick query - I use the > Fedora source rpm as a basis and do "rpmbuild -bp qemu.spec" to prepare > the source. This, according to the said .spec file, applies the following > patches (by Fedora, not me): [skip long list] > I am almost certain that the majority of these will fail with the new source, > so I'll try to build without those. Is that OK? I expect so. I have no idea what the Fedora patches are but if upstream's sources don't work without needing extra patches that's what we care about. > Interesting. I'll do a "vanilla" build (with no patches applied) and see > how it goes, unless you have something else in mind? Sonuds like a good plan. -- PMM
Re: [Qemu-devel] cannot build qemu with "--static" configure option
> Can you retry this with one of the 1.0 release candidates > or current head-of-git, please? OK, I'll try with 1.0-rc3, but before that just a quick query - I use the Fedora source rpm as a basis and do "rpmbuild -bp qemu.spec" to prepare the source. This, according to the said .spec file, applies the following patches (by Fedora, not me): Patch01: 0001-char-Split-out-tcp-socket-close-code-in-a-separate-f.patch Patch02: 0002-char-Add-a-QemuChrHandlers-struct-to-initialise-char.patch Patch03: 0003-iohandlers-Add-enable-disable_write_fd_handler-funct.patch Patch04: 0004-char-Add-framework-for-a-write-unblocked-callback.patch Patch05: 0005-char-Update-send_all-to-handle-nonblocking-chardev-w.patch Patch06: 0006-char-Equip-the-unix-tcp-backend-to-handle-nonblockin.patch Patch07: 0007-char-Throttle-when-host-connection-is-down.patch Patch08: 0008-virtio-console-Enable-port-throttling-when-chardev-i.patch Patch09: 0009-spice-qemu-char.c-add-throttling.patch Patch10: 0010-spice-qemu-char.c-remove-intermediate-buffer.patch Patch11: 0011-usb-redir-Add-flow-control-support.patch Patch12: 0012-spice-add-worker-wrapper-functions.patch Patch13: 0013-spice-add-qemu_spice_display_init_common.patch Patch14: 0014-spice-qxl-move-worker-wrappers.patch Patch15: 0015-qxl-fix-surface-tracking-locking.patch Patch16: 0016-qxl-add-io_port_to_string.patch Patch17: 0017-qxl-error-handling-fixes-and-cleanups.patch Patch18: 0018-qxl-make-qxl_guest_bug-take-variable-arguments.patch Patch19: 0019-qxl-only-disallow-specific-io-s-in-vga-mode.patch Patch20: 0020-qxl-async-io-support-using-new-spice-api.patch Patch21: 0021-qxl-add-QXL_IO_FLUSH_-SURFACES-RELEASE-for-guest-S3-.patch Patch22: 0022-qxl-bump-pci-rev.patch Patch23: 0023-virtio-serial-bus-replay-guest_open-on-migration.patch Patch24: 0024-qemu-char-make-qemu_chr_event-public.patch Patch25: 0025-spice-qemu-char-Generate-chardev-open-close-events.patch Patch26: 0026-usb-redir-Call-qemu_chr_guest_open-close.patch Patch27: 0027-usb-redir-Device-disconnect-re-connect-robustness-fi.patch Patch28: 0028-usb-redir-Don-t-try-to-write-to-the-chardev-after-a-.patch I am almost certain that the majority of these will fail with the new source, so I'll try to build without those. Is that OK? > (when I do a static build it doesn't try to link against ssl3.) Interesting. I'll do a "vanilla" build (with no patches applied) and see how it goes, unless you have something else in mind?
Re: [Qemu-devel] cannot build qemu with "--static" configure option
On 23 November 2011 18:33, Mr Dash Four wrote: > FYI Peter, I just tried to build qemu with only the -user targets - > unsuccessfully - exactly the same error as before -lssl3 cannot be found. Can you retry this with one of the 1.0 release candidates or current head-of-git, please? (when I do a static build it doesn't try to link against ssl3.) thanks -- PMM
Re: [Qemu-devel] cannot build qemu with "--static" configure option
>> >> So, where do I get this? > > > > You don't. Fedora does not package static libraries. Just don't use > > the option on Linux, it makes (a little) sense only on Windows to get a > > monolithic, redistributable qemu.exe. So, what you are suggesting above is that qemu-[arch]-static cannot be build on Linux? I mean, you can't be serious, really?!
Re: [Qemu-devel] cannot build qemu with "--static" configure option
>> You don't. Fedora does not package static libraries. Just don't use the >> option on Linux, it makes (a little) sense only on Windows to get a >> monolithic, redistributable qemu.exe. > > It's also important for building linux-user targets so you can > put them in chroots. Luckily linux-user doesn't link against > quite so much of the world as the whole-system qemu binary... My thoughts exactly! Without having static qemu built I simply can't use it for the purpose I stated in my previous post. FYI Peter, I just tried to build qemu with only the -user targets - unsuccessfully - exactly the same error as before -lssl3 cannot be found.
Re: [Qemu-devel] [RFC PATCH] Exporting Guest RAM information for NUMA binding
On 11/23/2011 04:03 PM, 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". 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. I doubt that the assumption that all cloud nodes will have the same physical numa topology is reasonable. 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). I think it's unreasonable to expect all applications to use ms_mbind/ms_tbind in the guest, at best guest apps will use cpusets or wrappers, few apps will be modified for sys_ms_tbind/mbind. You can always have the supercomputer case with just one app that is optimized and a single VM spanning over the whole host, but in that scenarios hard bindings would work perfectly too. 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. Well yeah, of course the guest needs to see some topology. I don't see why we'd have to actually scan the host for this though. All we need to tell the kernel is "this memory region is close to that thread". So if you define "-numa node,mem=1G,cpus=0" then QEMU should be able to tell the kernel that this GB of RAM actually is close to that vCPU thread. Of course the admin still needs to decide how to split up memory. That's the deal with emulating real hardware. You get the interfaces hardware gets :). However, if you follow a reasonable default strategy such as numa splitting your RAM into equal chunks between guest vCPUs you're probably close enough to optimal usage models. Or at least you could have a close enough approximation of how this mapping could work for the _guest_ regardless of the host and when you migrate it somewhere else it should also work reasonably well. Now dealing with bindings isn't big deal for qemu, in fact this API is pretty much ideal for qemu, but it won't make life substantially easier than if compared to hard bindings. Simply the management code that is now done with a perl script will have to be moved in the kernel. It looks an incremental improvement compared to the relative mbind+cpuset, but I'm unsure if it's the best we could aim for and what we really need in virt considering we deal with VM migration too. The real long term design to me is not to add more syscalls, and initially handling the case of a process/VM spanning not more than one node in thread number and amount of memory. That's not too hard an in fact I've benchmarks for the scheduler already showing it to work pretty well (it's creating a too strict affinity but it can be relaxed to be more useful). Then later add some mechanism (simplest is the page fault at low frequency) to create a guest_vcpu_thread<->host_memory affinity and have a parvirtualized interface that tells the guest scheduler to group CPUs. If the
Re: [Qemu-devel] cannot build qemu with "--static" configure option
On 23 November 2011 18:00, Paolo Bonzini wrote: > You don't. Fedora does not package static libraries. Just don't use the > option on Linux, it makes (a little) sense only on Windows to get a > monolithic, redistributable qemu.exe. It's also important for building linux-user targets so you can put them in chroots. Luckily linux-user doesn't link against quite so much of the world as the whole-system qemu binary... -- PMM
Re: [Qemu-devel] [Xen-devel] [PATCH V4 05/10] Introduce HostPCIDevice to access a pci device on the host.
On Fri, Nov 18, 2011 at 15:06, Konrad Rzeszutek Wilk
wrote:
>> +static int host_pci_config_read(HostPCIDevice *d, int pos, void *buf, int
>> len)
>> +{
>> + int fd = host_pci_config_fd(d);
>> + int res = 0;
>> +
>> +again:
>> + res = pread(fd, buf, len, pos);
>> + if (res != len) {
>> + if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
>> + goto again;
>> + }
>> + fprintf(stderr, "host_pci_config: read failed: %s (fd: %i)\n",
>> + strerror(errno), fd);
>> + return -errno;
>> + }
>> + return 0;
>> +}
>> +static int host_pci_config_write(HostPCIDevice *d,
>> + int pos, const void *buf, int len)
>> +{
>> + int fd = host_pci_config_fd(d);
>> + int res = 0;
>> +
>> +again:
>> + res = pwrite(fd, buf, len, pos);
>> + if (res != len) {
>> + if (res < 0 && (errno == EINTR || errno == EAGAIN)) {
>> + goto again;
>> + }
>> + fprintf(stderr, "host_pci_config: write failed: %s\n",
>> + strerror(errno));
>> + return -errno;
>> + }
>> + return 0;
>> +}
>> +
>> +int host_pci_get_byte(HostPCIDevice *d, int pos, uint8_t *p)
>> +{
>> + uint8_t buf;
>> + if (host_pci_config_read(d, pos, &buf, 1)) {
>> + return -1;
>
> Would it make sense to use the nice enum you decleraed at the
> top of the file? Or not?
I should probably return -errno instead, I mean the return value of
host_pci_config_read/write.
I just introduce the enum to have a differente value than -errno for
some internal function (get_ressource/get_hex_value), so I don't think
that the enum can really by used outside of this file, yet.
(I will change the rest of the patch as you sugest in your comment)
Thanks,
--
Anthony PERARD
Re: [Qemu-devel] [PATCH v3 07/11] bonito: convert north bridge register mapping to memory API
2011/11/23 Benoît Canet : > It would work using memory_region_add_subregion() and get_system_memory() > but Avi previously noticed me that using get_system_memory() in devices > is wrong because it goes against one of the goals of the memory API : > avoiding global knowledge. Yes. It's a bit difficult to tell without hardware docs for this chip, but I suspect that at least some of these memory regions should actually be registered as part of the init of the "Bonito-pcihost" sysbus device and then mapped by bonito_init(). But I don't know enough about PCI or the Bonito to know just how much of bonito_initfn() ought to move into bonito_pcihost_initfn(). -- PMM
[Qemu-devel] [PATCH 2/7] usb: fix usb_qdev_init error handling.
qdev doesn't call the ->exit callback on ->init failures, so we have to
take care ourself that we cleanup property on errors.
Signed-off-by: Gerd Hoffmann
---
hw/usb-bus.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index f8b9807..8cafb76 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
@@ -9,6 +9,7 @@ static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev,
int indent);
static char *usb_get_dev_path(DeviceState *dev);
static char *usb_get_fw_dev_path(DeviceState *qdev);
+static int usb_qdev_exit(DeviceState *qdev);
static struct BusInfo usb_bus_info = {
.name = "USB",
@@ -75,12 +76,23 @@ static int usb_qdev_init(DeviceState *qdev, DeviceInfo
*base)
dev->auto_attach = 1;
QLIST_INIT(&dev->strings);
rc = usb_claim_port(dev);
-if (rc == 0) {
-rc = dev->info->init(dev);
+if (rc != 0) {
+goto err;
}
-if (rc == 0 && dev->auto_attach) {
+rc = dev->info->init(dev);
+if (rc != 0) {
+goto err;
+}
+if (dev->auto_attach) {
rc = usb_device_attach(dev);
+if (rc != 0) {
+goto err;
+}
}
+return 0;
+
+err:
+usb_qdev_exit(qdev);
return rc;
}
--
1.7.1
[Qemu-devel] [PATCH 4/7] usb-hub: implement reset
based on a patch from hk...@linux.vnet.ibm.com
Signed-off-by: Gerd Hoffmann
---
hw/usb-hub.c | 20 +---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/hw/usb-hub.c b/hw/usb-hub.c
index 5b48763..e195937 100644
--- a/hw/usb-hub.c
+++ b/hw/usb-hub.c
@@ -222,7 +222,22 @@ static void usb_hub_complete(USBPort *port, USBPacket
*packet)
static void usb_hub_handle_reset(USBDevice *dev)
{
-/* XXX: do it */
+USBHubState *s = DO_UPCAST(USBHubState, dev, dev);
+USBHubPort *port;
+int i;
+
+for (i = 0; i < NUM_PORTS; i++) {
+port = s->ports + i;
+port->wPortStatus = PORT_STAT_POWER;
+port->wPortChange = 0;
+if (port->port.dev && port->port.dev->attached) {
+port->wPortStatus |= PORT_STAT_CONNECTION;
+port->wPortChange |= PORT_STAT_C_CONNECTION;
+if (port->port.dev->speed == USB_SPEED_LOW) {
+port->wPortStatus |= PORT_STAT_LOW_SPEED;
+}
+}
+}
}
static int usb_hub_handle_control(USBDevice *dev, USBPacket *p,
@@ -497,9 +512,8 @@ static int usb_hub_initfn(USBDevice *dev)
&port->port, s, i, &usb_hub_port_ops,
USB_SPEED_MASK_LOW | USB_SPEED_MASK_FULL);
usb_port_location(&port->port, dev->port, i+1);
-port->wPortStatus = PORT_STAT_POWER;
-port->wPortChange = 0;
}
+usb_hub_handle_reset(dev);
return 0;
}
--
1.7.1
[Qemu-devel] [PULL 1.0] usb fixes
Hi, A few more usb bugfixes. Two are pretty serious error handling issues (patches 1+2) which can lead to use-after-free. The other ones are minor but still nice to have and simple enougth that the risk to break something is low. please pull, Gerd The following changes since commit 40897c9c160393df922dfdb59cfa210048d3071d: Update version for 1.0-rc3 release (2011-11-21 15:05:59 -0600) are available in the git repository at: git://git.kraxel.org/qemu usb.32 Gerd Hoffmann (7): usb: make usb_create_simple catch and pass up errors. usb: fix usb_qdev_init error handling. usb-hub: wakeup on detach too. usb-hub: implement reset usb-ehci: codestyle fixups usb-ehci: add register names usb-host: add usb_host_do_reset function. hw/usb-bt.c |3 ++ hw/usb-bus.c | 29 +++ hw/usb-ehci.c | 58 +--- hw/usb-hub.c | 22 ++-- usb-linux.c | 25 +-- 5 files changed, 98 insertions(+), 39 deletions(-)
[Qemu-devel] [PATCH 7/7] usb-host: add usb_host_do_reset function.
Add a special function to reset the host usb device. It tracks the time
needed by the USBDEVFS_RESET ioctl and prints a warning in case it needs
too long. Usually it should be finished in 200 - 300 miliseconds.
Warning threshold is one second.
Intention is to help troubleshooting by indicating that the usb device
stopped responding even to a reset request and is possibly broken.
Signed-off-by: Gerd Hoffmann
---
usb-linux.c | 25 ++---
1 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index d4426ea..ab4c693 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -148,6 +148,25 @@ static int usb_host_read_file(char *line, size_t line_size,
const char *device_file, const char *device_name);
static int usb_linux_update_endp_table(USBHostDevice *s);
+static int usb_host_do_reset(USBHostDevice *dev)
+{
+struct timeval s, e;
+uint32_t usecs;
+int ret;
+
+gettimeofday(&s, NULL);
+ret = ioctl(dev->fd, USBDEVFS_RESET);
+gettimeofday(&e, NULL);
+usecs = (e.tv_sec - s.tv_sec) * 100;
+usecs += e.tv_usec - s.tv_usec;
+if (usecs > 100) {
+/* more than a second, something is fishy, broken usb device? */
+fprintf(stderr, "husb: device %d:%d reset took %d.%06d seconds\n",
+dev->bus_num, dev->addr, usecs / 100, usecs % 100);
+}
+return ret;
+}
+
static struct endp_data *get_endp(USBHostDevice *s, int pid, int ep)
{
struct endp_data *eps = pid == USB_TOKEN_IN ? s->ep_in : s->ep_out;
@@ -606,7 +625,7 @@ static void usb_host_handle_reset(USBDevice *dev)
trace_usb_host_reset(s->bus_num, s->addr);
-ioctl(s->fd, USBDEVFS_RESET);
+usb_host_do_reset(s);;
usb_host_claim_interfaces(s, 0);
usb_linux_update_endp_table(s);
@@ -1370,7 +1389,7 @@ static int usb_host_close(USBHostDevice *dev)
if (dev->dev.attached) {
usb_device_detach(&dev->dev);
}
-ioctl(dev->fd, USBDEVFS_RESET);
+usb_host_do_reset(dev);
close(dev->fd);
dev->fd = -1;
return 0;
@@ -1381,7 +1400,7 @@ static void usb_host_exit_notifier(struct Notifier *n,
void *data)
USBHostDevice *s = container_of(n, USBHostDevice, exit);
if (s->fd != -1) {
-ioctl(s->fd, USBDEVFS_RESET);
+usb_host_do_reset(s);;
}
}
--
1.7.1
[Qemu-devel] [PATCH 1/2] configure: Include #define name in check_define compiler error
Include the name of the #define being tested for in the compiler
error produced when a check_define test is run and fails. This
appears only in the config.log, but it does make it a little easier
to debug problems by inspecting config.log.
Signed-off-by: Peter Maydell
---
configure |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index f033438..5a35b6d 100755
--- a/configure
+++ b/configure
@@ -249,7 +249,7 @@ source_path=`cd "$source_path"; pwd`
check_define() {
cat > $TMPC <
[Qemu-devel] [PATCH 1/7] usb: make usb_create_simple catch and pass up errors.
Use qdev_init() instead of qdev_init_nofail(), usb device initialization
can fail, most common case being port and device speed mismatch. Handle
failures correctly and pass up NULL pointers then.
Also fixup usb_create_simple() callers (only one was buggy) to properly
check for NULL pointers before referncing the usb_create_simple() return
value.
Signed-off-by: Gerd Hoffmann
---
hw/usb-bt.c |3 +++
hw/usb-bus.c | 11 +--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/hw/usb-bt.c b/hw/usb-bt.c
index 529fa33..f30eec1 100644
--- a/hw/usb-bt.c
+++ b/hw/usb-bt.c
@@ -528,6 +528,9 @@ USBDevice *usb_bt_init(HCIInfo *hci)
if (!hci)
return NULL;
dev = usb_create_simple(NULL /* FIXME */, "usb-bt-dongle");
+if (!dev) {
+return NULL;
+}
s = DO_UPCAST(struct USBBtState, dev, dev);
s->dev.opaque = s;
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index 93f640d..f8b9807 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
@@ -139,10 +139,17 @@ USBDevice *usb_create(USBBus *bus, const char *name)
USBDevice *usb_create_simple(USBBus *bus, const char *name)
{
USBDevice *dev = usb_create(bus, name);
+int rc;
+
if (!dev) {
-hw_error("Failed to create USB device '%s'\n", name);
+error_report("Failed to create USB device '%s'\n", name);
+return NULL;
+}
+rc = qdev_init(&dev->qdev);
+if (rc < 0) {
+error_report("Failed to initialize USB device '%s'\n", name);
+return NULL;
}
-qdev_init_nofail(&dev->qdev);
return dev;
}
--
1.7.1
[Qemu-devel] planet-ltc.com
Preferred Domain Availability Notice: planet-ltc.com will be listed for auction in a few days. This domain might be useful for you, since you own a domain similar to this domain. To confirm interest in owning this domain, fill out the simple form here: planet-ltc.com Sincerely,Alexander 330 Franklin Road #135A Suite 186 Brentwood, TN 37027 If you do not want more of these messages, please click the link above and follow instructions at the bottom of the page Work is either fun or drudgery. It depends on your attitude. I like fun. -- Colleen C. Barrett
Re: [Qemu-devel] cannot build qemu with "--static" configure option
On 11/23/2011 04:41 PM, Mr Dash Four wrote: Hmm, this opens a huge Pandora's box for me - in my own distribution (Fedora) the "nss" package (which I have installed) provides /usr/lib64/libssl3.so, but not libssl3.a. "nss-devel" (which I also have installed) provides all the relevant /include files (headers and the like), but there is no libssl3.a there either! There is no package called "nss-devel-static" distributed by Fedora and the only ".a" files produced by compiling the nss source are libcrmf.a libnssb.a and libnssckfw.a - no libssl3.a at all. So, where do I get this? You don't. Fedora does not package static libraries. Just don't use the option on Linux, it makes (a little) sense only on Windows to get a monolithic, redistributable qemu.exe. Paolo
Re: [Qemu-devel] [PATCH v3 07/11] bonito: convert north bridge register mapping to memory API
2011/11/23 Peter Maydell
> 2011/11/22 Benoît Canet :
> > static int bonito_initfn(PCIDevice *dev)
> > {
> > PCIBonitoState *s = DO_UPCAST(PCIBonitoState, dev, dev);
> > +SysBusDevice *sysbus = sysbus_from_qdev(&dev->qdev);
>
> This looks odd. The device here is a PCIBonitoState, which
> is-a PCIDevice, which is-a DeviceState. It's not a SysBusDevice
> and merely casting doesn't make it one.
>
> I'm not sure what should be being done here, but I'm pretty
> sure this won't work...
>
It would work using memory_region_add_subregion() and get_system_memory()
but
Avi previously noticed me that using get_system_memory() in devices is wrong
because it goes against one of the goals of the memory API : avoiding
global knowledge.
I think I need Avi's advices on this one.
Re: [Qemu-devel] oprofile on qemu
> I oprofiled QEMU with some workloads, i.e. SPECjbb on Ubuntu Linux, i > see QEMU spent about 60 - 70% of the time in the code cache ( code > cache size is 256MB ). but I want to know which TB takes the most > amount of time. I doubt that it's possible to profile TB code by external tools without QEMU assistance. Probably it's easier to account individual TB timing from within QEMU, like it is now done for translation, see places marked with #ifdef CONFIG_PROFILER. With TB chaining disabled, TB execution starts with tcg_qemu_tb_exec, there's one call to it in cpu_exec(). TB may exit normally, or via longjmp, so there are two places in cpu_exec() where it must be caught. Virtual/physical mapping must also be taken care of, but it depends on your application. Thanks. -- Max
[Qemu-devel] [PATCH 5/7] usb-ehci: codestyle fixups
Signed-off-by: Gerd Hoffmann
---
hw/usb-ehci.c | 56
1 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/hw/usb-ehci.c b/hw/usb-ehci.c
index 3eea94d..2609aba 100644
--- a/hw/usb-ehci.c
+++ b/hw/usb-ehci.c
@@ -437,37 +437,37 @@ struct EHCIState {
} while(0)
static const char *ehci_state_names[] = {
-[ EST_INACTIVE ] = "INACTIVE",
-[ EST_ACTIVE ] = "ACTIVE",
-[ EST_EXECUTING ]= "EXECUTING",
-[ EST_SLEEPING ] = "SLEEPING",
-[ EST_WAITLISTHEAD ] = "WAITLISTHEAD",
-[ EST_FETCHENTRY ] = "FETCH ENTRY",
-[ EST_FETCHQH ] = "FETCH QH",
-[ EST_FETCHITD ] = "FETCH ITD",
-[ EST_ADVANCEQUEUE ] = "ADVANCEQUEUE",
-[ EST_FETCHQTD ] = "FETCH QTD",
-[ EST_EXECUTE ] = "EXECUTE",
-[ EST_WRITEBACK ]= "WRITEBACK",
-[ EST_HORIZONTALQH ] = "HORIZONTALQH",
+[EST_INACTIVE] = "INACTIVE",
+[EST_ACTIVE] = "ACTIVE",
+[EST_EXECUTING]= "EXECUTING",
+[EST_SLEEPING] = "SLEEPING",
+[EST_WAITLISTHEAD] = "WAITLISTHEAD",
+[EST_FETCHENTRY] = "FETCH ENTRY",
+[EST_FETCHQH] = "FETCH QH",
+[EST_FETCHITD] = "FETCH ITD",
+[EST_ADVANCEQUEUE] = "ADVANCEQUEUE",
+[EST_FETCHQTD] = "FETCH QTD",
+[EST_EXECUTE] = "EXECUTE",
+[EST_WRITEBACK]= "WRITEBACK",
+[EST_HORIZONTALQH] = "HORIZONTALQH",
};
static const char *ehci_mmio_names[] = {
-[ CAPLENGTH ]= "CAPLENGTH",
-[ HCIVERSION ] = "HCIVERSION",
-[ HCSPARAMS ]= "HCSPARAMS",
-[ HCCPARAMS ]= "HCCPARAMS",
-[ USBCMD ] = "USBCMD",
-[ USBSTS ] = "USBSTS",
-[ USBINTR ] = "USBINTR",
-[ FRINDEX ] = "FRINDEX",
-[ PERIODICLISTBASE ] = "P-LIST BASE",
-[ ASYNCLISTADDR ]= "A-LIST ADDR",
-[ PORTSC_BEGIN ] = "PORTSC #0",
-[ PORTSC_BEGIN + 4] = "PORTSC #1",
-[ PORTSC_BEGIN + 8] = "PORTSC #2",
-[ PORTSC_BEGIN + 12] = "PORTSC #3",
-[ CONFIGFLAG ] = "CONFIGFLAG",
+[CAPLENGTH] = "CAPLENGTH",
+[HCIVERSION]= "HCIVERSION",
+[HCSPARAMS] = "HCSPARAMS",
+[HCCPARAMS] = "HCCPARAMS",
+[USBCMD]= "USBCMD",
+[USBSTS]= "USBSTS",
+[USBINTR] = "USBINTR",
+[FRINDEX] = "FRINDEX",
+[PERIODICLISTBASE] = "P-LIST BASE",
+[ASYNCLISTADDR] = "A-LIST ADDR",
+[PORTSC_BEGIN] = "PORTSC #0",
+[PORTSC_BEGIN + 4] = "PORTSC #1",
+[PORTSC_BEGIN + 8] = "PORTSC #2",
+[PORTSC_BEGIN + 12] = "PORTSC #3",
+[CONFIGFLAG]= "CONFIGFLAG",
};
static const char *nr2str(const char **n, size_t len, uint32_t nr)
--
1.7.1
[Qemu-devel] [PATCH 6/7] usb-ehci: add register names
The mmio register name list only had the names for four port status
registers. We emulate a EHCI adapter with six ports though, the last
two ones are listed as "unknown" in traces. Fix it.
Signed-off-by: Gerd Hoffmann
---
hw/usb-ehci.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/hw/usb-ehci.c b/hw/usb-ehci.c
index 2609aba..a946e1d 100644
--- a/hw/usb-ehci.c
+++ b/hw/usb-ehci.c
@@ -467,6 +467,8 @@ static const char *ehci_mmio_names[] = {
[PORTSC_BEGIN + 4] = "PORTSC #1",
[PORTSC_BEGIN + 8] = "PORTSC #2",
[PORTSC_BEGIN + 12] = "PORTSC #3",
+[PORTSC_BEGIN + 16] = "PORTSC #4",
+[PORTSC_BEGIN + 20] = "PORTSC #5",
[CONFIGFLAG]= "CONFIGFLAG",
};
--
1.7.1
[Qemu-devel] [PATCH 2/2] configure: Print a banner comment at the top of config.log
Print a banner comment at the top of config.log identifying
when configure was run and the arguments used. This is occasionally
useful for debugging purposes.
Signed-off-by: Peter Maydell
---
configure |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/configure b/configure
index 5a35b6d..2e23650 100755
--- a/configure
+++ b/configure
@@ -20,6 +20,11 @@ TMPE="${TMPDIR1}/qemu-conf-${RANDOM}-$$-${RANDOM}.exe"
trap "rm -f $TMPC $TMPO $TMPE" EXIT INT QUIT TERM
rm -f config.log
+# Print a helpful header at the top of config.log
+echo "# QEMU configure log $(date)" >> config.log
+echo "# produced by $0 $*" >> config.log
+echo "#" >> config.log
+
compile_object() {
echo $cc $QEMU_CFLAGS -c -o $TMPO $TMPC >> config.log
$cc $QEMU_CFLAGS -c -o $TMPO $TMPC >> config.log 2>&1
--
1.7.1
[Qemu-devel] [PATCH 0/2] configure: minor improvements to config.log
Two trivial patches which make it a little easier to look at config.log
and figure out what's going on.
The next step down this road would probably be something like
test_start() {
echo "# Checking for $1..." >> config.log
}
and then lots of:
test_start "zlib"
in the relevant places.
Peter Maydell (2):
configure: Include #define name in check_define compiler error
configure: Print a banner comment at the top of config.log
configure |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
[Qemu-devel] [PATCH 3/7] usb-hub: wakeup on detach too.
When detaching devices from the usb hub we must wakeup too, otherwise the host misses the detach event. Commit 4a33a9ea06f6fbb08d8311a7cfed72975344f9ab does the same for device attach. Found by hk...@linux.vnet.ibm.com Signed-off-by: Gerd Hoffmann --- hw/usb-hub.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/hw/usb-hub.c b/hw/usb-hub.c index 3eb0f1a..5b48763 100644 --- a/hw/usb-hub.c +++ b/hw/usb-hub.c @@ -171,6 +171,8 @@ static void usb_hub_detach(USBPort *port1) USBHubState *s = port1->opaque; USBHubPort *port = &s->ports[port1->index]; +usb_wakeup(&s->dev); + /* Let upstream know the device on this port is gone */ s->dev.port->ops->child_detach(s->dev.port, port1->dev); -- 1.7.1
Re: [Qemu-devel] [PATCH v2] qcow2: Unlock during COW
Am 14.11.2011 18:55, schrieb Kevin Wolf: > Unlocking during COW allows for more parallelism. One change it requires is > that buffers are dynamically allocated instead of just using a per-image > buffer. > > While touching the code, drop the synchronous qcow2_read() function and > replace > it by a bdrv_read() call. > > Signed-off-by: Kevin Wolf This seems to break an IDE guest for me. I don't quite understand why yet, but maybe someone has an idea. hw/ide/pci.c:313: bmdma_cmd_writeb: Assertion `bm->bus->dma->aiocb == ((void *)0)' failed. Kevin
[Qemu-devel] [RFC PATCH 2/3] raw: implement raw_get_alignment
Signed-off-by: Paolo Bonzini
---
block/raw-posix.c | 65 ++--
block/raw-win32.c | 45
2 files changed, 97 insertions(+), 13 deletions(-)
diff --git a/block/raw-posix.c b/block/raw-posix.c
index 3482fc8..f6747ad 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -279,22 +279,56 @@ static int raw_open(BlockDriverState *bs, const char
*filename, int flags)
return raw_open_common(bs, filename, flags, 0);
}
-/* XXX: use host sector size if necessary with:
+static int raw_get_alignment(BlockDriverState *bs)
+{
+BDRVRawState *s = bs->opaque;
+unsigned int sector_size;
+int ret;
+
+ret = fd_open(bs);
+if (ret < 0) {
+return ret;
+}
+
+/* For block devices, try to get the actual sector size even if we
+ * do not need it, so that it can be passed down to the guest.
+ */
+#ifdef BLKSSZGET
+if (ioctl(s->fd, BLKSSZGET, §or_size)) {
+return sector size;
+}
+#endif
+#ifdef DKIOCGETBLOCKSIZE
+if (ioctl(s->fd, DKIOCGETBLOCKSIZE, §or_size)) {
+return sector_size;
+}
+#endif
#ifdef DIOCGSECTORSIZE
-{
-unsigned int sectorsize = 512;
-if (!ioctl(fd, DIOCGSECTORSIZE, §orsize) &&
-sectorsize > bufsize)
-bufsize = sectorsize;
-}
+if (ioctl(s->fd, DIOCGSECTORSIZE, §or_size)) {
+return sector_size;
+}
#endif
-#ifdef CONFIG_COCOA
-uint32_t blockSize = 512;
-if ( !ioctl( fd, DKIOCGETBLOCKSIZE, &blockSize ) && blockSize >
bufsize) {
-bufsize = blockSize;
+
+/* If we could not get the size so far, we can only guess it if
+ * the file was opened with O_DIRECT. If not, just return the
+ * minimal size.
+ *
+ * For /dev/sg devices the alignment is not really used, so return
+ * a dummy value for them too.
+ */
+if (bs->sg || !s->aligned_buf) {
+return 512;
+}
+
+for (sector_size = 512; sector_size < MAX_BLOCKSIZE; sector_size <<= 1) {
+/* The buffer must be aligned to sector_size, but not sector_size*2.
*/
+if (pread(s->fd, s->aligned_buf + sector_size, sector_size, 0) >= 0) {
+break;
}
-#endif
-*/
+}
+return sector_size;
+}
+
/*
* Check if all memory in this vector is sector aligned.
@@ -642,6 +676,7 @@ static BlockDriver bdrv_file = {
.bdrv_truncate = raw_truncate,
.bdrv_getlength = raw_getlength,
+.bdrv_get_alignment = raw_get_alignment,
.bdrv_get_allocated_file_size
= raw_get_allocated_file_size,
@@ -910,6 +945,7 @@ static BlockDriver bdrv_host_device = {
.bdrv_truncate = raw_truncate,
.bdrv_getlength= raw_getlength,
+.bdrv_get_alignment = raw_get_alignment,
.bdrv_get_allocated_file_size
= raw_get_allocated_file_size,
@@ -1029,6 +1065,7 @@ static BlockDriver bdrv_host_floppy = {
.bdrv_truncate = raw_truncate,
.bdrv_getlength= raw_getlength,
+.bdrv_get_alignment = raw_get_alignment,
.bdrv_get_allocated_file_size
= raw_get_allocated_file_size,
@@ -1128,6 +1165,7 @@ static BlockDriver bdrv_host_cdrom = {
.bdrv_truncate = raw_truncate,
.bdrv_getlength = raw_getlength,
+.bdrv_get_alignment = raw_get_alignment,
.bdrv_get_allocated_file_size
= raw_get_allocated_file_size,
@@ -1247,6 +1285,7 @@ static BlockDriver bdrv_host_cdrom = {
.bdrv_truncate = raw_truncate,
.bdrv_getlength = raw_getlength,
+.bdrv_get_alignment = raw_get_alignment,
.bdrv_get_allocated_file_size
= raw_get_allocated_file_size,
diff --git a/block/raw-win32.c b/block/raw-win32.c
index e4b0b75..f033037 100644
--- a/block/raw-win32.c
+++ b/block/raw-win32.c
@@ -96,6 +96,18 @@ static int raw_open(BlockDriverState *bs, const char
*filename, int flags)
overlapped |= FILE_FLAG_NO_BUFFERING;
if (!(flags & BDRV_O_CACHE_WB))
overlapped |= FILE_FLAG_WRITE_THROUGH;
+
+if (filename[0] && filename[1] == ':') {
+snprintf(s->drive_path, sizeof(s->drive_path), "%c:\\", filename[0]);
+} else if (filename[0] == '\\' && filename[1] == '\\') {
+s->drive_path[0] = 0;
+} else {
+/* Relative path. */
+char buf[MAX_PATH];
+GetCurrentDirectory(MAX_PATH, buf);
+snprintf(s->drive_path, sizeof(s->drive_path), "%c:\\", buf[0]);
+}
+
s->hfile = CreateFile(filename, access_flags,
FILE_SHARE_READ, NULL,
OPEN_EXISTING, overlapped, NULL);
@@ -184,6 +196,37 @@ static int raw_truncate(BlockDriverState *bs, int64_t
offset)
return 0;
}
+static int raw_get_alignment(BlockDriverState *bs)
+{
+BDRVRawState *s = bs->opaque;
+DWORD sectorsPerCluster, freeClusters, totalClusters, count;
+
[Qemu-devel] [RFC PATCH 3/3] block: do not rely on the buffer alignment passed to the guest
The guest alignment should not override the host's. Instead, just use
the bdrv_set_buffer_alignment calls to print a warning about possible
performance degradations due to insufficiently-aligned guest buffers.
Signed-off-by: Paolo Bonzini
---
block.c |8 ++--
block.h |2 +-
hw/ide/core.c |2 +-
hw/scsi-disk.c|2 +-
hw/scsi-generic.c |1 -
hw/virtio-blk.c |2 +-
6 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/block.c b/block.c
index aba92ad..cd11344 100644
--- a/block.c
+++ b/block.c
@@ -3039,9 +3039,13 @@ BlockDriverAIOCB *bdrv_aio_ioctl(BlockDriverState *bs,
return NULL;
}
-void bdrv_set_buffer_alignment(BlockDriverState *bs, int align)
+void bdrv_check_buffer_alignment(BlockDriverState *bs, int align)
{
-bs->buffer_alignment = align;
+if ((bs->open_flags & BDRV_O_NOCACHE) && bdrv_get_alignment(bs) > align) {
+error_report("Host block size is %d, guest block size is %d.\n"
+"cache=none may cause performance degradation.",
+bdrv_get_alignment(bs), align);
+}
}
void *qemu_blockalign(BlockDriverState *bs, size_t size)
diff --git a/block.h b/block.h
index 5fa632c..386284c 100644
--- a/block.h
+++ b/block.h
@@ -295,7 +295,7 @@ int bdrv_img_create(const char *filename, const char *fmt,
char *options, uint64_t img_size, int flags);
int bdrv_get_alignment(BlockDriverState *bs);
-void bdrv_set_buffer_alignment(BlockDriverState *bs, int align);
+void bdrv_check_buffer_alignment(BlockDriverState *bs, int align);
void *qemu_blockalign(BlockDriverState *bs, size_t size);
#define BDRV_SECTORS_PER_DIRTY_CHUNK 2048
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 93a1a68..3b8cdb2 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -1863,7 +1863,7 @@ int ide_init_drive(IDEState *s, BlockDriverState *bs,
IDEDriveKind kind,
s->smart_selftest_count = 0;
if (kind == IDE_CD) {
bdrv_set_dev_ops(bs, &ide_cd_block_ops, s);
-bdrv_set_buffer_alignment(bs, 2048);
+bdrv_check_buffer_alignment(bs, 2048);
} else {
if (!bdrv_is_inserted(s->bs)) {
error_report("Device needs media, but drive is empty");
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 673948c..946d670 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -1553,7 +1553,7 @@ static int scsi_initfn(SCSIDevice *dev)
if (s->removable) {
bdrv_set_dev_ops(s->qdev.conf.bs, &scsi_cd_block_ops, s);
}
-bdrv_set_buffer_alignment(s->qdev.conf.bs, s->qdev.blocksize);
+bdrv_check_buffer_alignment(s->qdev.conf.bs, s->qdev.blocksize);
bdrv_iostatus_enable(s->qdev.conf.bs);
add_boot_device_path(s->qdev.conf.bootindex, &dev->qdev, NULL);
diff --git a/hw/scsi-generic.c b/hw/scsi-generic.c
index 9594cc1..c681a37 100644
--- a/hw/scsi-generic.c
+++ b/hw/scsi-generic.c
@@ -188,7 +188,6 @@ static void scsi_read_complete(void * opaque, int ret)
s->blocksize = ldl_be_p(&r->buf[8]);
s->max_lba = ldq_be_p(&r->buf[0]);
}
-bdrv_set_buffer_alignment(s->conf.bs, s->blocksize);
scsi_req_data(&r->req, len);
if (!r->req.io_canceled) {
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 91c92b2..ddc8b15 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -624,7 +624,7 @@ VirtIODevice *virtio_blk_init(DeviceState *dev, BlockConf
*conf,
register_savevm(dev, "virtio-blk", virtio_blk_id++, 2,
virtio_blk_save, virtio_blk_load, s);
bdrv_set_dev_ops(s->bs, &virtio_block_ops, s);
-bdrv_set_buffer_alignment(s->bs, conf->logical_block_size);
+bdrv_check_buffer_alignment(s->bs, conf->logical_block_size);
bdrv_iostatus_enable(s->bs);
add_boot_device_path(conf->bootindex, dev, "/disk@0,0");
--
1.7.7.1
[Qemu-devel] [RFC PATCH 1/3] block: add bdrv_get_alignment, use it
We cannot simply use the guest logical block size on the host; we need
to ask the protocol driver about the minimum required alignment.
Signed-off-by: Paolo Bonzini
---
block.c | 26 --
block.h |1 +
block/raw-posix.c |3 ++-
block_int.h |1 +
4 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/block.c b/block.c
index d015887..aba92ad 100644
--- a/block.c
+++ b/block.c
@@ -476,7 +476,7 @@ static int bdrv_open_common(BlockDriverState *bs, const
char *filename,
bs->sg = 0;
bs->open_flags = flags;
bs->growable = 0;
-bs->buffer_alignment = 512;
+bs->buffer_alignment = 0;
pstrcpy(bs->filename, sizeof(bs->filename), filename);
bs->backing_file[0] = '\0';
@@ -1361,6 +1361,27 @@ int64_t bdrv_get_allocated_file_size(BlockDriverState
*bs)
}
/**
+ * Required buffer alignment for a file or device. Return < 0 if error or
unknown.
+ */
+int bdrv_get_alignment(BlockDriverState *bs)
+{
+BlockDriver *drv = bs->drv;
+if (!drv) {
+return -ENOMEDIUM;
+}
+if (bs->buffer_alignment == 0) {
+if (drv->bdrv_get_alignment) {
+bs->buffer_alignment = drv->bdrv_get_alignment(bs);
+} else if (bs->file) {
+bs->buffer_alignment = bdrv_get_alignment(bs->file);
+} else {
+bs->buffer_alignment = BDRV_SECTOR_SIZE;
+}
+}
+return bs->buffer_alignment;
+}
+
+/**
* Length of a file in bytes. Return < 0 if error or unknown.
*/
int64_t bdrv_getlength(BlockDriverState *bs)
@@ -3025,7 +3046,8 @@ void bdrv_set_buffer_alignment(BlockDriverState *bs, int
align)
void *qemu_blockalign(BlockDriverState *bs, size_t size)
{
-return qemu_memalign((bs && bs->buffer_alignment) ? bs->buffer_alignment :
512, size);
+int alignment = bs ? bdrv_get_alignment(bs) : 512;
+return qemu_memalign(alignment, size);
}
void bdrv_set_dirty_tracking(BlockDriverState *bs, int enable)
diff --git a/block.h b/block.h
index a826059..5fa632c 100644
--- a/block.h
+++ b/block.h
@@ -294,6 +294,7 @@ int bdrv_img_create(const char *filename, const char *fmt,
const char *base_filename, const char *base_fmt,
char *options, uint64_t img_size, int flags);
+int bdrv_get_alignment(BlockDriverState *bs);
void bdrv_set_buffer_alignment(BlockDriverState *bs, int align);
void *qemu_blockalign(BlockDriverState *bs, size_t size);
diff --git a/block/raw-posix.c b/block/raw-posix.c
index a3de373..3482fc8 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -301,10 +301,11 @@ static int raw_open(BlockDriverState *bs, const char
*filename, int flags)
*/
static int qiov_is_aligned(BlockDriverState *bs, QEMUIOVector *qiov)
{
+int alignment = bdrv_get_alignment(bs);
int i;
for (i = 0; i < qiov->niov; i++) {
-if ((uintptr_t) qiov->iov[i].iov_base % bs->buffer_alignment) {
+if ((uintptr_t) qiov->iov[i].iov_base % alignment) {
return 0;
}
}
diff --git a/block_int.h b/block_int.h
index 77c0187..6caf063 100644
--- a/block_int.h
+++ b/block_int.h
@@ -113,6 +113,7 @@ struct BlockDriver {
const char *protocol_name;
int (*bdrv_truncate)(BlockDriverState *bs, int64_t offset);
+int (*bdrv_get_alignment)(BlockDriverState *bs);
int64_t (*bdrv_getlength)(BlockDriverState *bs);
int64_t (*bdrv_get_allocated_file_size)(BlockDriverState *bs);
int (*bdrv_write_compressed)(BlockDriverState *bs, int64_t sector_num,
--
1.7.7.1
[Qemu-devel] [RFC PATCH 0/3] block: add support for 4k logical blocks
This series adds support for 4k logical blocks by bouncing requests unless the host's logical_block_size is also 4096. Paolo Bonzini (3): block: add bdrv_get_alignment, use it raw: implement raw_get_alignment block: do not rely on the buffer alignment passed to the guest block.c | 34 +++--- block.h |3 +- block/raw-posix.c | 68 ++--- block/raw-win32.c | 45 +++ block_int.h |1 + hw/ide/core.c |2 +- hw/scsi-disk.c|2 +- hw/scsi-generic.c |1 - hw/virtio-blk.c |2 +- 9 files changed, 135 insertions(+), 23 deletions(-) -- 1.7.7.1
[Qemu-devel] [PATCH 8/8] vmstate: Add copyright info for sparc processor
v2: Move license to BSD-like as in vl.c
Signed-off-by: Juan Quintela
---
target-sparc/vmstate-cpu.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/target-sparc/vmstate-cpu.c b/target-sparc/vmstate-cpu.c
index 259db19..c74ea9a 100644
--- a/target-sparc/vmstate-cpu.c
+++ b/target-sparc/vmstate-cpu.c
@@ -1,3 +1,32 @@
+/*
+ * Migration support for sparc cpu
+ *
+ * Copyright (c) 2003-2008 Fabrice Bellard
+ * Copyright (c) 2003-2011 Blue Swirl
+ * Copyright (c) 2011 Red Hat, Inc.
+ *
+ * Author(s):
+ * Juan Quintela
+ *
+ * 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 "hw/hw.h"
static const VMStateDescription vmstate_cpu_timer = {
--
1.7.7.1
Re: [Qemu-devel] oprofile on qemu
I oprofiled QEMU with some workloads, i.e. SPECjbb on Ubuntu Linux, i see QEMU spent about 60 - 70% of the time in the code cache ( code cache size is 256MB ). but I want to know which TB takes the most amount of time. Thanks Xin On Wed, Nov 23, 2011 at 3:10 AM, 陳韋任 wrote: > On Tue, Nov 22, 2011 at 08:23:32AM -0500, Xin Tong wrote: >> Is there a way to profile QEMU's code cache ? > > What do you try to profile? The execution time in the code > cache? > > P.S. The subject is a little misleading. Oprofile is a tool. > Do you specify you want use Oprofile only? > > 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 >
[Qemu-devel] [PATCH 2/8] vmstate: Add copyright info for lm32 processor
Signed-off-by: Juan Quintela
Acked-By: Michael Walle
---
target-lm32/vmstate-cpu.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/target-lm32/vmstate-cpu.c b/target-lm32/vmstate-cpu.c
index 60b4b29..27e09d2 100644
--- a/target-lm32/vmstate-cpu.c
+++ b/target-lm32/vmstate-cpu.c
@@ -1,3 +1,18 @@
+/*
+ * Migration support for lm32 cpus
+ *
+ * Copyright (C) 2011 Red Hat, Inc.
+ *
+ * Author(s):
+ * Juan Quintela
+ *
+ * Based on qemu-file support done by:
+ * Michael Walle
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * later. See the COPYING file in the top-level directory.
+ */
+
#include "hw/hw.h"
const VMStateDescription vmstate_cpu = {
--
1.7.7.1
Re: [Qemu-devel] [PATCH v2] cow: use bdrv_co_is_allocated()
Am 23.11.2011 16:00, schrieb Stefan Hajnoczi: > Now that bdrv_co_is_allocated() is available we can use it instead of > the synchronous bdrv_is_allocated() interface. This is a follow-up that > Kevin Wolf pointed out after applying the series that > introduces bdrv_co_is_allocated(). > > It is safe to make cow_read() a coroutine_fn because its only caller is > a coroutine_fn. > > Signed-off-by: Stefan Hajnoczi Thanks, applied to the block branch (for 1.1) Kevin
Re: [Qemu-devel] [libvirt] virDomainBlockJobAbort and block_job_cancel
On 11/23/2011 07:48 AM, Stefan Hajnoczi wrote: > This means that virDomainBlockJobAbort() returns to the client without > a guarantee that the job has completed. If the client enumerates jobs > it may still see a job that has not finished cancelling. The client > must register a handler for the BLOCK_JOB_CANCELLED event if it wants > to know when the job really goes away. The BLOCK_JOB_CANCELLED event > has the same fields as the BLOCK_JOB_COMPLETED event, except it lacks > the optional "error" message field. > > The impact on clients is that they need to add a BLOCK_JOB_CANCELLED > handler if they really want to wait. Most clients today (not many > exist) will be fine without waiting for cancellation. > > Any objections or thoughts on this? virDomainBlockJobAbort() thankfully has an 'unsigned int flags' argument. For backwards-compatibility, I suggest we use it: calling virDomainBlockJobAbort(,0) maintains old blocking behavior, and we document that blocking until things abort may render the rest of interactions with the domain unresponsive. The new virDomainBlockJobAbort(,VIR_DOMAIN_BLOCK_JOB_ABORT_ASYNC) would then implement your new proposed semantics of returning immediately once the cancellation has been requested, even if it hasn't been acted on yet. Maybe you could convince me to swap the flags: have 0 change semantics to non-blocking, and a new flag to request blocking, where callers that care have to try the flag, and if the flag is unsupported then they know they are talking to older libvirtd where the behavior is blocking by default, but that's a bit riskier. -- 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 v2] Support for UDP unicast network backend
Signed-off-by: Benjamin MARSILI
---
net.c |6 -
net/socket.c| 71
+-
qemu-options.hx |2 +
3 files changed, 76 insertions(+), 3 deletions(-)
diff --git a/net.c b/net.c
index cb52050..8e957b2 100644
--- a/net.c
+++ b/net.c
@@ -999,7 +999,11 @@ static const struct {
}, {
.name = "localaddr",
.type = QEMU_OPT_STRING,
-.help = "source address for multicast packets",
+.help = "source address and port for multicast and udp
packets",
+}, {
+.name = "udp",
+.type = QEMU_OPT_STRING,
+.help = "UDP unicast address and port number",
},
{ /* end of list */ }
},
diff --git a/net/socket.c b/net/socket.c
index e9ef128..ca183f2 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -524,6 +524,55 @@ static int net_socket_mcast_init(VLANState *vlan,
}
+static int net_socket_udp_init(VLANState *vlan,
+ const char *model,
+ const char *name,
+ const char *rhost,
+ const char *lhost)
+{
+NetSocketState *s;
+int fd, val, ret;
+struct sockaddr_in laddr, raddr;
+
+if (parse_host_port(&laddr, lhost) < 0) {
+return -1;
+}
+
+if (parse_host_port(&raddr, rhost) < 0) {
+return -1;
+}
+
+fd = qemu_socket(PF_INET, SOCK_DGRAM, 0);
+if (fd < 0) {
+perror("socket(PF_INET, SOCK_DGRAM)");
+return -1;
+}
+val = 1;
+ret = setsockopt(fd, SOL_SOCKET, SO_REUSEADDR,
+ (const char *)&val, sizeof(val));
+if (ret < 0) {
+perror("setsockopt(SOL_SOCKET, SO_REUSEADDR)");
+return -1;
+}
+ret = bind(fd, (struct sockaddr *)&laddr, sizeof(laddr));
+if (ret < 0) {
+perror("bind");
+return -1;
+}
+
+s = net_socket_fd_init(vlan, model, name, fd, 0);
+if (!s) {
+return -1;
+}
+
+s->dgram_dst = raddr;
+
+snprintf(s->nc.info_str, sizeof(s->nc.info_str),
+ "socket: udp=%s:%d",
+ inet_ntoa(raddr.sin_addr), ntohs(raddr.sin_port));
+return 0;
+}
+
int net_init_socket(QemuOpts *opts,
Monitor *mon,
const char *name,
@@ -597,10 +646,28 @@ int net_init_socket(QemuOpts *opts,
if (net_socket_mcast_init(vlan, "socket", name, mcast,
localaddr) == -1) {
return -1;
}
+} else if (qemu_opt_get(opts, "udp")) {
+const char *udp, *localaddr;
+
+if (qemu_opt_get(opts, "fd") ||
+qemu_opt_get(opts, "connect") ||
+qemu_opt_get(opts, "listen") ||
+qemu_opt_get(opts, "mcast")) {
+error_report("fd=, connect=, listen=\
+ and mcast= is invalid with udp=");
+return -1;
+}
+
+udp = qemu_opt_get(opts, "udp");
+localaddr = qemu_opt_get(opts, "localaddr");
+
+if (net_socket_udp_init(vlan, "udp", name, udp, localaddr) == -1) {
+return -1;
+}
} else {
-error_report("-socket requires fd=, listen=, connect= or mcast=");
+error_report("-socket requires fd=, listen=, \
+ connect=, mcast= or udp=");
return -1;
}
-
return 0;
}
diff --git a/qemu-options.hx b/qemu-options.hx
index 681eaf1..5495368 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1217,6 +1217,8 @@ DEF("net", HAS_ARG, QEMU_OPTION_net,
"-net
socket[,vlan=n][,name=str][,fd=h][,mcast=maddr:port[,localaddr=addr]]\n"
"connect the vlan 'n' to multicast maddr and port\n"
"use 'localaddr=addr' to specify the host address
to send packets from\n"
+"-net
socket[,vlan=n][,name=str][,fd=h][,udp=host:port][,localaddr=host:port]\n"
+"connect the vlan 'n' to another VLAN using an UDP
tunnel\n"
#ifdef CONFIG_VDE
"-net
vde[,vlan=n][,name=str][,sock=socketpath][,port=n][,group=groupname][,mode=octalmode]\n"
"connect the vlan 'n' to port 'n' of a vde switch
running\n"
--
1.7.3.5
Is this better? Sent the patch by hand since I didn't configure my mail
client yet. Will do for the next patches.
Thanks for your help,
Benjamin
Re: [Qemu-devel] husb: out of buffers for iso stream
On 11/19/11 20:40, Stefan Hajnoczi wrote: > I have a Windows 7 VM running a sound driver for a passthrough USB > host device. The driver submits iso in and out urbs to do audio > capture and playback at the same time. > > Audacity running inside the guest freezes and does not record audio > unless I move the mouse. Somehow it seems USB iso urbs aren't being > pumped unless I keep moving the mouse. The VM is using VNC. I have no idea how moving the mouse could possibly help here. > Checking the QEMU stderr logs I see many occurrences of "husb: out of > buffers for iso stream". Perhaps this message is enough to pinpoint > the problem? It means the number of buffers in flight (on the host side) went down to zero, i.e. the stream is interrupted. usb-host maintains a set of buffers (four by default) per iso endpoint to keep the constant data flow up, i.e. pass one buffer to the guest while the host fills the next one. Now the host has no more buffers to fill. Most likely usb-host sits on a bunch of full buffers which it hasn't passed to the guest yet. For starter try a higher number of buffers (isobufs property). Also make sure you enable the vnc thread (unless you have already). cheers, Gerd
[Qemu-devel] [Bug 894037] [NEW] With VNC, "-usbdevice tablet" no longer makes mouse pointers line up
Public bug reported: I use qemu in VNC mode. In order to get the client and server mouse pointers to line up, I've had to use the "-usbdevice tablet" option. This no longer works, and it behaves the same as if the option is not there. This makes my VMs unusable to me. Here's how I'm booting WinXP: qemu-system-x86_64 -vga std -drive cache=writeback,index=0,media=disk,file=winxp.img -k en-us -m 2048 -smp 2 -vnc :3101 -usbdevice tablet -boot c -enable-kvm & The Windows install hasn't changed, only qemu. I'm running this version of QEMU: QEMU emulator version 0.15.0 (qemu-kvm-0.15.0), Copyright (c) 2003-2008 Fabrice Bellard I'll see about upgrading to 0.15.1, but since I haven't seen other reports of this particular problem in your DB, I'm assuming that this problem has not been fixed between 0.15.0 and 0.15.1. ** 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/894037 Title: With VNC, "-usbdevice tablet" no longer makes mouse pointers line up Status in QEMU: New Bug description: I use qemu in VNC mode. In order to get the client and server mouse pointers to line up, I've had to use the "-usbdevice tablet" option. This no longer works, and it behaves the same as if the option is not there. This makes my VMs unusable to me. Here's how I'm booting WinXP: qemu-system-x86_64 -vga std -drive cache=writeback,index=0,media=disk,file=winxp.img -k en-us -m 2048 -smp 2 -vnc :3101 -usbdevice tablet -boot c -enable-kvm & The Windows install hasn't changed, only qemu. I'm running this version of QEMU: QEMU emulator version 0.15.0 (qemu-kvm-0.15.0), Copyright (c) 2003-2008 Fabrice Bellard I'll see about upgrading to 0.15.1, but since I haven't seen other reports of this particular problem in your DB, I'm assuming that this problem has not been fixed between 0.15.0 and 0.15.1. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/894037/+subscriptions
Re: [Qemu-devel] [RFC PATCH 0/2] Fix migration with NFS & iscsi/Fiber channel
Juan Quintela wrote: Hi I did the stupid thing, and send the wrong directory of patches, sorry for any inconveniences. /me writes 100 times: I have to re-read the whole command line before sending patches /me writes another 100 times Later, Juan.
[Qemu-devel] [PATCH 7/8] vmstate: Add copyright info for ppc processor
v2: Move license to BSD-like as in vl.c
Signed-off-by: Juan Quintela
---
target-ppc/vmstate-cpu.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/target-ppc/vmstate-cpu.c b/target-ppc/vmstate-cpu.c
index 1664d32..9e36a18 100644
--- a/target-ppc/vmstate-cpu.c
+++ b/target-ppc/vmstate-cpu.c
@@ -1,3 +1,31 @@
+/*
+ * Migration support for ppc cpu
+ *
+ * Copyright (c) 2003-2011 Blue Swirl
+ * Copyright (c) 2011 Red Hat, Inc.
+ *
+ * Author(s):
+ * Juan Quintela
+ *
+ * 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 "hw/hw.h"
static const VMStateDescription vmstate_tlb = {
--
1.7.7.1
[Qemu-devel] [PATCH 5/8] vmstate: Add copyright info for i386 processor
v2: Move license to BSD-like as in vl.c
Add Fabrice copyright from vl.c
Signed-off-by: Juan Quintela
---
target-i386/vmstate-cpu.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/target-i386/vmstate-cpu.c b/target-i386/vmstate-cpu.c
index 838983e..442a1f0 100644
--- a/target-i386/vmstate-cpu.c
+++ b/target-i386/vmstate-cpu.c
@@ -1,3 +1,31 @@
+/*
+ * Migration support for x86 cpu
+ *
+ * Copyright (c) 2003-2008 Fabrice Bellard
+ * Copyright (c) 2011 Red Hat, Inc.
+ *
+ * Author(s):
+ * Juan Quintela
+ *
+ * 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 "hw/hw.h"
static const VMStateDescription vmstate_segment = {
--
1.7.7.1
[Qemu-devel] [PATCH 6/8] vmstate: Add copyright info for mips processor
v2: Move license to BSD-like as in vl.c
Signed-off-by: Juan Quintela
---
target-mips/vmstate-cpu.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/target-mips/vmstate-cpu.c b/target-mips/vmstate-cpu.c
index d6d7830..f709cf2 100644
--- a/target-mips/vmstate-cpu.c
+++ b/target-mips/vmstate-cpu.c
@@ -1,3 +1,32 @@
+/*
+ * Migration support for mips cpu
+ *
+ * Copyright (c) 2003-2008 Fabrice Bellard
+ * Copyright (c) 2003-2008 Thiemo Seufer
+ * Copyright (c) 2011 Red Hat, Inc.
+ *
+ * Author(s):
+ * Juan Quintela
+ *
+ * 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 "hw/hw.h"
static const VMStateDescription vmstate_tc = {
--
1.7.7.1
[Qemu-devel] [PATCH 4/8] vmstate: Add copyright info for arm processor
Signed-off-by: Juan Quintela Acked-by: Andrzej Zaborowski --- target-arm/vmstate-cpu.c | 15 +++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/target-arm/vmstate-cpu.c b/target-arm/vmstate-cpu.c index 836d9ed..bc48434 100644 --- a/target-arm/vmstate-cpu.c +++ b/target-arm/vmstate-cpu.c @@ -1,3 +1,18 @@ +/* + * Migration support for arm cpus + * + * Copyright (C) 2011 Red Hat, Inc. + * + * Author(s): + * Juan Quintela + * + * Based on qemu-file support done by: + * Andrzej Zaborowski + * + * This work is licensed under the terms of the GNU GPL, version 2 or + * later. See the COPYING file in the top-level directory. + */ + #include "hw/hw.h" static bool feature_vfp_needed(void *opaque) -- 1.7.7.1
[Qemu-devel] [PATCH 1/8] vmstate: Add copyright info for alpha processor
Signed-off-by: Juan Quintela Acked-by: Richard Henderson --- target-alpha/vmstate-cpu.c | 15 +++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/target-alpha/vmstate-cpu.c b/target-alpha/vmstate-cpu.c index 156cb74..9d4b065 100644 --- a/target-alpha/vmstate-cpu.c +++ b/target-alpha/vmstate-cpu.c @@ -1,3 +1,18 @@ +/* + * Migration support for alpha cpus + * + * Copyright (C) 2011 Red Hat, Inc. + * + * Author(s): + * Juan Quintela + * + * Based on qemu-file support done by: + * Richard Henderson + * + * This work is licensed under the terms of the GNU GPL, version 2 or + * later. See the COPYING file in the top-level directory. + */ + #include "hw/hw.h" static int get_fpcr(QEMUFile *f, void *opaque, size_t size) -- 1.7.7.1
[Qemu-devel] [PATCH 3/8] vmstate: Add copyright info for cris processor
Signed-off-by: Juan Quintela
Acked-by: Edgar E. Iglesias
---
target-cris/vmstate-cpu.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/target-cris/vmstate-cpu.c b/target-cris/vmstate-cpu.c
index 0f732d3..f062272 100644
--- a/target-cris/vmstate-cpu.c
+++ b/target-cris/vmstate-cpu.c
@@ -1,3 +1,18 @@
+/*
+ * Migration support for cris cpus
+ *
+ * Copyright (C) 2011 Red Hat, Inc.
+ *
+ * Author(s):
+ * Juan Quintela
+ *
+ * Based on qemu-file support done by:
+ * Edgar E. Iglesias
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * later. See the COPYING file in the top-level directory.
+ */
+
#include "hw/hw.h"
static const VMStateDescription vmstate_tlbset = {
--
1.7.7.1
[Qemu-devel] [PATCH v2 0/8] [RFC] vmstate: Add copyrights for all cpus
Hi [ Resnd this time also ading fabrice address, sorry ] v2: - split patches by file, make easier to add "acked-by" notices. - cc'd fabrice - everybody (except for Thiemo for ovbious reasons) answered. - move ppc/sparc/i386 to BSD like license from vl.c at Blue suggestion. - move all other licenses to GPL v2 or later (notice that I had forget the later part on the 1st submission). Notice this change for the people that acked previous version. Any other comments? v1: This patch adds copyrights to all the machine description files for all architectures supported. (this is done on top of my vmstate-cpus series patches) The problem? - What should we put as "copyirght" owners. Althought I modified almost every line of the files, mostly of the changes are a conversion, so claiming myself as the only "copyright" owner sounds at least pretentious, and more than probably false. I tried to "dig" into the git logs and tried to came with "whoever" commit the initial cpu_save/load foar each architecture. I have put them as: * Based on qemu-file support done by: * Richard Henderson But I would preffer that the persons involved state what copyright notice they want, name, address, year(s), etc. (Some architectures already have a propper copyright notice, I didn't touch them), and others had an empty file (I put mine there on the previosu series). Several of the logs are from the svn days, and then I don't know if the person was the committer, or the author. If anyone contributed to the functionality and want to add its copyright, please told me. To make things more complicated, when machine.c files were split from vl.c, they didn't carry any copyright notice at all, should we copy back everything from vl.c? To make things more complicated, it looks like Thiemo Seufer did the original mips support, and he passed away. So he can't obviously comment. Anthony asked me to send a patch to the list, asking form comments. alpha: CC: Richard Henderson arm: CC: Andrzej Zaborowski (it appears as balrog, but on irc channel peter told me that balrog has him) cris: CC: Edgar E. Iglesias i386: Fabrice Bellard? * Copyright (c) 2003-2008 Fabrice Bellard Didn't cc'd him because he left project/didn't have email address on MAINTAINERS/vl.c. If you think that I should cc'd to him, just let me know. lm32: CC: Michael Walle mips: Thiemo Seufer? ppc & sparc: CC: Blue Swirl What do you think, what should we do? Juan. *** BLURB HERE *** Juan Quintela (8): vmstate: Add copyright info for alpha processor vmstate: Add copyright info for lm32 processor vmstate: Add copyright info for cris processor vmstate: Add copyright info for arm processor vmstate: Add copyright info for i386 processor vmstate: Add copyright info for mips processor vmstate: Add copyright info for ppc processor vmstate: Add copyright info for sparc processor target-alpha/vmstate-cpu.c | 15 +++ target-arm/vmstate-cpu.c | 15 +++ target-cris/vmstate-cpu.c | 15 +++ target-i386/vmstate-cpu.c | 28 target-lm32/vmstate-cpu.c | 15 +++ target-mips/vmstate-cpu.c | 29 + target-ppc/vmstate-cpu.c | 28 target-sparc/vmstate-cpu.c | 29 + 8 files changed, 174 insertions(+), 0 deletions(-) -- 1.7.7.1
Re: [Qemu-devel] cannot build qemu with "--static" configure option
Perhaps you lack a static version of the library. What do you mean by that? The *.la files? I wasn't aware that there are any... I mean lib*.a files. They are needed if you specify static, by definition. Hmm, this opens a huge Pandora's box for me - in my own distribution (Fedora) the "nss" package (which I have installed) provides /usr/lib64/libssl3.so, but not libssl3.a. "nss-devel" (which I also have installed) provides all the relevant /include files (headers and the like), but there is no libssl3.a there either! There is no package called "nss-devel-static" distributed by Fedora and the only ".a" files produced by compiling the nss source are libcrmf.a libnssb.a and libnssckfw.a - no libssl3.a at all. So, where do I get this? Also, assuming libssl3 is not the only one, ld will probably complain that there are other ".a" files missing from various other packages which are probably not present in my host machine. If that is the case, this is an absolute nightmare to have to deal with! Where do I get these files? Thanks for your input Paolo.
Re: [Qemu-devel] MMU address collision.
Hi all, I have a question regarding MMU. I've built SPARC based small embedded system. at this system addresses *0x-0x8000* (32KB) belong to ROM and *0x8000 - 0x80001000* to HW devices. the problem is that when a code from first ROM page accesses a HW device register there is an infinite loop. - cpu_sparc_handle_mmu_fault is called to bring page 0 - cpu_sparc_handle_mmu_fault is called to bring 0x8000 and flushes 0x - cpu_sparc_handle_mmu_fault is called to bring 0x and flushes 0x8000 ... this can be fixed if I set CPU_TLB_BITS to be 20 bits. is there a better solution? Michael
[Qemu-devel] MMU address collision.
Hi all, I have a question regarding MMU. I've built SPARC based small embedded system. at this system addresses *0x-0x8000* (32KB) belong to ROM and *0x8000 - 0x80001000* to HW devices. the problem is that when a code from first ROM page accesses a HW device register there is an infinite loop. -- Best Regards, Michael Rolnik
Re: [Qemu-devel] cannot build qemu with "--static" configure option
On 11/23/2011 03:15 PM, Mr Dash Four wrote: It would indicate a missing libssl3, but the library, as far as I can see, is there! When I try building this without the "--static" option all is well - the build succeeds without any hitches. What could be the problem with this, what am I missing? Perhaps you lack a static version of the library. What do you mean by that? The *.la files? I wasn't aware that there are any... I mean lib*.a files. They are needed if you specify static, by definition. Paolo
Re: [Qemu-devel] [PATCH 1.0] 9pfs: improve portability to older systems
On 11/23/2011 04:11 PM, Aneesh Kumar K.V wrote: > > virtio-9p-handle.c is only for recent Linux and you can assume the ioctl > is defined there. But the file gets build by default right ? ie, we would build virtio-9p-handle.c and if FS_IOC_GETVERSION is not defined, build will fail right ? I think you're right. Strange that Erik did not see it. Paolo
Re: [Qemu-devel] [PATCH 1.0] 9pfs: improve portability to older systems
On Wed, 23 Nov 2011 08:24:53 +0100, Paolo Bonzini wrote: > On 11/23/2011 07:16 AM, Aneesh Kumar K.V wrote: > > We would also require same changes for virtio-9p-handle.c right ? > > virtio-9p-handle.c is only for recent Linux and you can assume the ioctl > is defined there. But the file gets build by default right ? ie, we would build virtio-9p-handle.c and if FS_IOC_GETVERSION is not defined, build will fail right ? -aneesh
Re: [Qemu-devel] [RFC PATCH] Exporting Guest RAM information for NUMA binding
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". 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. I doubt that the assumption that all cloud nodes will have the same physical numa topology is reasonable. 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). I think it's unreasonable to expect all applications to use ms_mbind/ms_tbind in the guest, at best guest apps will use cpusets or wrappers, few apps will be modified for sys_ms_tbind/mbind. You can always have the supercomputer case with just one app that is optimized and a single VM spanning over the whole host, but in that scenarios hard bindings would work perfectly too. 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. Now dealing with bindings isn't big deal for qemu, in fact this API is pretty much ideal for qemu, but it won't make life substantially easier than if compared to hard bindings. Simply the management code that is now done with a perl script will have to be moved in the kernel. It looks an incremental improvement compared to the relative mbind+cpuset, but I'm unsure if it's the best we could aim for and what we really need in virt considering we deal with VM migration too. The real long term design to me is not to add more syscalls, and initially handling the case of a process/VM spanning not more than one node in thread number and amount of memory. That's not too hard an in fact I've benchmarks for the scheduler already showing it to work pretty well (it's creating a too strict affinity but it can be relaxed to be more useful). Then later add some mechanism (simplest is the page fault at low frequency) to create a guest_vcpu_thread<->host_memory affinity and have a parvirtualized interface that tells the guest scheduler to group CPUs. If the guest scheduler runs free and is allowed to move threads randomly without any paravirtualized interface that controls the CPU thread migration in the guest scheduler, the thread<->memory affinity on host will be hopeless. But with a parvirtualized interface to make a guest thread stick to vcpu0/1/2/3 and not going into vcpu4/5/6/7, will allow to create a more meaningful guest_thread<->physical_ram affinity on host through KVM page faults. And then this will work also with VM migration and without having to create a vtopology in guest. And for apps running in guest no paravirt will be needed of course. The reason paravirt would be needed for qemu-kvm with a full automatic thread<->memory affinity is that the vcpu threads are magic. What runs in the vcpu thread are guest threads. And those can move through the guest CPU scheduler from vcpu0 to vcpu7. If that happens and we've 4 physical cpu for each p
[Qemu-devel] [PATCH v2] cow: use bdrv_co_is_allocated()
Now that bdrv_co_is_allocated() is available we can use it instead of
the synchronous bdrv_is_allocated() interface. This is a follow-up that
Kevin Wolf pointed out after applying the series that
introduces bdrv_co_is_allocated().
It is safe to make cow_read() a coroutine_fn because its only caller is
a coroutine_fn.
Signed-off-by: Stefan Hajnoczi
---
block/cow.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/block/cow.c b/block/cow.c
index 7ae887b..586493c 100644
--- a/block/cow.c
+++ b/block/cow.c
@@ -171,14 +171,14 @@ static int cow_update_bitmap(BlockDriverState *bs,
int64_t sector_num,
return error;
}
-static int cow_read(BlockDriverState *bs, int64_t sector_num,
-uint8_t *buf, int nb_sectors)
+static int coroutine_fn cow_read(BlockDriverState *bs, int64_t sector_num,
+ uint8_t *buf, int nb_sectors)
{
BDRVCowState *s = bs->opaque;
int ret, n;
while (nb_sectors > 0) {
-if (bdrv_is_allocated(bs, sector_num, nb_sectors, &n)) {
+if (bdrv_co_is_allocated(bs, sector_num, nb_sectors, &n)) {
ret = bdrv_pread(bs->file,
s->cow_sectors_offset + sector_num * 512,
buf, n * 512);
--
1.7.7.1
