Re: [Qemu-devel] TCG flow vs dyngen
You should see this pdf (www.ecs.syr.edu/faculty/yin/Teaching/TC2010/Proj4.pdf). It talks about tracing the instructions. -- Dushyant Wow thank you! It sounds incredibly interesting!! What we really need is to insert a function call into the translated code, so when each instruction is executed at runtime, our inserted function will be executed. Again wow!! Is that really possible? Some sort of callback triggered at every instruction execution? Yes, this mechanism works. I have written a code to count different kinds of instructions. Do you have any another document explaining that? No. But maybe you can try to understand this through qemu source code. Here are some resources for that http://stackoverflow.com/questions/4501173/a-call-to-those-who-have-worked-with-qemu This pdf just gives instructions on how to do it on an old version of qemu (disas_insn doesn't exist at all on my code now), and does not explain what it is, what's behind that suggested code .. Also the code for single step would be of great help to me! I really needed that.. but when I tried it on qemu-user didn't work at all.. It exists in file qemu/target-i386/translate.c You are also talking about qemu source code privided here http://wiki.qemu.org/Download, right? If you need, I can give the source code of counting implementation with some documentation. Hope this helps. -- Dushyant
RE: [Qemu-devel] [PATCH] Correct win32 timers deleting
> > diff --git a/qemu-timer.c b/qemu-timer.c index 95814af..548f2e5
> 100644
> > --- a/qemu-timer.c
> > +++ b/qemu-timer.c
> > @@ -972,7 +972,10 @@ static int win32_start_timer(struct
> qemu_alarm_timer
> > *t)
>
> Your patch is broken here.
I checked the patch file, my "sent items" folder in outlook. This line is
not broken in both places.
But when I receive my patch from "qemu-devel" list, this line is broken.
Do you have any ideas about that?
>
> > - timeKillEvent(data->timerId);
> > - timeEndPeriod(data->period);
> > + if (data->timerId)
> > + timeKillEvent(data->timerId);
> > + if (data->period)
> > + timeEndPeriod(data->period);
>
> CODING_STYLE requires {} for both if statements.
Ok, inserted in new version.
>
> Please check your patch using scripts/checkpatch.pl.
>
Now this script says, that patch is ok.
Pavel Dovgaluk
Re: [Qemu-devel] Re: [PATCH 4/7] Get rid of QemuMutex and teach its callers about GStaticMutex
On 2011-01-25 01:02, Anthony Liguori wrote: > On 01/24/2011 04:24 PM, Jan Kiszka wrote: >> On 2011-01-24 22:00, Anthony Liguori wrote: >> >>> Signed-off-by: Anthony Liguori >>> >>> diff --git a/cpus.c b/cpus.c >>> index 9cf7e6e..0f8e33b 100644 >>> --- a/cpus.c >>> +++ b/cpus.c >>> @@ -321,8 +321,8 @@ void vm_stop(int reason) >>> >>> #include "qemu-thread.h" >>> >>> -QemuMutex qemu_global_mutex; >>> -static QemuMutex qemu_fair_mutex; >>> +GStaticMutex qemu_global_mutex; >>> +static GStaticMutex qemu_fair_mutex; >>> >>> static QemuThread io_thread; >>> >>> @@ -416,9 +416,9 @@ int qemu_init_main_loop(void) >>> qemu_cond_init(&qemu_system_cond); >>> qemu_cond_init(&qemu_pause_cond); >>> qemu_cond_init(&qemu_work_cond); >>> -qemu_mutex_init(&qemu_fair_mutex); >>> -qemu_mutex_init(&qemu_global_mutex); >>> -qemu_mutex_lock(&qemu_global_mutex); >>> +g_static_mutex_init(&qemu_fair_mutex); >>> +g_static_mutex_init(&qemu_global_mutex); >>> +g_static_mutex_lock(&qemu_global_mutex); >>> >>> >> Just replacing our own abstraction with glib's looks like a step in the >> wrong direction. From a first glance at that library and its semantics >> it has at least two major drawbacks: >> >> - Error handling of things like g_mutex_lock or g_cond_wait is, well, >> very "simplistic". Once we start to use more sophisticated locking, >> more bugs will occur here, and we will need more support than glib is >> able to provide (or can you control error handling elsewhere?). >> >> - GMutex is not powerful enough for optional things like PI mutexes - >> which is required once we want to schedule parts of qemu with RT >> priorities (I did it, it works surprisingly well). >> > > One of the nice design characteristics of glib/gobject/gtk is that it > cohabitates well with other APIs. > > Nothing stops you from using pthread mutex directly if you really need > to. It makes you less portable, but sometimes it's a price that has to > be paid for functionality. I'm not talking about adding new PI mutexes, I'm talking about effectively reverting this patch as I need to initializes the existing ones with PI enabled in the attributes. Or replacing g_mutex_* with wrappers again to add real error handling. Really, glib is too primitive here. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] Re: Errors on MMIO read access on VM suspend / resume operations
On 2011-01-25 04:13, Stefan Berger wrote: > On 01/24/2011 05:34 PM, Jan Kiszka wrote: >> On 2011-01-24 19:27, Stefan Berger wrote: >>> On 01/18/2011 03:53 AM, Jan Kiszka wrote: On 2011-01-18 04:03, Stefan Berger wrote: > On 01/16/2011 09:43 AM, Avi Kivity wrote: >> On 01/14/2011 09:27 PM, Stefan Berger wrote: Can you sprinkle some printfs() arount kvm_run (in qemu-kvm.c) to verify this? >>> Here's what I did: >>> >>> >>> interrupt exit requested >> It appears from this you're using qemu.git. Please try qemu-kvm.git, >> where the code appears to be correct. >> > Cc'ing qemu-devel now. For reference, here the initial problem > description: > > http://www.spinics.net/lists/kvm/msg48274.html > > I didn't know there was another tree... > > I have seen now a couple of suspends-while-reading with patches > applied > to the qemu-kvm.git tree and indeed, when run with the same host > kernel > and VM I do not see the debugging dumps due to double-reads that I > would > have anticipated seeing by now. Now what? Can this be easily fixed in > the other Qemu tree as well? Please give this a try: git://git.kiszka.org/qemu-kvm.git queues/kvm-upstream I bet (& hope) "kvm: Unconditionally reenter kernel after IO exits" fixes the issue for you. If other problems pop up with that tree, also try resetting to that particular commit. I'm currently trying to shake all those hidden or forgotten bug fixes out of qemu-kvm and port them upstream. Most of those subtle differences should hopefully soon be history. >>> I did the same test as I did with Avi's tree and haven't seen the >>> consequences of possible double-reads. So, I would say that you should >>> upstream those patches... >>> >>> I searched for the text you mention above using 'gitk' but couldn't find >>> a patch with that headline in your tree. There were others that seem to >>> be related: >>> >>> Gleb Natapov: "do not enter vcpu again if it was stopped during IO" >> Err, I don't think you checked out queues/kvm-upstream. I bet you just >> ran my master branch which is a version of qemu-kvm's master. Am I >> right? :) >> > > You're right. :-) my lack of git knowledge - checked out the branch now. > > I redid the testing and it passed. No double-reads and lost bytes from > what I could see. Great, thanks. > > One thing I'd like to mention is that I have seen what I think are > interrupt stalls when running my tests inside the qemu-kvm.git tree > version and not suspending at all. A some point the interrupt > counter in > the guest kernel does not increase anymore even though I see the > device > model raising the IRQ and lowering it. The same tests run literally > forever in the qemu.git tree version of Qemu. What about qemu-kmv and -no-kvm-irqchip? >>> That seems to be necessary for both trees, yours and the one Avi pointed >>> me to. If applied, then I did not see the interrupt problem. >> And the fact that you were able to call qemu from my tree with >> -no-kvm-irqchip just underlines my assumption: that switch is refused by >> upstream. Please retry with the latest kvm-upstream queue. >> >> Besides that, this other bug you may see in the in-kernel IRQ path - how >> can we reproduce it? > Unfortunately I don't know. Some things have to come together for the > code I am working on to become available and useful for everyone. It's > going to be a while. Do you see a chance to look closer at the issue yourself? E.g. instrument the kernel's irqchip models and dump their states once your guest is stuck? Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] [PATCH] Correct win32 timers deleting
This patch fixes resource leaks caused by quitting qemu with exit() function
on win32 host.
Timer object should be freed not only at the end of the main function, but
by every of the application exits.
Signed-off-by: Pavel Dovgalyuk
---
qemu-timer.c | 16 +---
vl.c |1 -
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/qemu-timer.c b/qemu-timer.c
index 95814af..86d77a6 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -972,7 +972,10 @@ static int win32_start_timer(struct qemu_alarm_timer
*t)
timeGetDevCaps(&tc, sizeof(tc));
data->period = tc.wPeriodMin;
-timeBeginPeriod(data->period);
+if (timeBeginPeriod(data->period) != TIMERR_NOERROR) {
+fprintf(stderr, "Failed to initialize win32 alarm timer\n");
+return -1;
+}
flags = TIME_CALLBACK_FUNCTION;
if (alarm_has_dynticks(t))
@@ -990,6 +993,7 @@ static int win32_start_timer(struct qemu_alarm_timer *t)
fprintf(stderr, "Failed to initialize win32 alarm timer: %ld\n",
GetLastError());
timeEndPeriod(data->period);
+data->period = 0;
return -1;
}
@@ -1000,8 +1004,12 @@ static void win32_stop_timer(struct qemu_alarm_timer
*t)
{
struct qemu_alarm_win32 *data = t->priv;
-timeKillEvent(data->timerId);
-timeEndPeriod(data->period);
+if (data->timerId) {
+timeKillEvent(data->timerId);
+}
+if (data->period) {
+timeEndPeriod(data->period);
+}
}
static void win32_rearm_timer(struct qemu_alarm_timer *t)
@@ -1027,6 +1035,7 @@ static void win32_rearm_timer(struct qemu_alarm_timer
*t)
GetLastError());
timeEndPeriod(data->period);
+data->period = 0;
exit(1);
}
}
@@ -1061,6 +1070,7 @@ int init_timer_alarm(void)
t->pending = 1;
alarm_timer = t;
qemu_add_vm_change_state_handler(alarm_timer_on_change_state_rearm, t);
+atexit(quit_timers);
return 0;
diff --git a/vl.c b/vl.c
index 0292184..c4b25b0 100644
--- a/vl.c
+++ b/vl.c
@@ -3118,7 +3118,6 @@ int main(int argc, char **argv, char **envp)
os_setup_post();
main_loop();
-quit_timers();
net_cleanup();
return 0;
Re: [Qemu-devel] [PATCH v5 2/4] virtio-pci: Use ioeventfd for virtqueue notify
On Mon, Jan 24, 2011 at 8:05 PM, Kevin Wolf wrote: > Am 24.01.2011 20:47, schrieb Michael S. Tsirkin: >> On Mon, Jan 24, 2011 at 08:48:05PM +0100, Kevin Wolf wrote: >>> Am 24.01.2011 20:36, schrieb Michael S. Tsirkin: On Mon, Jan 24, 2011 at 07:54:20PM +0100, Kevin Wolf wrote: > Am 12.12.2010 16:02, schrieb Stefan Hajnoczi: >> Virtqueue notify is currently handled synchronously in userspace virtio. >> This >> prevents the vcpu from executing guest code while hardware emulation code >> handles the notify. >> >> On systems that support KVM, the ioeventfd mechanism can be used to make >> virtqueue notify a lightweight exit by deferring hardware emulation to >> the >> iothread and allowing the VM to continue execution. This model is >> similar to >> how vhost receives virtqueue notifies. >> >> The result of this change is improved performance for userspace virtio >> devices. >> Virtio-blk throughput increases especially for multithreaded scenarios >> and >> virtio-net transmit throughput increases substantially. >> >> Some virtio devices are known to have guest drivers which expect a >> notify to be >> processed synchronously and spin waiting for completion. Only enable >> ioeventfd >> for virtio-blk and virtio-net for now. >> >> Care must be taken not to interfere with vhost-net, which uses host >> notifiers. If the set_host_notifier() API is used by a device >> virtio-pci will disable virtio-ioeventfd and let the device deal with >> host notifiers as it wishes. >> >> After migration and on VM change state (running/paused) virtio-ioeventfd >> will enable/disable itself. >> >> * VIRTIO_CONFIG_S_DRIVER_OK -> enable virtio-ioeventfd >> * !VIRTIO_CONFIG_S_DRIVER_OK -> disable virtio-ioeventfd >> * virtio_pci_set_host_notifier() -> disable virtio-ioeventfd >> * vm_change_state(running=0) -> disable virtio-ioeventfd >> * vm_change_state(running=1) -> enable virtio-ioeventfd >> >> Signed-off-by: Stefan Hajnoczi > > On current git master I'm getting hangs when running iozone on a > virtio-blk disk. "Hang" means that it's not responsive any more and has > 100% CPU consumption. > > I bisected the problem to this patch. Any ideas? > > Kevin Does it help if you set ioeventfd=off on command line? >>> >>> Yes, with ioeventfd=off it seems to work fine. >>> >>> Kevin >> >> Then it's the ioeventfd that is to blame. >> Is it the io thread that consumes 100% CPU? >> Or the vcpu thread? > > I was building with the default options, i.e. there is no IO thread. > > Now I'm just running the test with IO threads enabled, and so far > everything looks good. So I can only reproduce the problem with IO > threads disabled. Hrm...aio uses SIGUSR2 to force the vcpu to process aio completions (relevant when --enable-io-thread is not used). I will take a look at that again and see why we're spinning without checking for ioeventfd completion. Stefan
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib
On Mon, Jan 24, 2011 at 06:24:13PM -0600, Anthony Liguori wrote: > On 01/24/2011 03:00 PM, Anthony Liguori wrote: > > Both the recent I/O loop and threadlet series have me concerned that we're > > digging ourselves deeper into the NIH hole. I think it's time we look at > > something radical to let us borrow more code from existing projects instead > > of > > reinventing everything through trial and error. > > > > This series introduces a hard dependency on glib. The initial use is > > portable > > threads but I see this as just the beginning. Glib/Gobject offer many nice > > things including: > > > > - portable threads > > - rich data structure support > > - INI parser > > - JSON parser > > - generic type system > > - object oriented infrastructure > > - IO library > > - module system > > - introspection to enable support for dynamic language bindings > > > > I see this series as the first step, followed by converting the I/O loop to > > a GMainLoop instance. Once we're there, we can start making deeper use of > > GObjects including converting QDev to a GObject hierarchy. > > > > I've spent the past few months working on C++ integration for QEMU. I'm > > more > > convinced than ever that we desperately in need of structured object > > oriented > > mechanisms to be successful but am pretty strongly convinced that > > incremental > > additional of C++ is not going to be successful. > > > > On the other hand, while GObjects are uglier and require a lot of template > > code, > > there's more than enough structure that I think it can guide us into a much > > better object model implementation. > > > > There is some ugliness. GLib does not abstract signals because they're > > very > > non-portable but QEMU makes extensive use of signaling. I don't think it's > > a major issue but some of the ugliness in this series is due to that fact. > > > > This series is only lightly tested but also mostly mechanical. I'm pretty > > confused by the way tcg_halt_cond and friends works so I'm fairly sure I > > broke > > that (for non-threaded TCG). > > > > Just to share where this is going, attached patch removes the posix-aio > thread pool and replaces it with a GThreadPool. > > Need to do a lot of functional and performance testing before making a > change like this so I'll keep this in a separate series, but thought it > might be interesting. > > Regards, > > Anthony Liguori > > From 5fdc51b2aac307c0219e1489b80bc18e9a3db0d1 Mon Sep 17 00:00:00 2001 > From: Anthony Liguori > Date: Mon, 24 Jan 2011 18:19:08 -0600 > Subject: [PATCH 8/7] posix-aio: convert to glib based thread pool > > This removes the custom pthread based thread pool in favor of a GThreadPool. > I believe this patch implements all of the necessary functionality but it > needs > quite a lot more testing and performance analysis. > > One thing I'm sure will break--we used to deliver a signal on every I/O > completion. This just slows down the I/O path. The reason we did this was > because at the time, I believe Cris depended on that signal to break out of > QEMU because it did I/O without a periodic timer installed. Hi Anthony, I have no memory of any such issues. Anyway, if you've got a tree a can clone, I'll be happy to give it a go and let you know if CRIS works ok. There's also a bootable CRIS linux guest image on the wiki's download page if you wan't to try yourself. Cheers
[Qemu-devel] [PATCH] target-sh4: fix TLB invalidation code
In cpu_sh4_invalidate_tlb, the UTLB was invalidated twice and the
ITLB left unchaged, probably because of some unfortunate copy/paste.
Signed-off-by: Alexandre Courbot
---
target-sh4/helper.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/target-sh4/helper.c b/target-sh4/helper.c
index c34d2f5..aec4d75 100644
--- a/target-sh4/helper.c
+++ b/target-sh4/helper.c
@@ -562,8 +562,8 @@ void cpu_load_tlb(CPUSH4State * env)
entry->v = 0;
}
/* ITLB */
-for (i = 0; i < UTLB_SIZE; i++) {
-tlb_t * entry = &s->utlb[i];
+for (i = 0; i < ITLB_SIZE; i++) {
+tlb_t * entry = &s->itlb[i];
entry->v = 0;
}
--
1.7.3.5
[Qemu-devel] [PATCH v2] linux-user/FLAT: allow targets to override FLAT processing
This brings flatload.c more in line with the current Linux FLAT loader
which allows targets to handle various FLAT aspects in their own way.
For the common behavior, the new functions get stubbed out.
Signed-off-by: Mike Frysinger
---
v2
- also add flat_argvp_envp_on_stack() just like Linux
Makefile.target |2 +-
linux-user/flatload.c| 27 +++
linux-user/target_flat.h | 10 ++
3 files changed, 22 insertions(+), 17 deletions(-)
create mode 100644 linux-user/target_flat.h
diff --git a/Makefile.target b/Makefile.target
index b0ba95f..48e6c00 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -107,7 +107,7 @@ ifdef CONFIG_LINUX_USER
$(call set-vpath,
$(SRC_PATH)/linux-user:$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR))
-QEMU_CFLAGS+=-I$(SRC_PATH)/linux-user
-I$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR)
+QEMU_CFLAGS+=-I$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR)
-I$(SRC_PATH)/linux-user
obj-y = main.o syscall.o strace.o mmap.o signal.o thunk.o \
elfload.o linuxload.o uaccess.o gdbstub.o cpu-uname.o \
qemu-malloc.o $(oslib-obj-y)
diff --git a/linux-user/flatload.c b/linux-user/flatload.c
index d8b4476..cd7af7c 100644
--- a/linux-user/flatload.c
+++ b/linux-user/flatload.c
@@ -41,6 +41,8 @@
#include "qemu.h"
#include "flat.h"
+#define ntohl(x) be32_to_cpu(x)
+#include
//#define DEBUG
@@ -50,14 +52,6 @@
#defineDBG_FLT(...)
#endif
-#define flat_reloc_valid(reloc, size) ((reloc) <= (size))
-#define flat_old_ram_flag(flag) (flag)
-#ifdef TARGET_WORDS_BIGENDIAN
-#define flat_get_relocate_addr(relval)(relval)
-#else
-#define flat_get_relocate_addr(relval)bswap32(relval)
-#endif
-
#define RELOC_FAILED 0xff00ff01/* Relocation incorrect
somewhere */
#define UNLOADED_LIB 0x7ff000ff/* Placeholder for unused
library */
@@ -78,8 +72,6 @@ static int load_flat_shared_library(int id, struct lib_info
*p);
struct linux_binprm;
-#define ntohl(x) be32_to_cpu(x)
-
//
/*
* create_flat_tables() parses the env- and arg-strings in new user
@@ -625,6 +617,7 @@ static int load_flat_file(struct linux_binprm * bprm,
* __start to address 4 so that is okay).
*/
if (rev > OLD_FLAT_VERSION) {
+abi_ulong persistent = 0;
for (i = 0; i < relocs; i++) {
abi_ulong addr, relval;
@@ -633,6 +626,9 @@ static int load_flat_file(struct linux_binprm * bprm,
relocated first). */
if (get_user_ual(relval, reloc + i * sizeof(abi_ulong)))
return -EFAULT;
+relval = ntohl(relval);
+if (flat_set_persistent(relval, &persistent))
+continue;
addr = flat_get_relocate_addr(relval);
rp = calc_reloc(addr, libinfo, id, 1);
if (rp == RELOC_FAILED)
@@ -641,22 +637,20 @@ static int load_flat_file(struct linux_binprm * bprm,
/* Get the pointer's value. */
if (get_user_ual(addr, rp))
return -EFAULT;
+addr = flat_get_addr_from_rp(rp, relval, flags, &persistent);
if (addr != 0) {
/*
* Do the relocation. PIC relocs in the data section are
* already in target order
*/
-
-#ifndef TARGET_WORDS_BIGENDIAN
if ((flags & FLAT_FLAG_GOTPIC) == 0)
-addr = bswap32(addr);
-#endif
+addr = ntohl(addr);
addr = calc_reloc(addr, libinfo, id, 0);
if (addr == RELOC_FAILED)
return -ENOEXEC;
/* Write back the relocated pointer. */
-if (put_user_ual(addr, rp))
+if (flat_put_addr_at_rp(rp, addr, relval))
return -EFAULT;
}
}
@@ -782,7 +776,8 @@ int load_flt_binary(struct linux_binprm * bprm, struct
target_pt_regs * regs,
stack_len *= sizeof(abi_ulong);
if ((sp + stack_len) & 15)
sp -= 16 - ((sp + stack_len) & 15);
-sp = loader_build_argptr(bprm->envc, bprm->argc, sp, p, 1);
+sp = loader_build_argptr(bprm->envc, bprm->argc, sp, p,
+ flat_argvp_envp_on_stack());
/* Fake some return addresses to ensure the call chain will
* initialise library in order for us. We are required to call
diff --git a/linux-user/target_flat.h b/linux-user/target_flat.h
new file mode 100644
index 000..0ba6bdd
--- /dev/null
+++ b/linux-user/target_flat.h
@@ -0,0 +1,10 @@
+/* If your arch needs to do custom stuff, create your own target_flat.h
+ * header file in linux-user//
+ */
+#define flat_argvp_envp_on_stack() 1
+#define flat_reloc_valid(reloc, size)((reloc) <=
(size))
+#define flat_old_ram_flag(flag)
[Qemu-devel] [PATCH] target-sh4: update PTEH upon MMU exception
Update the PTEH register to contain the VPN at which an MMU
exception occured as specified by the SH4 reference.
---
target-sh4/helper.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/target-sh4/helper.c b/target-sh4/helper.c
index 2d76f22..c34d2f5 100644
--- a/target-sh4/helper.c
+++ b/target-sh4/helper.c
@@ -453,6 +453,9 @@ int cpu_sh4_handle_mmu_fault(CPUState * env, target_ulong
address, int rw,
if (ret != MMU_OK) {
env->tea = address;
+ if (ret != MMU_DTLB_MULTIPLE && ret != MMU_ITLB_MULTIPLE)
+ env->pteh = (env->pteh & PTEH_ASID_MASK) |
+ (address & PTEH_VPN_MASK);
switch (ret) {
case MMU_ITLB_MISS:
case MMU_DTLB_MISS_READ:
--
1.7.3.5
[Qemu-devel] [PATCH] target-sh4: fix index of address read error exception
Exception index of address read error should be 0x0e0. --- target-sh4/helper.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/target-sh4/helper.c b/target-sh4/helper.c index 45449ea..2d76f22 100644 --- a/target-sh4/helper.c +++ b/target-sh4/helper.c @@ -479,7 +479,7 @@ int cpu_sh4_handle_mmu_fault(CPUState * env, target_ulong address, int rw, break; case MMU_IADDR_ERROR: case MMU_DADDR_ERROR_READ: - env->exception_index = 0x0c0; + env->exception_index = 0x0e0; break; case MMU_DADDR_ERROR_WRITE: env->exception_index = 0x100; -- 1.7.3.5
Re: [Qemu-devel] Re: Errors on MMIO read access on VM suspend / resume operations
On 01/24/2011 05:34 PM, Jan Kiszka wrote: On 2011-01-24 19:27, Stefan Berger wrote: On 01/18/2011 03:53 AM, Jan Kiszka wrote: On 2011-01-18 04:03, Stefan Berger wrote: On 01/16/2011 09:43 AM, Avi Kivity wrote: On 01/14/2011 09:27 PM, Stefan Berger wrote: Can you sprinkle some printfs() arount kvm_run (in qemu-kvm.c) to verify this? Here's what I did: interrupt exit requested It appears from this you're using qemu.git. Please try qemu-kvm.git, where the code appears to be correct. Cc'ing qemu-devel now. For reference, here the initial problem description: http://www.spinics.net/lists/kvm/msg48274.html I didn't know there was another tree... I have seen now a couple of suspends-while-reading with patches applied to the qemu-kvm.git tree and indeed, when run with the same host kernel and VM I do not see the debugging dumps due to double-reads that I would have anticipated seeing by now. Now what? Can this be easily fixed in the other Qemu tree as well? Please give this a try: git://git.kiszka.org/qemu-kvm.git queues/kvm-upstream I bet (& hope) "kvm: Unconditionally reenter kernel after IO exits" fixes the issue for you. If other problems pop up with that tree, also try resetting to that particular commit. I'm currently trying to shake all those hidden or forgotten bug fixes out of qemu-kvm and port them upstream. Most of those subtle differences should hopefully soon be history. I did the same test as I did with Avi's tree and haven't seen the consequences of possible double-reads. So, I would say that you should upstream those patches... I searched for the text you mention above using 'gitk' but couldn't find a patch with that headline in your tree. There were others that seem to be related: Gleb Natapov: "do not enter vcpu again if it was stopped during IO" Err, I don't think you checked out queues/kvm-upstream. I bet you just ran my master branch which is a version of qemu-kvm's master. Am I right? :) You're right. :-) my lack of git knowledge - checked out the branch now. I redid the testing and it passed. No double-reads and lost bytes from what I could see. One thing I'd like to mention is that I have seen what I think are interrupt stalls when running my tests inside the qemu-kvm.git tree version and not suspending at all. A some point the interrupt counter in the guest kernel does not increase anymore even though I see the device model raising the IRQ and lowering it. The same tests run literally forever in the qemu.git tree version of Qemu. What about qemu-kmv and -no-kvm-irqchip? That seems to be necessary for both trees, yours and the one Avi pointed me to. If applied, then I did not see the interrupt problem. And the fact that you were able to call qemu from my tree with -no-kvm-irqchip just underlines my assumption: that switch is refused by upstream. Please retry with the latest kvm-upstream queue. Besides that, this other bug you may see in the in-kernel IRQ path - how can we reproduce it? Unfortunately I don't know. Some things have to come together for the code I am working on to become available and useful for everyone. It's going to be a while. Thanks! Stefan Jan
[Qemu-devel] [Bug 706766] Re: [Qemu-kvm] qemu-img fail to create qcow image
Patch worked with testing. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/706766 Title: [Qemu-kvm] qemu-img fail to create qcow image Status in QEMU: Confirmed Bug description: On qemu-kvm tree 6f32e3d09d990fd50008756fcb446b55e0c0af79, complier it. Then try to create a qcow image with a exist raw image, create fail. reproduce steps: 1) build qemu-kvm 2) ./qemu-img create -b ./ia32e_fc10.img -f qcow2 ./qcow.img 3) Fail to create qcow image, it show error "qemu-img: Could not open './qcow.img' "
Re: [Qemu-devel] qemu-user: relocating target code weakness
On 01/24/2011 01:44 PM, Stefano Bonifazi wrote: > Wow wonderful! So you fixed the code for PIC (ET_DYN) support? Yes. > how can I get your sources? I was mistaken -- a later version of the patch set was in fact merged. I simply forgot to delete my working branch afterward. r~
Re: [Qemu-devel] TCG flow vs dyngen
On 01/24/2011 03:16 PM, Stefano Bonifazi wrote: > Hi! Thanks for replying me! >> The thing is, the kernel currently _does_ work, so studying the relevant >> kernel code (and possibly the dynamic loader code) is one way to learn >> how it currently works. > Sorry what kernel? Qemu's? Linux's? QEMU isn't a kernel, it's an emulator. Linux is a kernel. I meant Linux loads and runs Linux ELF executables. That's pretty much the definition of "how to do it". So if there's ever a conflict between "how qemu does it" and "how the Linux kernel does it", the Linux kernel is going to win. (And yes, this has come up before, for me it was http://www.mail-archive.com/qemu-devel@nongnu.org/msg25336.html ) That said, QEMU's currently working fairly well on this front too, so studying either should work pretty well... One advantage of the kernel is "cat /proc/$PID/maps" which lets you know what the mappings are, and then you can look up the appropriate chunks of the executable and read the elf spec: http://refspecs.freestandards.org/elf/elf.pdf And to be honest, the best way to get up to speed on this is to read this: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html Where some guy asked "ok, what do we actually NEED" and then set out to prove it. This book is pretty good too, although so dry it's almost unreadable. You might have better luck getting a paper copy out of the library: http://www.iecc.com/linker/ Rob
Re: [Qemu-devel] Re: [RFC][PATCH v6 08/23] virtagent: add va.getfile RPC
On 01/24/2011 06:22 PM, Michael Roth wrote: Actually, copyfile is the proposed open/read/write/close interface. getfile is the current interface, and it seems to be a contentious one. I've discussed it quite a bit with Jes here and in the last couple RFCs. I think the current course is that we'll end up ditching viewfile/viewdmesg in favor of copyfile, and that we should do it now rather than later. The upshot is that "viewfile " is basically equivalent to: copyfile_open /dev/stdout -> fd_handle; copyfile_read fd ; copyfile_close fd_handle". I really just want getfile. I think designing a partial read API at this stage isn't a good idea. Wait until there's a concrete use case before adding an interface. Regards, Anthony Liguori
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib
On 01/24/2011 03:00 PM, Anthony Liguori wrote:
Both the recent I/O loop and threadlet series have me concerned that we're
digging ourselves deeper into the NIH hole. I think it's time we look at
something radical to let us borrow more code from existing projects instead of
reinventing everything through trial and error.
This series introduces a hard dependency on glib. The initial use is portable
threads but I see this as just the beginning. Glib/Gobject offer many nice
things including:
- portable threads
- rich data structure support
- INI parser
- JSON parser
- generic type system
- object oriented infrastructure
- IO library
- module system
- introspection to enable support for dynamic language bindings
I see this series as the first step, followed by converting the I/O loop to
a GMainLoop instance. Once we're there, we can start making deeper use of
GObjects including converting QDev to a GObject hierarchy.
I've spent the past few months working on C++ integration for QEMU. I'm more
convinced than ever that we desperately in need of structured object oriented
mechanisms to be successful but am pretty strongly convinced that incremental
additional of C++ is not going to be successful.
On the other hand, while GObjects are uglier and require a lot of template code,
there's more than enough structure that I think it can guide us into a much
better object model implementation.
There is some ugliness. GLib does not abstract signals because they're very
non-portable but QEMU makes extensive use of signaling. I don't think it's
a major issue but some of the ugliness in this series is due to that fact.
This series is only lightly tested but also mostly mechanical. I'm pretty
confused by the way tcg_halt_cond and friends works so I'm fairly sure I broke
that (for non-threaded TCG).
Just to share where this is going, attached patch removes the posix-aio
thread pool and replaces it with a GThreadPool.
Need to do a lot of functional and performance testing before making a
change like this so I'll keep this in a separate series, but thought it
might be interesting.
Regards,
Anthony Liguori
>From 5fdc51b2aac307c0219e1489b80bc18e9a3db0d1 Mon Sep 17 00:00:00 2001
From: Anthony Liguori
Date: Mon, 24 Jan 2011 18:19:08 -0600
Subject: [PATCH 8/7] posix-aio: convert to glib based thread pool
This removes the custom pthread based thread pool in favor of a GThreadPool.
I believe this patch implements all of the necessary functionality but it needs
quite a lot more testing and performance analysis.
One thing I'm sure will break--we used to deliver a signal on every I/O
completion. This just slows down the I/O path. The reason we did this was
because at the time, I believe Cris depended on that signal to break out of
QEMU because it did I/O without a periodic timer installed.
At this point in time, I think any architecture that requires signals needs to
do so with a periodic timer or some other mechanism.
Signed-off-by: Anthony Liguori
diff --git a/configure b/configure
index 820fde9..1af6b44 100755
--- a/configure
+++ b/configure
@@ -1663,6 +1663,7 @@ if $pkg_config --modversion gthread-2.0 > /dev/null 2>&1 ; then
glib_cflags=`$pkg_config --cflags gthread-2.0 2>/dev/null`
glib_libs=`$pkg_config --libs gthread-2.0 2>/dev/null`
libs_softmmu="$glib_libs $libs_softmmu"
+libs_tools="$glib_libs $libs_tools"
else
echo "glib-2.0 required to compile QEMU"
exit 1
diff --git a/posix-aio-compat.c b/posix-aio-compat.c
index fa5494d..4d65396 100644
--- a/posix-aio-compat.c
+++ b/posix-aio-compat.c
@@ -12,27 +12,24 @@
*/
#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "qemu-queue.h"
+
#include "osdep.h"
#include "sysemu.h"
#include "qemu-common.h"
#include "trace.h"
#include "block_int.h"
+#include "qemu-thread.h"
#include "block/raw-posix-aio.h"
+typedef enum AioState {
+INACTIVE,
+CANCELLED,
+ACTIVE,
+COMPLETED
+} AioState;
-struct qemu_paiocb {
+typedef struct AioAiocb {
BlockDriverAIOCB common;
int aio_fildes;
union {
@@ -40,34 +37,29 @@ struct qemu_paiocb {
void *aio_ioctl_buf;
};
int aio_niov;
-size_t aio_nbytes;
-#define aio_ioctl_cmd aio_nbytes /* for QEMU_AIO_IOCTL */
-int ev_signo;
+union {
+size_t aio_nbytes;
+long aio_ioctl_cmd;
+};
off_t aio_offset;
-
-QTAILQ_ENTRY(qemu_paiocb) node;
int aio_type;
ssize_t ret;
-int active;
-struct qemu_paiocb *next;
-
int async_context_id;
-};
-typedef struct PosixAioState {
+/* This state can only be set/get when the aio pool lock is held */
+AioState state;
+} AioAiocb;
+
+typedef struct AioPool {
+GThreadPool *pool;
int rfd, wfd;
-struct qemu_paiocb *first_aio;
-} PosixAioState;
+GList *requests;
+/* If this turns out to be contended, push to a per-request lock */
+
Re: [Qemu-devel] Re: [RFC][PATCH v6 08/23] virtagent: add va.getfile RPC
On 01/24/2011 05:40 PM, Anthony Liguori wrote: On 01/24/2011 04:48 PM, Richard W.M. Jones wrote: On Mon, Jan 24, 2011 at 04:26:09PM -0600, Anthony Liguori wrote: On 01/24/2011 04:20 PM, Richard W.M. Jones wrote: On Mon, Jan 24, 2011 at 10:08:09PM +, Richard W.M. Jones wrote: You might as well reuse the libguestfs API here because you get the benefit of all the code that's been written, all the tools on top, and a far more comprehensive API that would take you another 2 years to implement. To put it in some perspective, libguestfs is just shy of 500K lines of code now, not including the tools built on top. 150 page manual just for the core API. Yeah, but I think that's the reason that it might not be a good candidate for this use-case. We need a *simple* interface that we can convince everyone to install by default and run in their guests. It needs to be flexible enough that we can do lots of fun things but simple enough that a reasonable person can audit the code in a short period of time. It will never replace something as sophisticated as guestfs but that's not it's point. It's point is to let you do simple things like execute a command in the guest or peek at /proc/meminfo. You don't need 500k LOCs for that. I don't really want to argue over this, since I think accessing live VMs like this is a really useful feature, and it complements libguestfs (image editing) very nicely. I'll just say that you might not think you need it to start off with (and we didn't either), but when you notice that "simple" open/read/write/close Oh I don't think there should be an open/read/write/close interface. I'm quite happy with the current copyfile interface. Actually, copyfile is the proposed open/read/write/close interface. getfile is the current interface, and it seems to be a contentious one. I've discussed it quite a bit with Jes here and in the last couple RFCs. I think the current course is that we'll end up ditching viewfile/viewdmesg in favor of copyfile, and that we should do it now rather than later. The upshot is that "viewfile " is basically equivalent to: copyfile_open /dev/stdout -> fd_handle; copyfile_read fd ; copyfile_close fd_handle". Or we can output to a file and potentially introduce a monitor command that wraps these to provide simple oneliner like we have now, though there may be some reluctance there as well. But at least it'll be possible either way. in fact has terrible performance so you need to specialize many operations, and then someone wants to create a filesystem, and someone else wants a FUSE interface, suddenly you'll be reimplementing large parts of libguestfs. Nope. If you want to do fancy things, use libguestfs :-) BTW, how dependent is guestfsd on the guest that libguestfs uses? I wasn't even aware that it could be used outside of that context. Regards, Anthony Liguori The daemon (guestfsd) is 36106 LoC. Rich.
Re: [Qemu-devel] qemu-user: relocating target code weakness
On Mon, Jan 24, 2011 at 19:06, Mike Frysinger wrote: > On Mon, Jan 24, 2011 at 11:29, Mulyadi Santosa wrote: >> I wrote an article about understanding ELF years ago, here is the URL: >> http://www.linuxforums.org/articles/understanding-elf-using-readelf-and-objdump_125.html > > i also highly recommend Linkers & Loaders: > http://linker.iecc.com/ > > some pieces might be a little dated, but buy & large, it's still relevant Ian Lance Taylor (author of the GOLD linker) maintains a blog where he posts well written and in-depth articles on various toolchain pieces: http://www.airs.com/blog/archives/category/programming this one talks about the GOT/PLT for ELF on a MMU: http://www.airs.com/blog/archives/41 -mike
Re: [Qemu-devel] qemu-user: relocating target code weakness
On Mon, Jan 24, 2011 at 11:29, Mulyadi Santosa wrote: > I wrote an article about understanding ELF years ago, here is the URL: > http://www.linuxforums.org/articles/understanding-elf-using-readelf-and-objdump_125.html i also highly recommend Linkers & Loaders: http://linker.iecc.com/ some pieces might be a little dated, but buy & large, it's still relevant -mike
Re: [Qemu-devel] Re: [PATCH 4/7] Get rid of QemuMutex and teach its callers about GStaticMutex
On 01/24/2011 04:24 PM, Jan Kiszka wrote: On 2011-01-24 22:00, Anthony Liguori wrote: Signed-off-by: Anthony Liguori diff --git a/cpus.c b/cpus.c index 9cf7e6e..0f8e33b 100644 --- a/cpus.c +++ b/cpus.c @@ -321,8 +321,8 @@ void vm_stop(int reason) #include "qemu-thread.h" -QemuMutex qemu_global_mutex; -static QemuMutex qemu_fair_mutex; +GStaticMutex qemu_global_mutex; +static GStaticMutex qemu_fair_mutex; static QemuThread io_thread; @@ -416,9 +416,9 @@ int qemu_init_main_loop(void) qemu_cond_init(&qemu_system_cond); qemu_cond_init(&qemu_pause_cond); qemu_cond_init(&qemu_work_cond); -qemu_mutex_init(&qemu_fair_mutex); -qemu_mutex_init(&qemu_global_mutex); -qemu_mutex_lock(&qemu_global_mutex); +g_static_mutex_init(&qemu_fair_mutex); +g_static_mutex_init(&qemu_global_mutex); +g_static_mutex_lock(&qemu_global_mutex); Just replacing our own abstraction with glib's looks like a step in the wrong direction. From a first glance at that library and its semantics it has at least two major drawbacks: - Error handling of things like g_mutex_lock or g_cond_wait is, well, very "simplistic". Once we start to use more sophisticated locking, more bugs will occur here, and we will need more support than glib is able to provide (or can you control error handling elsewhere?). - GMutex is not powerful enough for optional things like PI mutexes - which is required once we want to schedule parts of qemu with RT priorities (I did it, it works surprisingly well). One of the nice design characteristics of glib/gobject/gtk is that it cohabitates well with other APIs. Nothing stops you from using pthread mutex directly if you really need to. It makes you less portable, but sometimes it's a price that has to be paid for functionality. The same concerns apply to other abstractions glib provides for threading and synchronization. One may work around them, but that will break abstractions again. Glib seems to fit standard use case quite comfortably but fails in more advanced scenarios qemu is already useable for (just lacking a few additional lines of code). In short: we need full POSIX where available. If the problem we have is that we have such advanced use of threading and locking in QEMU such that the glib API is not enough and we find ourselves constantly calling into the pthread's API directly, then that's a wonderful problem to have. Regards, Anthony Liguori Jan
Re: [Qemu-devel] qemu-user: relocating target code weakness
On Mon, Jan 24, 2011 at 16:52, Stefano Bonifazi wrote: >> but that can happen with the app running natively too, so any app not >> handling MAP_FIXED failures is buggy and not qemu's problem. > > How? For what I learned each process executing on a OS with an mmu sees its > virtual address space, and normally only its code is loaded there (well I am > learning that the dynamic linker also inject into that space shared library > code used by the process code, but of course a good dynamic linker would > prevent clashes!) how can the ldso possibly prevent clashes ? it has no idea what addresses an app will ask for at runtime. plus, if the kernel is employing ASLR (which isnt uncommon nowadays), the load addresses could be anywhere. -mike
Re: [Qemu-devel] Re: [RFC][PATCH v6 08/23] virtagent: add va.getfile RPC
On 01/24/2011 04:48 PM, Richard W.M. Jones wrote: On Mon, Jan 24, 2011 at 04:26:09PM -0600, Anthony Liguori wrote: On 01/24/2011 04:20 PM, Richard W.M. Jones wrote: On Mon, Jan 24, 2011 at 10:08:09PM +, Richard W.M. Jones wrote: You might as well reuse the libguestfs API here because you get the benefit of all the code that's been written, all the tools on top, and a far more comprehensive API that would take you another 2 years to implement. To put it in some perspective, libguestfs is just shy of 500K lines of code now, not including the tools built on top. 150 page manual just for the core API. Yeah, but I think that's the reason that it might not be a good candidate for this use-case. We need a *simple* interface that we can convince everyone to install by default and run in their guests. It needs to be flexible enough that we can do lots of fun things but simple enough that a reasonable person can audit the code in a short period of time. It will never replace something as sophisticated as guestfs but that's not it's point. It's point is to let you do simple things like execute a command in the guest or peek at /proc/meminfo. You don't need 500k LOCs for that. I don't really want to argue over this, since I think accessing live VMs like this is a really useful feature, and it complements libguestfs (image editing) very nicely. I'll just say that you might not think you need it to start off with (and we didn't either), but when you notice that "simple" open/read/write/close Oh I don't think there should be an open/read/write/close interface. I'm quite happy with the current copyfile interface. in fact has terrible performance so you need to specialize many operations, and then someone wants to create a filesystem, and someone else wants a FUSE interface, suddenly you'll be reimplementing large parts of libguestfs. Nope. If you want to do fancy things, use libguestfs :-) BTW, how dependent is guestfsd on the guest that libguestfs uses? I wasn't even aware that it could be used outside of that context. Regards, Anthony Liguori The daemon (guestfsd) is 36106 LoC. Rich.
Re: [Qemu-devel] qemu-user: relocating target code weakness
On Mon, Jan 24, 2011 at 16:44, Stefano Bonifazi wrote: >> http://lists.gnu.org/archive/html/qemu-devel/2010-07/msg01626.html > > A noob question, how can I get your sources? Is there a simpler solution > than "copy&paste" all the code from your messages into patches and then > applying them? Can you just send your sources by email? Or can I download > them from a site? weird ... usually the gnu archives have a "download raw text" option so you can get a mbox file to import into your mailer you could use the gmane.org nntp gateway to get all the raw e-mails though: nntp://news.gmane.org/gmane.comp.emulators.qemu -mike
[Qemu-devel] [PULL 00/23] Block patches
The following changes since commit 0bfe006c5380c5f8a485a55ded3329fbbc224396: multiboot: Fix upper memory size in multiboot info (2011-01-23 22:44:13 +0100) are available in the git repository at: git://repo.or.cz/qemu/kevin.git for-anthony Aurelien Jarno (1): qcow2: fix unaligned access Christoph Hellwig (3): ide: factor dma handling helpers ide: also reset io_buffer_index for writes ide: kill ide_dma_submit_check Jes Sorensen (2): do_snapshot_blkdev() error on missing snapshot_file argument Make strtosz() return int64_t instead of ssize_t Kevin Wolf (5): qemu-img snapshot: Use writeback caching qcow2: Add QcowCache qcow2: Use QcowCache qcow2: Batch flushes for COW Documentation: Add qemu-img check/rebase Markus Armbruster (3): blockdev: Fix error message for invalid -drive CHS blockdev: Make drive_init() use error_report() blockdev: Fix drive_del not to crash when drive is not in use Pierre Riteau (2): Avoid divide by zero when there is no block device to migrate Fix block migration when the device size is not a multiple of 1 MB Stefan Hajnoczi (6): qed: Refuse to create images on block devices block: Use backing format driver during image creation scsi-disk: Allow overriding SCSI INQUIRY removable bit scsi: Allow scsi_bus_legacy_add_drive() to set removable bit usb-msd: Propagate removable bit to SCSI device docs: Document scsi-disk and usb-storage removable parameter Stefan Weil (1): ide: Remove unneeded null pointer check Makefile.objs|2 +- block-migration.c| 29 - block.c |8 +- block/qcow2-cache.c | 314 ++ block/qcow2-cluster.c| 210 +++ block/qcow2-refcount.c | 260 -- block/qcow2.c| 48 +++- block/qcow2.h| 32 - block/qed.c |6 + blockdev.c | 81 +++-- cutils.c |8 +- docs/qdev-device-use.txt | 13 ++- hw/ide/core.c| 113 ++--- hw/ide/internal.h|4 +- hw/ide/pci.c | 13 +-- hw/pci-hotplug.c |2 +- hw/scsi-bus.c|8 +- hw/scsi-disk.c |3 + hw/scsi.h|3 +- hw/usb-msd.c |4 +- monitor.c|2 +- qemu-common.h|4 +- qemu-img.c |4 +- qemu-img.texi| 41 ++ vl.c |4 +- 25 files changed, 764 insertions(+), 452 deletions(-) create mode 100644 block/qcow2-cache.c
Re: [Qemu-devel] qemu-user: relocating target code weakness
Yes. Have a look at http://lists.gnu.org/archive/html/qemu-devel/2010-07/msg01626.html where I tried to clean this up last year. The patch never got properly reviewed, however. All that said, unless you have an executable that's been properly prepared for relocation, e.g. an ET_DYN binary instead of a normal ET_EXEC binary, you will *not* have enough information to do what you're suggesting. r~ Wow wonderful! So you fixed the code for PIC (ET_DYN) support? I won't have any problem in producing the target code into pie format, as I am writing, compiling and linking my target code by my own ;) A noob question, how can I get your sources? Is there a simpler solution than "copy&paste" all the code from your messages into patches and then applying them? Can you just send your sources by email? Or can I download them from a site? I am very eager to study your code and to try it :) Thank you very much!! Stefano B.
[Qemu-devel] git rm Changelog?
... or at least "git mv Changelog Changelog.old"? It only goes back to 0.12.0 so that there is hardly a place in the git repo to look for new features in 0.13 and 0.14. Paolo
Re: [Qemu-devel] Re: [RFC][PATCH v6 08/23] virtagent: add va.getfile RPC
On Mon, Jan 24, 2011 at 04:26:09PM -0600, Anthony Liguori wrote: > On 01/24/2011 04:20 PM, Richard W.M. Jones wrote: > >On Mon, Jan 24, 2011 at 10:08:09PM +, Richard W.M. Jones wrote: > >>You might as well reuse the libguestfs API here because you get the > >>benefit of all the code that's been written, all the tools on top, and > >>a far more comprehensive API that would take you another 2 years to > >>implement. > >To put it in some perspective, libguestfs is just shy of 500K lines of > >code now, not including the tools built on top. 150 page manual just > >for the core API. > > Yeah, but I think that's the reason that it might not be a good > candidate for this use-case. > > We need a *simple* interface that we can convince everyone to > install by default and run in their guests. It needs to be flexible > enough that we can do lots of fun things but simple enough that a > reasonable person can audit the code in a short period of time. > > It will never replace something as sophisticated as guestfs but > that's not it's point. It's point is to let you do simple things > like execute a command in the guest or peek at /proc/meminfo. You > don't need 500k LOCs for that. I don't really want to argue over this, since I think accessing live VMs like this is a really useful feature, and it complements libguestfs (image editing) very nicely. I'll just say that you might not think you need it to start off with (and we didn't either), but when you notice that "simple" open/read/write/close in fact has terrible performance so you need to specialize many operations, and then someone wants to create a filesystem, and someone else wants a FUSE interface, suddenly you'll be reimplementing large parts of libguestfs. The daemon (guestfsd) is 36106 LoC. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v
Re: [Qemu-devel] qemu-user: relocating target code weakness
how can the ldso possibly prevent clashes ? it has no idea what addresses an app will ask for at runtime. plus, if the kernel is employing ASLR (which isnt uncommon nowadays), the load addresses could be anywhere. -mike Well not alone, in my mind ld.so asks the memory manager through calling mmap where it can map the shared modules inside the process address space.. the memory manager should know what addresses are free and which are taken .. then when the process code requires dynamic memory allocation, it does it again through the memory manager (i.e. malloc) avoiding of allocating memory where shared modules have been loaded into.. Again with ASLR I think the mmu should be aware of all used memory slots, avoiding conflicts.. Well your view of random possible clashes maybe is what happens or happened in Windows systems :D But Linux is supposed to be different, isn't it? Best regards, Stefano B.
Re: [Qemu-devel] Re: [RFC][PATCH v6 08/23] virtagent: add va.getfile RPC
On Mon, Jan 24, 2011 at 10:08:09PM +, Richard W.M. Jones wrote: > You might as well reuse the libguestfs API here because you get the > benefit of all the code that's been written, all the tools on top, and > a far more comprehensive API that would take you another 2 years to > implement. To put it in some perspective, libguestfs is just shy of 500K lines of code now, not including the tools built on top. 150 page manual just for the core API. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/
[Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by default
On 01/24/2011 03:00 PM, Anthony Liguori wrote: Leave the disable options for now to help with testing but these will be removed once we're confident in the thread implementations. Disabled code bit rots. These have been in tree long enough that we need to either commit to making them work or just remove them entirely. I/O thread disables icount apparently. I'm not really sure why. Marcelo, do you know the reason qemu_calculate_timeout returns a fixed value in the I/O thread regardless of icount? Regards, Anthony Liguori Signed-off-by: Anthony Liguori diff --git a/configure b/configure index d68f862..d5ac074 100755 --- a/configure +++ b/configure @@ -124,7 +124,7 @@ vnc_tls="" vnc_sasl="" vnc_jpeg="" vnc_png="" -vnc_thread="no" +vnc_thread="yes" xen="" linux_aio="" attr="" @@ -161,7 +161,7 @@ darwin_user="no" bsd_user="no" guest_base="" uname_release="" -io_thread="no" +io_thread="yes" mixemu="no" kerneldir="" aix="no" @@ -699,6 +699,8 @@ for opt do ;; --enable-io-thread) io_thread="yes" ;; + --disable-io-thread) io_thread="no" + ;; --disable-blobs) blobs="no" ;; --kerneldir=*) kerneldir="$optarg" @@ -901,6 +903,7 @@ echo " --enable-linux-aio enable Linux AIO support" echo " --disable-attr disables attr and xattr support" echo " --enable-attrenable attr and xattr support" echo " --enable-io-thread enable IO thread" +echo " --disable-io-thread disable IO thread" echo " --disable-blobs disable installing provided firmware blobs" echo " --kerneldir=PATH look for kernel includes in PATH" echo " --enable-docsenable documentation build"
Re: [Qemu-devel] Re: [RFC][PATCH v6 08/23] virtagent: add va.getfile RPC
On 01/24/2011 04:20 PM, Richard W.M. Jones wrote: On Mon, Jan 24, 2011 at 10:08:09PM +, Richard W.M. Jones wrote: You might as well reuse the libguestfs API here because you get the benefit of all the code that's been written, all the tools on top, and a far more comprehensive API that would take you another 2 years to implement. To put it in some perspective, libguestfs is just shy of 500K lines of code now, not including the tools built on top. 150 page manual just for the core API. Yeah, but I think that's the reason that it might not be a good candidate for this use-case. We need a *simple* interface that we can convince everyone to install by default and run in their guests. It needs to be flexible enough that we can do lots of fun things but simple enough that a reasonable person can audit the code in a short period of time. It will never replace something as sophisticated as guestfs but that's not it's point. It's point is to let you do simple things like execute a command in the guest or peek at /proc/meminfo. You don't need 500k LOCs for that. Regards, Anthony Liguori Rich.
[Qemu-devel] Re: [PATCH 4/7] Get rid of QemuMutex and teach its callers about GStaticMutex
On 2011-01-24 22:00, Anthony Liguori wrote: > Signed-off-by: Anthony Liguori > > diff --git a/cpus.c b/cpus.c > index 9cf7e6e..0f8e33b 100644 > --- a/cpus.c > +++ b/cpus.c > @@ -321,8 +321,8 @@ void vm_stop(int reason) > > #include "qemu-thread.h" > > -QemuMutex qemu_global_mutex; > -static QemuMutex qemu_fair_mutex; > +GStaticMutex qemu_global_mutex; > +static GStaticMutex qemu_fair_mutex; > > static QemuThread io_thread; > > @@ -416,9 +416,9 @@ int qemu_init_main_loop(void) > qemu_cond_init(&qemu_system_cond); > qemu_cond_init(&qemu_pause_cond); > qemu_cond_init(&qemu_work_cond); > -qemu_mutex_init(&qemu_fair_mutex); > -qemu_mutex_init(&qemu_global_mutex); > -qemu_mutex_lock(&qemu_global_mutex); > +g_static_mutex_init(&qemu_fair_mutex); > +g_static_mutex_init(&qemu_global_mutex); > +g_static_mutex_lock(&qemu_global_mutex); > Just replacing our own abstraction with glib's looks like a step in the wrong direction. From a first glance at that library and its semantics it has at least two major drawbacks: - Error handling of things like g_mutex_lock or g_cond_wait is, well, very "simplistic". Once we start to use more sophisticated locking, more bugs will occur here, and we will need more support than glib is able to provide (or can you control error handling elsewhere?). - GMutex is not powerful enough for optional things like PI mutexes - which is required once we want to schedule parts of qemu with RT priorities (I did it, it works surprisingly well). The same concerns apply to other abstractions glib provides for threading and synchronization. One may work around them, but that will break abstractions again. Glib seems to fit standard use case quite comfortably but fails in more advanced scenarios qemu is already useable for (just lacking a few additional lines of code). In short: we need full POSIX where available. Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] Re: Errors on MMIO read access on VM suspend / resume operations
On 2011-01-24 19:27, Stefan Berger wrote: > On 01/18/2011 03:53 AM, Jan Kiszka wrote: >> On 2011-01-18 04:03, Stefan Berger wrote: >>> On 01/16/2011 09:43 AM, Avi Kivity wrote: On 01/14/2011 09:27 PM, Stefan Berger wrote: >> Can you sprinkle some printfs() arount kvm_run (in qemu-kvm.c) to >> verify this? >> > Here's what I did: > > > interrupt exit requested It appears from this you're using qemu.git. Please try qemu-kvm.git, where the code appears to be correct. >>> Cc'ing qemu-devel now. For reference, here the initial problem >>> description: >>> >>> http://www.spinics.net/lists/kvm/msg48274.html >>> >>> I didn't know there was another tree... >>> >>> I have seen now a couple of suspends-while-reading with patches applied >>> to the qemu-kvm.git tree and indeed, when run with the same host kernel >>> and VM I do not see the debugging dumps due to double-reads that I would >>> have anticipated seeing by now. Now what? Can this be easily fixed in >>> the other Qemu tree as well? >> Please give this a try: >> >> git://git.kiszka.org/qemu-kvm.git queues/kvm-upstream >> >> I bet (& hope) "kvm: Unconditionally reenter kernel after IO exits" >> fixes the issue for you. If other problems pop up with that tree, also >> try resetting to that particular commit. >> >> I'm currently trying to shake all those hidden or forgotten bug fixes >> out of qemu-kvm and port them upstream. Most of those subtle differences >> should hopefully soon be history. >> > I did the same test as I did with Avi's tree and haven't seen the > consequences of possible double-reads. So, I would say that you should > upstream those patches... > > I searched for the text you mention above using 'gitk' but couldn't find > a patch with that headline in your tree. There were others that seem to > be related: > > Gleb Natapov: "do not enter vcpu again if it was stopped during IO" Err, I don't think you checked out queues/kvm-upstream. I bet you just ran my master branch which is a version of qemu-kvm's master. Am I right? :) >>> One thing I'd like to mention is that I have seen what I think are >>> interrupt stalls when running my tests inside the qemu-kvm.git tree >>> version and not suspending at all. A some point the interrupt counter in >>> the guest kernel does not increase anymore even though I see the device >>> model raising the IRQ and lowering it. The same tests run literally >>> forever in the qemu.git tree version of Qemu. >> What about qemu-kmv and -no-kvm-irqchip? > That seems to be necessary for both trees, yours and the one Avi pointed > me to. If applied, then I did not see the interrupt problem. And the fact that you were able to call qemu from my tree with -no-kvm-irqchip just underlines my assumption: that switch is refused by upstream. Please retry with the latest kvm-upstream queue. Besides that, this other bug you may see in the in-kernel IRQ path - how can we reproduce it? Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] qemu-user: relocating target code weakness
On Mon, Jan 24, 2011 at 17:24, Stefano Bonifazi wrote: >> how can the ldso possibly prevent clashes ? it has no idea what >> addresses an app will ask for at runtime. >> >> plus, if the kernel is employing ASLR (which isnt uncommon nowadays), >> the load addresses could be anywhere. > > Well not alone, in my mind ld.so asks the memory manager through calling > mmap where it can map the shared modules inside the process address space.. > the memory manager should know what addresses are free and which are taken > .. then when the process code requires dynamic memory allocation, it does it > again through the memory manager (i.e. malloc) avoiding of allocating memory > where shared modules have been loaded into.. > Again with ASLR I think the mmu should be aware of all used memory slots, > avoiding conflicts.. i'm not saying conflicts arent noticed. i'm saying that there is no way for the surrounding system (ldso/linux mm/...) to know ahead of time what the app is going to request with MAP_FIXED and thus prevent possible future conflicts. -mike
[Qemu-devel] Re: KVM call agenda for Jan 25
On 01/24/2011 07:25 AM, Chris Wright wrote: Please send in any agenda items you are interested in covering. - coroutines for the block layer - glib everywhere Regards, Anthony Liguori thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: [RFC][PATCH v6 08/23] virtagent: add va.getfile RPC
On Fri, Jan 21, 2011 at 12:23:40PM -0600, Michael Roth wrote: > getfile() is confusingly named however, it's really just a means to > peek at a text file like /proc/meminfo. You might as well reuse the libguestfs API here because you get the benefit of all the code that's been written, all the tools on top, and a far more comprehensive API that would take you another 2 years to implement. There's various ways to do it: Encapsulate the libguestfs API messages to and from guestfsd into the virtagent protocol. Or give us another 8-bit-clean channel. Or write a libguestfs generator component that generates virtagent messages. We got a long way through porting guestfsd to Windows last year when we thought we needed a Windows-native daemon (since abandoned for other reasons). It works already for many of the API calls. > general file access will be done via a stateful interface that > implements similar semantics to open()/read()/write()/close(). This will be very slow. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
Re: [Qemu-devel] Re: [RFC/PATCH] elfload: add FDPIC support
On 01/24/2011 10:27 PM, Mike Frysinger wrote: On Mon, Jan 24, 2011 at 16:06, Stefano Bonifazi wrote: I don't understand.. what is the difference between pie binary for pcc and for your architecture? as i said, i think this is all irrelevant to what you want to do. but since you asked and i feel like writing ... i have no idea what "pcc" is. there are really two stark differences between FDPIC ELF and a PIE ELF on say x86. since the data/text sections can be relocated independently of each other, the PIC cannot assume a fixed offset between its text and GOT. so every PLT entry is actually two sets of addresses -- the function address and the function's GOT address. the other big difference is that an FDPIC ELF app must first do a little relocation processing of itself as soon as it starts ... in order to do so, the kernel provides a loadmap (made up of multiple loadsegs) which describes the executable's PT_LOADs (the addr encoded in the program header and the addr the chunk was actually relocated to) as well as the (optional) executable's interpreter's PT_LOADs. As far as I understood pie code is independent from addresses, so it should not care if the OS running them would have an mmu at all.. it should be just the task of the dynamic linker to relocate it properly, am I wrong? but the PIE code still has fixed offsets between its text and its data. so FDPIC ELF is even more flexible than a PIE ELF. -mike Thank you very much! As a student, understanding how things work is even more precious than making things work ;) You know? I was just trying to figure out today how the code could locate the .got in x86 when relocation is needed.. I am studying ELF and relocation now, reading all possible material online, but I did not find yet about the fixed offset! PPC stands for PowerPC. Now also your code is much clearer for me, though not useful in my case.. Thank you again! Best regards! Stefano B.
Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state
On 2011-01-24 22:35, Blue Swirl wrote: > On Mon, Jan 24, 2011 at 2:08 PM, Jan Kiszka wrote: >> On 2011-01-21 19:49, Blue Swirl wrote: > I'd add fourth possible class: > - device, CPU and machine configuration, like nographic, > win2k_install_hack, no_hpet, smp_cpus etc. Maybe also > irqchip_in_kernel could fit here, though it obviously depends on a > host capability too. I would count everything that cannot be assigned to a concrete device upfront to the dynamic state of a machine, thus class 2. The point is, (potentially) every device of that machine requires access to it, just like (indirectly, via the KVM core services) to some KVM VM state bits. >>> >>> The machine class should not be a catch-all, it would be like >>> QEMUState or KVMState then. Perhaps each field or variable should be >>> listed and given more thought. >> >> Let's start with what is most urgent: >> >> - vmfd: file descriptor required for any KVM request that has VM scope >> (in-kernel device creation, device state synchronizations, IRQ >> routing etc.) > > I'd say VM state. Good. That's +1 for introducing and distributing it. > >> - irqchip_in_kernel: VM uses in-kernel irqchip acceleration >> (some devices will have to adjust their behavior depending on this) > > Since QEMU version is useless, I peeked at qemu-kvm version. > > There are a lot of lines like: > if (kvm_enabled() && !kvm_irqchip_in_kernel()) > kvm_just_do_it(); > > Perhaps these would be cleaner with stub functions. Probably. I guess there is quite some room left for cleanups in this area. > > The device cases are obvious: the devices need a flag, passed to them > by pc.c, which combines kvm_enabled && kvm_irqchip_in_kernel(). This > gets stored in device state. Not all devices are only instantiated by the machine init code. Even if we are lucky that all those we need on x86 are created that way, we shouldn't rely on this for future use case, including other KVM archs. > > But exec.c case, where kvm_update_interrupt_request() is called, is > more interesting. CPU init could set up function pointer to either > stub/NULL or kvm_update_interrupt_request(). > Yes, callbacks are the way to go long term. Here we could also define one for VCPU interrupt handling and set it according to the VCPU mode. > I didn't look at kvm*.c, qemu-kvm*.c or stuff in kvm/. > > So I'd eliminate kvm_irqchip_in_kernel() from outside of KVM and pc.c. > The information could be stored in a MachineState, where pc.c could > grab it for device and CPU setup. I still don't see how we can distribute the information to all interested devices. It's basically the same issue as with current kvm_state. Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] [PATCH 21/23] scsi: Allow scsi_bus_legacy_add_drive() to set removable bit
From: Stefan Hajnoczi
scsi-disk devices may wish to override the removable bit. Add support
for a qdev property on SCSI devices. This is will be used by usb-msd.
Signed-off-by: Stefan Hajnoczi
Signed-off-by: Kevin Wolf
---
hw/pci-hotplug.c |2 +-
hw/scsi-bus.c|8 ++--
hw/scsi.h|3 ++-
hw/usb-msd.c |2 +-
4 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c
index 716133c..270a982 100644
--- a/hw/pci-hotplug.c
+++ b/hw/pci-hotplug.c
@@ -90,7 +90,7 @@ static int scsi_hot_add(Monitor *mon, DeviceState *adapter,
* specified).
*/
dinfo->unit = qemu_opt_get_number(dinfo->opts, "unit", -1);
-scsidev = scsi_bus_legacy_add_drive(scsibus, dinfo->bdrv, dinfo->unit);
+scsidev = scsi_bus_legacy_add_drive(scsibus, dinfo->bdrv, dinfo->unit,
false);
if (!scsidev) {
return -1;
}
diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
index 7febb86..ceeb4ec 100644
--- a/hw/scsi-bus.c
+++ b/hw/scsi-bus.c
@@ -87,7 +87,8 @@ void scsi_qdev_register(SCSIDeviceInfo *info)
}
/* handle legacy '-drive if=scsi,...' cmd line args */
-SCSIDevice *scsi_bus_legacy_add_drive(SCSIBus *bus, BlockDriverState *bdrv,
int unit)
+SCSIDevice *scsi_bus_legacy_add_drive(SCSIBus *bus, BlockDriverState *bdrv,
+ int unit, bool removable)
{
const char *driver;
DeviceState *dev;
@@ -95,6 +96,9 @@ SCSIDevice *scsi_bus_legacy_add_drive(SCSIBus *bus,
BlockDriverState *bdrv, int
driver = bdrv_is_sg(bdrv) ? "scsi-generic" : "scsi-disk";
dev = qdev_create(&bus->qbus, driver);
qdev_prop_set_uint32(dev, "scsi-id", unit);
+if (qdev_prop_exists(dev, "removable")) {
+qdev_prop_set_bit(dev, "removable", removable);
+}
if (qdev_prop_set_drive(dev, "drive", bdrv) < 0) {
qdev_free(dev);
return NULL;
@@ -117,7 +121,7 @@ int scsi_bus_legacy_handle_cmdline(SCSIBus *bus)
continue;
}
qemu_opts_loc_restore(dinfo->opts);
-if (!scsi_bus_legacy_add_drive(bus, dinfo->bdrv, unit)) {
+if (!scsi_bus_legacy_add_drive(bus, dinfo->bdrv, unit, false)) {
res = -1;
break;
}
diff --git a/hw/scsi.h b/hw/scsi.h
index bf02adf..846fbba 100644
--- a/hw/scsi.h
+++ b/hw/scsi.h
@@ -94,7 +94,8 @@ static inline SCSIBus *scsi_bus_from_device(SCSIDevice *d)
return DO_UPCAST(SCSIBus, qbus, d->qdev.parent_bus);
}
-SCSIDevice *scsi_bus_legacy_add_drive(SCSIBus *bus, BlockDriverState *bdrv,
int unit);
+SCSIDevice *scsi_bus_legacy_add_drive(SCSIBus *bus, BlockDriverState *bdrv,
+ int unit, bool removable);
int scsi_bus_legacy_handle_cmdline(SCSIBus *bus);
SCSIRequest *scsi_req_alloc(size_t size, SCSIDevice *d, uint32_t tag, uint32_t
lun);
diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index 729d96c..ccdf8ff 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -515,7 +515,7 @@ static int usb_msd_initfn(USBDevice *dev)
usb_desc_init(dev);
scsi_bus_new(&s->bus, &s->dev.qdev, 0, 1, usb_msd_command_complete);
-s->scsi_dev = scsi_bus_legacy_add_drive(&s->bus, bs, 0);
+s->scsi_dev = scsi_bus_legacy_add_drive(&s->bus, bs, 0, false);
if (!s->scsi_dev) {
return -1;
}
--
1.7.2.3
Re: [Qemu-devel] Re: [RFC 0/7] Introduce hard dependency on glib
On 01/24/2011 03:28 PM, Paolo Bonzini wrote: On 01/24/2011 10:00 PM, Anthony Liguori wrote: Both the recent I/O loop and threadlet series have me concerned that we're digging ourselves deeper into the NIH hole. I think it's time we look at something radical to let us borrow more code from existing projects instead of reinventing everything through trial and error. This series introduces a hard dependency on glib. The initial use is portable threads but I see this as just the beginning. Glib/Gobject offer many nice things including: - portable threads - IO library - rich data structure support These are where GLib shines. - INI parser Not compatible with our config files anyway. - JSON parser I think our JSON parser is much better than JsonGlib (which isn't anyway a part of GLib proper). Not sure how much either of these matter, but we should at least drop QObject and convert our JSON parser to use GValues such that we can treat the JSON parser as a stand alone component. - generic type system - object oriented infrastructure - module system - introspection to enable support for dynamic language bindings See below. I see this series as the first step, followed by converting the I/O loop to a GMainLoop instance. Once we're there, we can start making deeper use of GObjects including converting QDev to a GObject hierarchy. I am not sure how these other bits will look like and maybe it won't make sense at all, but it doesn't matter. The bits you posted are already a step in the right direction IMHO, and the same goes for converting the I/O loop to GMainLoop if you can pull that :) and using glib's thread pool. (Regarding GMainLoop, my main worry is that we'd have to reinvent a lot of GSources to integrate properly with slirp, with QEMU's multiple clocks, and so on. And GSources are black magic...). I've been thinking about this myself. I think slirp is probably best handled as a GSource as much as I don't want to do it. I don't see another option. We can't use the g_timeout_source directly because the interval is milliseconds. Since our clock mechanisms all use signals to generate clock events, I think we can tie it all to a pipe() and just use a GIOChannel to generate events. Obviously, implementing a GSource is the best long term approach but I think there's a reasonable short term one. Regards, Anthony Liguori I'd also add to the benefits a good multi-threaded memory allocator. A small qualm I have is that glib (and GNOME in general) is one of the hardest pieces of free software to contribute to in my experience. I have patches which had multiple acks and are still languishing after a year or so. Still not an excuse for NIH. Paolo
[Qemu-devel] Re: [PULL 00/23] Block patches
On 01/24/2011 03:10 PM, Kevin Wolf wrote: The following changes since commit 0bfe006c5380c5f8a485a55ded3329fbbc224396: multiboot: Fix upper memory size in multiboot info (2011-01-23 22:44:13 +0100) are available in the git repository at: git://repo.or.cz/qemu/kevin.git for-anthony Pulled. Thanks. Regards, Anthony Liguori Aurelien Jarno (1): qcow2: fix unaligned access Christoph Hellwig (3): ide: factor dma handling helpers ide: also reset io_buffer_index for writes ide: kill ide_dma_submit_check Jes Sorensen (2): do_snapshot_blkdev() error on missing snapshot_file argument Make strtosz() return int64_t instead of ssize_t Kevin Wolf (5): qemu-img snapshot: Use writeback caching qcow2: Add QcowCache qcow2: Use QcowCache qcow2: Batch flushes for COW Documentation: Add qemu-img check/rebase Markus Armbruster (3): blockdev: Fix error message for invalid -drive CHS blockdev: Make drive_init() use error_report() blockdev: Fix drive_del not to crash when drive is not in use Pierre Riteau (2): Avoid divide by zero when there is no block device to migrate Fix block migration when the device size is not a multiple of 1 MB Stefan Hajnoczi (6): qed: Refuse to create images on block devices block: Use backing format driver during image creation scsi-disk: Allow overriding SCSI INQUIRY removable bit scsi: Allow scsi_bus_legacy_add_drive() to set removable bit usb-msd: Propagate removable bit to SCSI device docs: Document scsi-disk and usb-storage removable parameter Stefan Weil (1): ide: Remove unneeded null pointer check Makefile.objs|2 +- block-migration.c| 29 - block.c |8 +- block/qcow2-cache.c | 314 ++ block/qcow2-cluster.c| 210 +++ block/qcow2-refcount.c | 260 -- block/qcow2.c| 48 +++- block/qcow2.h| 32 - block/qed.c |6 + blockdev.c | 81 +++-- cutils.c |8 +- docs/qdev-device-use.txt | 13 ++- hw/ide/core.c| 113 ++--- hw/ide/internal.h|4 +- hw/ide/pci.c | 13 +-- hw/pci-hotplug.c |2 +- hw/scsi-bus.c|8 +- hw/scsi-disk.c |3 + hw/scsi.h|3 +- hw/usb-msd.c |4 +- monitor.c|2 +- qemu-common.h|4 +- qemu-img.c |4 +- qemu-img.texi| 41 ++ vl.c |4 +- 25 files changed, 764 insertions(+), 452 deletions(-) create mode 100644 block/qcow2-cache.c
[Qemu-devel] [PATCH 23/23] docs: Document scsi-disk and usb-storage removable parameter
From: Stefan Hajnoczi Signed-off-by: Stefan Hajnoczi Signed-off-by: Kevin Wolf --- docs/qdev-device-use.txt | 13 +++-- 1 files changed, 11 insertions(+), 2 deletions(-) diff --git a/docs/qdev-device-use.txt b/docs/qdev-device-use.txt index f2f9b75..4bb2be8 100644 --- a/docs/qdev-device-use.txt +++ b/docs/qdev-device-use.txt @@ -80,7 +80,11 @@ The -device argument differs in detail for each kind of drive: This SCSI controller a single SCSI bus, named ID.0. Put a disk on it: - -device scsi-disk,drive=DRIVE-ID,bus=ID.0,scsi-id=SCSI-ID + -device scsi-disk,drive=DRIVE-ID,bus=ID.0,scsi-id=SCSI-ID,removable=RMB + + The (optional) removable parameter lets you override the SCSI INQUIRY + removable (RMB) bit for non CD-ROM devices. It is ignored for CD-ROM devices + which are always removable. RMB is "on" or "off". * if=floppy @@ -116,7 +120,12 @@ For USB devices, the old way is actually different: Provides much less control than -drive's HOST-OPTS... The new way fixes that: --device usb-storage,drive=DRIVE-ID +-device usb-storage,drive=DRIVE-ID,removable=RMB + +The removable parameter gives control over the SCSI INQUIRY removable (RMB) +bit. USB thumbdrives usually set removable=on, while USB hard disks set +removable=off. See the if=scsi description above for details on the removable +parameter, which applies only to scsi-disk devices and not to scsi-generic. === Character Devices === -- 1.7.2.3
Re: [Qemu-devel] qemu-user: relocating target code weakness
but that can happen with the app running natively too, so any app not handling MAP_FIXED failures is buggy and not qemu's problem. -mike How? For what I learned each process executing on a OS with an mmu sees its virtual address space, and normally only its code is loaded there (well I am learning that the dynamic linker also inject into that space shared library code used by the process code, but of course a good dynamic linker would prevent clashes!) so how can it happen that it can clash with anything?? If I remember fine, at the time of DOS there were some addresses reserved for the OS, and then only one executable could run at time, but in modern time with virtual addressing I don't think it is possible other than in scenarios alike ours.. Regards, Stefano B.
[Qemu-devel] [PATCH 22/23] usb-msd: Propagate removable bit to SCSI device
From: Stefan Hajnoczi
USB Mass Storage Devices sometimes have the RMB (removable) bit set in
the SCSI INQUIRY response. Thumbdrives tend to have the bit set whereas
hard disks do not.
Operating systems differentiate between removable devices and fixed
devices. Under Linux, the anaconda installer looks for removable
devices. Under Windows, only fixed devices may have more than one
partition and AutoRun is also affected by the removable bit.
For these reasons, allow USB Mass Storage Devices to override the
removable bit:
qemu -usb
-drive if=none,file=test.img,cache=none,id=disk0
-device usb-storage,drive=disk0,removable=on
The default is off.
Signed-off-by: Stefan Hajnoczi
Signed-off-by: Kevin Wolf
---
hw/usb-msd.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index ccdf8ff..11722c7 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -51,6 +51,7 @@ typedef struct {
SCSIBus bus;
BlockConf conf;
SCSIDevice *scsi_dev;
+uint32_t removable;
int result;
/* For async completion. */
USBPacket *packet;
@@ -515,7 +516,7 @@ static int usb_msd_initfn(USBDevice *dev)
usb_desc_init(dev);
scsi_bus_new(&s->bus, &s->dev.qdev, 0, 1, usb_msd_command_complete);
-s->scsi_dev = scsi_bus_legacy_add_drive(&s->bus, bs, 0, false);
+s->scsi_dev = scsi_bus_legacy_add_drive(&s->bus, bs, 0, !!s->removable);
if (!s->scsi_dev) {
return -1;
}
@@ -607,6 +608,7 @@ static struct USBDeviceInfo msd_info = {
.usbdevice_init = usb_msd_init,
.qdev.props = (Property[]) {
DEFINE_BLOCK_PROPERTIES(MSDState, conf),
+DEFINE_PROP_BIT("removable", MSDState, removable, 0, false),
DEFINE_PROP_END_OF_LIST(),
},
};
--
1.7.2.3
Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state
On Mon, Jan 24, 2011 at 2:08 PM, Jan Kiszka wrote: > On 2011-01-21 19:49, Blue Swirl wrote: I'd add fourth possible class: - device, CPU and machine configuration, like nographic, win2k_install_hack, no_hpet, smp_cpus etc. Maybe also irqchip_in_kernel could fit here, though it obviously depends on a host capability too. >>> >>> I would count everything that cannot be assigned to a concrete device >>> upfront to the dynamic state of a machine, thus class 2. The point is, >>> (potentially) every device of that machine requires access to it, just >>> like (indirectly, via the KVM core services) to some KVM VM state bits. >> >> The machine class should not be a catch-all, it would be like >> QEMUState or KVMState then. Perhaps each field or variable should be >> listed and given more thought. > > Let's start with what is most urgent: > > - vmfd: file descriptor required for any KVM request that has VM scope > (in-kernel device creation, device state synchronizations, IRQ > routing etc.) I'd say VM state. > - irqchip_in_kernel: VM uses in-kernel irqchip acceleration > (some devices will have to adjust their behavior depending on this) Since QEMU version is useless, I peeked at qemu-kvm version. There are a lot of lines like: if (kvm_enabled() && !kvm_irqchip_in_kernel()) kvm_just_do_it(); Perhaps these would be cleaner with stub functions. The device cases are obvious: the devices need a flag, passed to them by pc.c, which combines kvm_enabled && kvm_irqchip_in_kernel(). This gets stored in device state. But exec.c case, where kvm_update_interrupt_request() is called, is more interesting. CPU init could set up function pointer to either stub/NULL or kvm_update_interrupt_request(). I didn't look at kvm*.c, qemu-kvm*.c or stuff in kvm/. So I'd eliminate kvm_irqchip_in_kernel() from outside of KVM and pc.c. The information could be stored in a MachineState, where pc.c could grab it for device and CPU setup.
[Qemu-devel] [PATCH 18/23] blockdev: Fix drive_del not to crash when drive is not in use
From: Markus Armbruster
Watch this:
(qemu) drive_add 0 if=none,file=tmp.img
OK
(qemu) info block
none0: type=hd removable=0 file=tmp.img ro=0 drv=raw encrypted=0
(qemu) drive_del none0
Segmentation fault (core dumped)
do_drive_del()'s code to clean up the pointer from a qdev using the
drive back to the drive needs to check whether such a device exists.
Signed-off-by: Markus Armbruster
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Kevin Wolf
---
blockdev.c | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 0621390..f7f591f 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -687,13 +687,15 @@ int do_drive_del(Monitor *mon, const QDict *qdict,
QObject **ret_data)
/* clean up guest state from pointing to host resource by
* finding and removing DeviceState "drive" property */
-for (prop = bs->peer->info->props; prop && prop->name; prop++) {
-if (prop->info->type == PROP_TYPE_DRIVE) {
-ptr = qdev_get_prop_ptr(bs->peer, prop);
-if ((*ptr) == bs) {
-bdrv_detach(bs, bs->peer);
-*ptr = NULL;
-break;
+if (bs->peer) {
+for (prop = bs->peer->info->props; prop && prop->name; prop++) {
+if (prop->info->type == PROP_TYPE_DRIVE) {
+ptr = qdev_get_prop_ptr(bs->peer, prop);
+if (*ptr == bs) {
+bdrv_detach(bs, bs->peer);
+*ptr = NULL;
+break;
+}
}
}
}
--
1.7.2.3
[Qemu-devel] [PATCH 17/23] blockdev: Make drive_init() use error_report()
From: Markus Armbruster
This makes the errors point to the error location, and fixes drive_add
to report errors in the monitor instead of stderr.
While there, tweak a few error messages for consistency.
Signed-off-by: Markus Armbruster
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Kevin Wolf
---
blockdev.c | 59 ---
1 files changed, 28 insertions(+), 31 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 28c051b..0621390 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -107,7 +107,7 @@ DriveInfo *drive_get_by_blockdev(BlockDriverState *bs)
static void bdrv_format_print(void *opaque, const char *name)
{
-fprintf(stderr, " %s", name);
+error_printf(" %s", name);
}
void drive_uninit(DriveInfo *dinfo)
@@ -129,8 +129,8 @@ static int parse_block_error_action(const char *buf, int
is_read)
} else if (!strcmp(buf, "report")) {
return BLOCK_ERR_REPORT;
} else {
-fprintf(stderr, "qemu: '%s' invalid %s error action\n",
-buf, is_read ? "read" : "write");
+error_report("'%s' invalid %s error action",
+ buf, is_read ? "read" : "write");
return -1;
}
}
@@ -217,31 +217,30 @@ DriveInfo *drive_init(QemuOpts *opts, int
default_to_scsi, int *fatal_error)
type = IF_NONE;
max_devs = 0;
} else {
-fprintf(stderr, "qemu: unsupported bus type '%s'\n", buf);
+error_report("unsupported bus type '%s'", buf);
return NULL;
}
}
if (cyls || heads || secs) {
if (cyls < 1 || (type == IF_IDE && cyls > 16383)) {
-fprintf(stderr, "qemu: invalid physical cyls number\n");
+error_report("invalid physical cyls number");
return NULL;
}
if (heads < 1 || (type == IF_IDE && heads > 16)) {
-fprintf(stderr, "qemu: invalid physical heads number\n");
+error_report("invalid physical heads number");
return NULL;
}
if (secs < 1 || (type == IF_IDE && secs > 63)) {
-fprintf(stderr, "qemu: invalid physical secs number\n");
+error_report("invalid physical secs number");
return NULL;
}
}
if ((buf = qemu_opt_get(opts, "trans")) != NULL) {
if (!cyls) {
-fprintf(stderr,
-"qemu: '%s' trans must be used with cyls,heads and secs\n",
-buf);
+error_report("'%s' trans must be used with cyls,heads and secs",
+ buf);
return NULL;
}
if (!strcmp(buf, "none"))
@@ -251,7 +250,7 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi,
int *fatal_error)
else if (!strcmp(buf, "auto"))
translation = BIOS_ATA_TRANSLATION_AUTO;
else {
-fprintf(stderr, "qemu: '%s' invalid translation type\n", buf);
+error_report("'%s' invalid translation type", buf);
return NULL;
}
}
@@ -261,13 +260,12 @@ DriveInfo *drive_init(QemuOpts *opts, int
default_to_scsi, int *fatal_error)
media = MEDIA_DISK;
} else if (!strcmp(buf, "cdrom")) {
if (cyls || secs || heads) {
-fprintf(stderr,
-"qemu: '%s' invalid physical CHS format\n", buf);
+error_report("'%s' invalid physical CHS format", buf);
return NULL;
}
media = MEDIA_CDROM;
} else {
- fprintf(stderr, "qemu: '%s' invalid media\n", buf);
+ error_report("'%s' invalid media", buf);
return NULL;
}
}
@@ -283,7 +281,7 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi,
int *fatal_error)
} else if (!strcmp(buf, "writethrough")) {
/* this is the default */
} else {
- fprintf(stderr, "qemu: invalid cache option\n");
+ error_report("invalid cache option");
return NULL;
}
}
@@ -295,7 +293,7 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi,
int *fatal_error)
} else if (!strcmp(buf, "threads")) {
/* this is the default */
} else {
- fprintf(stderr, "qemu: invalid aio option\n");
+ error_report("invalid aio option");
return NULL;
}
}
@@ -303,14 +301,14 @@ DriveInfo *drive_init(QemuOpts *opts, int
default_to_scsi, int *fatal_error)
if ((buf = qemu_opt_get(opts, "format")) != NULL) {
if (strcmp(buf, "?") == 0) {
-fprintf(stderr, "qemu: Supported formats:");
-bdrv_iterate_format(bdrv_format_print, NULL);
-fprintf(stderr, "\n");
- return NULL;
+ error_printf("Supported formats:");
+ bdrv_iterate_format(bdrv_format_print, NULL);
+ error_printf("\n");
+ return NULL;
}
drv = bdr
Re: [Qemu-devel] Re: [RFC/PATCH] elfload: add FDPIC support
On Mon, Jan 24, 2011 at 16:06, Stefano Bonifazi wrote: > I don't understand.. what is the difference between pie binary for pcc and > for your architecture? as i said, i think this is all irrelevant to what you want to do. but since you asked and i feel like writing ... i have no idea what "pcc" is. there are really two stark differences between FDPIC ELF and a PIE ELF on say x86. since the data/text sections can be relocated independently of each other, the PIC cannot assume a fixed offset between its text and GOT. so every PLT entry is actually two sets of addresses -- the function address and the function's GOT address. the other big difference is that an FDPIC ELF app must first do a little relocation processing of itself as soon as it starts ... in order to do so, the kernel provides a loadmap (made up of multiple loadsegs) which describes the executable's PT_LOADs (the addr encoded in the program header and the addr the chunk was actually relocated to) as well as the (optional) executable's interpreter's PT_LOADs. > As far as I understood pie code is independent from addresses, so it should > not care if the OS running them would have an mmu at all.. it should be just > the task of the dynamic linker to relocate it properly, am I wrong? but the PIE code still has fixed offsets between its text and its data. so FDPIC ELF is even more flexible than a PIE ELF. -mike
[Qemu-devel] [PATCH 15/23] Fix block migration when the device size is not a multiple of 1 MB
From: Pierre Riteau
b02bea3a85cc939f09aa674a3f1e4f36d418c007 added a check on the return
value of bdrv_write and aborts migration when it fails. However, if the
size of the block device to migrate is not a multiple of BLOCK_SIZE
(currently 1 MB), the last bdrv_write will fail with -EIO.
Fixed by calling bdrv_write with the correct size of the last block.
Signed-off-by: Pierre Riteau
Signed-off-by: Kevin Wolf
---
block-migration.c | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index 60b9fc0..c9d3e81 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -638,8 +638,10 @@ static int block_load(QEMUFile *f, void *opaque, int
version_id)
int len, flags;
char device_name[256];
int64_t addr;
-BlockDriverState *bs;
+BlockDriverState *bs, *bs_prev = NULL;
uint8_t *buf;
+int64_t total_sectors = 0;
+int nr_sectors;
do {
addr = qemu_get_be64(f);
@@ -661,10 +663,26 @@ static int block_load(QEMUFile *f, void *opaque, int
version_id)
return -EINVAL;
}
+if (bs != bs_prev) {
+bs_prev = bs;
+total_sectors = bdrv_getlength(bs) >> BDRV_SECTOR_BITS;
+if (total_sectors <= 0) {
+error_report("Error getting length of block device %s\n",
+ device_name);
+return -EINVAL;
+}
+}
+
+if (total_sectors - addr < BDRV_SECTORS_PER_DIRTY_CHUNK) {
+nr_sectors = total_sectors - addr;
+} else {
+nr_sectors = BDRV_SECTORS_PER_DIRTY_CHUNK;
+}
+
buf = qemu_malloc(BLOCK_SIZE);
qemu_get_buffer(f, buf, BLOCK_SIZE);
-ret = bdrv_write(bs, addr, buf, BDRV_SECTORS_PER_DIRTY_CHUNK);
+ret = bdrv_write(bs, addr, buf, nr_sectors);
qemu_free(buf);
if (ret < 0) {
--
1.7.2.3
[Qemu-devel] Re: [RFC 0/7] Introduce hard dependency on glib
On 01/24/2011 10:00 PM, Anthony Liguori wrote: Both the recent I/O loop and threadlet series have me concerned that we're digging ourselves deeper into the NIH hole. I think it's time we look at something radical to let us borrow more code from existing projects instead of reinventing everything through trial and error. This series introduces a hard dependency on glib. The initial use is portable threads but I see this as just the beginning. Glib/Gobject offer many nice things including: - portable threads - IO library - rich data structure support These are where GLib shines. - INI parser Not compatible with our config files anyway. - JSON parser I think our JSON parser is much better than JsonGlib (which isn't anyway a part of GLib proper). - generic type system - object oriented infrastructure - module system - introspection to enable support for dynamic language bindings See below. I see this series as the first step, followed by converting the I/O loop to a GMainLoop instance. Once we're there, we can start making deeper use of GObjects including converting QDev to a GObject hierarchy. I am not sure how these other bits will look like and maybe it won't make sense at all, but it doesn't matter. The bits you posted are already a step in the right direction IMHO, and the same goes for converting the I/O loop to GMainLoop if you can pull that :) and using glib's thread pool. (Regarding GMainLoop, my main worry is that we'd have to reinvent a lot of GSources to integrate properly with slirp, with QEMU's multiple clocks, and so on. And GSources are black magic...). I'd also add to the benefits a good multi-threaded memory allocator. A small qualm I have is that glib (and GNOME in general) is one of the hardest pieces of free software to contribute to in my experience. I have patches which had multiple acks and are still languishing after a year or so. Still not an excuse for NIH. Paolo
[Qemu-devel] [PATCH 13/23] Documentation: Add qemu-img check/rebase
Signed-off-by: Kevin Wolf
---
qemu-img.texi | 41 +
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/qemu-img.texi b/qemu-img.texi
index 1b90ddb..ced64a4 100644
--- a/qemu-img.texi
+++ b/qemu-img.texi
@@ -59,6 +59,13 @@ lists all snapshots in the given image
Command description:
@table @option
+@item check [-f @var{fmt}] @var{filename}
+
+Perform a consistency check on the disk image @var{filename}.
+
+Only the formats @code{qcow2}, @code{qed} and @code{vdi} support
+consistency checks.
+
@item create [-f @var{fmt}] [-o @var{options}] @var{filename} [@var{size}]
Create the new disk image @var{filename} of size @var{size} and format
@@ -107,6 +114,40 @@ they are displayed too.
List, apply, create or delete snapshots in image @var{filename}.
+@item rebase [-f @var{fmt}] [-u] -b @var{backing_file} [-F @var{backing_fmt}]
@var{filename}
+
+Changes the backing file of an image. Only the formats @code{qcow2} and
+@code{qed} support changing the backing file.
+
+The backing file is changed to @var{backing_file} and (if the image format of
+@var{filename} supports this) the backing file format is changed to
+@var{backing_fmt}.
+
+There are two different modes in which @code{rebase} can operate:
+@table @option
+@item Safe mode
+This is the default mode and performs a real rebase operation. The new backing
+file may differ from the old one and qemu-img rebase will take care of keeping
+the guest-visible content of @var{filename} unchanged.
+
+In order to achieve this, any clusters that differ between @var{backing_file}
+and the old backing file of @var{filename} are merged into @var{filename}
+before actually changing the backing file.
+
+Note that the safe mode is an expensive operation, comparable to converting
+an image. It only works if the old backing file still exists.
+
+@item Unsafe mode
+qemu-img uses the unsafe mode if @code{-u} is specified. In this mode, only the
+backing file name and format of @var{filename} is changed without any checks
+on the file contents. The user must take care of specifying the correct new
+backing file, or the guest-visible content of the image will be corrupted.
+
+This mode is useful for renaming or moving the backing file to somewhere else.
+It can be used without an accessible old backing file, i.e. you can use it to
+fix an image whose backing file has already been moved/renamed.
+@end table
+
@item resize @var{filename} [+ | -]@var{size}
Change the disk image as if it had been created with @var{size}.
--
1.7.2.3
Re: [Qemu-devel] qemu-user: relocating target code weakness
On Mon, Jan 24, 2011 at 15:58, Stefano Bonifazi wrote: >> review the mmap() man page ... MAP_FIXED is always a *suggestion* and >> never a requirement. the app must check the return value to see what >> the kernel actually gave it. > > Sorry, wrong! > > MAP_FIXED > Don't interpret addr as a hint: place the mapping at exactly > that > address. [] If the specified address cannot be used, mmap() > will fail.[] err, yes. i was thinking the specified address when MAP_FIXED isnt used. since qemu itself has its own mappings, there is a slightly greater possibility of the simulated program making a MAP_FIXED request that clashes with qemu itself, or with addresses that are free in the simulated arch's ABI but reserved in the host processor's ABI. but that can happen with the app running natively too, so any app not handling MAP_FIXED failures is buggy and not qemu's problem. -mike
Re: [Qemu-devel] TCG flow vs dyngen
Hi! Thanks for replying me! The thing is, the kernel currently _does_ work, so studying the relevant kernel code (and possibly the dynamic loader code) is one way to learn how it currently works. Sorry what kernel? Qemu's? Linux's?
[Qemu-devel] [PATCH 16/23] blockdev: Fix error message for invalid -drive CHS
From: Markus Armbruster
When cyls, heads or secs are out of range, the error message prints
buf, which points to the value of option "if". Bogus, may even be
null. Drop that.
Signed-off-by: Markus Armbruster
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Kevin Wolf
---
blockdev.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index 662f7a9..28c051b 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -224,15 +224,15 @@ DriveInfo *drive_init(QemuOpts *opts, int
default_to_scsi, int *fatal_error)
if (cyls || heads || secs) {
if (cyls < 1 || (type == IF_IDE && cyls > 16383)) {
-fprintf(stderr, "qemu: '%s' invalid physical cyls number\n", buf);
+fprintf(stderr, "qemu: invalid physical cyls number\n");
return NULL;
}
if (heads < 1 || (type == IF_IDE && heads > 16)) {
-fprintf(stderr, "qemu: '%s' invalid physical heads number\n", buf);
+fprintf(stderr, "qemu: invalid physical heads number\n");
return NULL;
}
if (secs < 1 || (type == IF_IDE && secs > 63)) {
-fprintf(stderr, "qemu: '%s' invalid physical secs number\n", buf);
+fprintf(stderr, "qemu: invalid physical secs number\n");
return NULL;
}
}
--
1.7.2.3
[Qemu-devel] [PATCH 08/23] ide: kill ide_dma_submit_check
From: Christoph Hellwig
Merge ide_dma_submit_check into it's only caller. Also use tail recursion
using a goto instead of a real recursion - this avoid overflowing the
stack in the pathological situation of an recurring error that is ignored.
We'll still be busy looping in ide_dma_cb, but at least won't eat up
all stack space after this.
Signed-off-by: Christoph Hellwig
Signed-off-by: Kevin Wolf
---
hw/ide/core.c | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 12b9c53..e698c13 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -321,14 +321,6 @@ static inline void ide_abort_command(IDEState *s)
s->error = ABRT_ERR;
}
-static inline void ide_dma_submit_check(IDEState *s,
- BlockDriverCompletionFunc *dma_cb)
-{
-if (s->bus->dma->aiocb)
- return;
-dma_cb(s, -1);
-}
-
/* prepare data transfer and tell what to do after */
static void ide_transfer_start(IDEState *s, uint8_t *buf, int size,
EndTransferFunc *end_transfer_func)
@@ -493,6 +485,7 @@ void ide_dma_cb(void *opaque, int ret)
int n;
int64_t sector_num;
+handle_rw_error:
if (ret < 0) {
int op = BM_STATUS_DMA_RETRY;
@@ -538,7 +531,11 @@ void ide_dma_cb(void *opaque, int ret)
s->bus->dma->aiocb = dma_bdrv_write(s->bs, &s->sg, sector_num,
ide_dma_cb, s);
}
-ide_dma_submit_check(s, ide_dma_cb);
+
+if (!s->bus->dma->aiocb) {
+ret = -1;
+goto handle_rw_error;
+}
return;
eot:
--
1.7.2.3
[Qemu-devel] [PATCH 19/23] block: Use backing format driver during image creation
From: Stefan Hajnoczi
The backing format should be honored during image creation. For some
reason we currently use the image format to open the backing file. This
fails when the backing file has a different format than the image being
created. Keep the image and backing format drivers completely separate.
Also print the backing filename if there is an error opening the backing
file instead of the image filename.
Signed-off-by: Stefan Hajnoczi
Acked-by: Jes Sorensen
Signed-off-by: Kevin Wolf
---
block.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/block.c b/block.c
index ff2795b..7ad3ddf 100644
--- a/block.c
+++ b/block.c
@@ -2778,6 +2778,7 @@ int bdrv_img_create(const char *filename, const char *fmt,
QEMUOptionParameter *backing_fmt, *backing_file;
BlockDriverState *bs = NULL;
BlockDriver *drv, *proto_drv;
+BlockDriver *backing_drv = NULL;
int ret = 0;
/* Find driver and parse its options */
@@ -2846,7 +2847,8 @@ int bdrv_img_create(const char *filename, const char *fmt,
backing_fmt = get_option_parameter(param, BLOCK_OPT_BACKING_FMT);
if (backing_fmt && backing_fmt->value.s) {
-if (!bdrv_find_format(backing_fmt->value.s)) {
+backing_drv = bdrv_find_format(backing_fmt->value.s);
+if (!backing_drv) {
error_report("Unknown backing file format '%s'",
backing_fmt->value.s);
ret = -EINVAL;
@@ -2863,9 +2865,9 @@ int bdrv_img_create(const char *filename, const char *fmt,
bs = bdrv_new("");
-ret = bdrv_open(bs, backing_file->value.s, flags, drv);
+ret = bdrv_open(bs, backing_file->value.s, flags, backing_drv);
if (ret < 0) {
-error_report("Could not open '%s'", filename);
+error_report("Could not open '%s'", backing_file->value.s);
goto out;
}
bdrv_get_geometry(bs, &size);
--
1.7.2.3
[Qemu-devel] [PATCH 12/23] ide: Remove unneeded null pointer check
From: Stefan Weil
With bm == NULL, other code in the same function would crash.
This bug was reported by cppcheck:
hw/ide/pci.c:280: error: Possible null pointer dereference: bm
Cc: Michael S. Tsirkin
Signed-off-by: Stefan Weil
Signed-off-by: Kevin Wolf
---
hw/ide/pci.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/hw/ide/pci.c b/hw/ide/pci.c
index 987caff..35168cb 100644
--- a/hw/ide/pci.c
+++ b/hw/ide/pci.c
@@ -267,9 +267,7 @@ static void bmdma_irq(void *opaque, int n, int level)
return;
}
-if (bm) {
-bm->status |= BM_STATUS_INT;
-}
+bm->status |= BM_STATUS_INT;
/* trigger the real irq */
qemu_set_irq(bm->irq, level);
--
1.7.2.3
[Qemu-devel] [PATCH 06/23] ide: factor dma handling helpers
From: Christoph Hellwig
Factor the DMA I/O path that is duplicated between read and write
commands, into common helpers using the s->is_read flag added for
the macio ATA controller.
Signed-off-by: Christoph Hellwig
Signed-off-by: Kevin Wolf
---
hw/ide/core.c | 103 +
hw/ide/internal.h |4 +--
hw/ide/pci.c |9 +
3 files changed, 36 insertions(+), 80 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 9496e99..e93dd46 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -487,16 +487,18 @@ static int ide_handle_rw_error(IDEState *s, int error,
int op)
return 1;
}
-void ide_read_dma_cb(void *opaque, int ret)
+void ide_dma_cb(void *opaque, int ret)
{
IDEState *s = opaque;
int n;
int64_t sector_num;
if (ret < 0) {
-if (ide_handle_rw_error(s, -ret,
-BM_STATUS_DMA_RETRY | BM_STATUS_RETRY_READ))
-{
+int op = BM_STATUS_DMA_RETRY;
+
+if (s->is_read)
+op |= BM_STATUS_RETRY_READ;
+if (ide_handle_rw_error(s, -ret, op)) {
return;
}
}
@@ -504,7 +506,7 @@ void ide_read_dma_cb(void *opaque, int ret)
n = s->io_buffer_size >> 9;
sector_num = ide_get_sector(s);
if (n > 0) {
-dma_buf_commit(s, 1);
+dma_buf_commit(s, s->is_read);
sector_num += n;
ide_set_sector(s, sector_num);
s->nsector -= n;
@@ -514,32 +516,44 @@ void ide_read_dma_cb(void *opaque, int ret)
if (s->nsector == 0) {
s->status = READY_STAT | SEEK_STAT;
ide_set_irq(s->bus);
-eot:
-s->bus->dma->ops->add_status(s->bus->dma, BM_STATUS_INT);
-ide_set_inactive(s);
-return;
+goto eot;
}
/* launch next transfer */
n = s->nsector;
-s->io_buffer_index = 0;
+if (s->is_read)
+s->io_buffer_index = 0;
s->io_buffer_size = n * 512;
-if (s->bus->dma->ops->prepare_buf(s->bus->dma, 1) == 0)
+if (s->bus->dma->ops->prepare_buf(s->bus->dma, s->is_read) == 0)
goto eot;
+
#ifdef DEBUG_AIO
-printf("aio_read: sector_num=%" PRId64 " n=%d\n", sector_num, n);
+printf("ide_dma_cb: sector_num=%" PRId64 " n=%d, is_read=%d\n",
+ sector_num, n, s->is_read);
#endif
-s->bus->dma->aiocb = dma_bdrv_read(s->bs, &s->sg, sector_num,
ide_read_dma_cb, s);
-ide_dma_submit_check(s, ide_read_dma_cb);
+
+if (s->is_read) {
+s->bus->dma->aiocb = dma_bdrv_read(s->bs, &s->sg, sector_num,
+ ide_dma_cb, s);
+} else {
+s->bus->dma->aiocb = dma_bdrv_write(s->bs, &s->sg, sector_num,
+ide_dma_cb, s);
+}
+ide_dma_submit_check(s, ide_dma_cb);
+return;
+
+eot:
+ s->bus->dma->ops->add_status(s->bus->dma, BM_STATUS_INT);
+ ide_set_inactive(s);
}
-static void ide_sector_read_dma(IDEState *s)
+static void ide_sector_start_dma(IDEState *s, int is_read)
{
s->status = READY_STAT | SEEK_STAT | DRQ_STAT | BUSY_STAT;
s->io_buffer_index = 0;
s->io_buffer_size = 0;
-s->is_read = 1;
-s->bus->dma->ops->start_dma(s->bus->dma, s, ide_read_dma_cb);
+s->is_read = is_read;
+s->bus->dma->ops->start_dma(s->bus->dma, s, ide_dma_cb);
}
static void ide_sector_write_timer_cb(void *opaque)
@@ -594,57 +608,6 @@ void ide_sector_write(IDEState *s)
}
}
-void ide_write_dma_cb(void *opaque, int ret)
-{
-IDEState *s = opaque;
-int n;
-int64_t sector_num;
-
-if (ret < 0) {
-if (ide_handle_rw_error(s, -ret, BM_STATUS_DMA_RETRY))
-return;
-}
-
-n = s->io_buffer_size >> 9;
-sector_num = ide_get_sector(s);
-if (n > 0) {
-dma_buf_commit(s, 0);
-sector_num += n;
-ide_set_sector(s, sector_num);
-s->nsector -= n;
-}
-
-/* end of transfer ? */
-if (s->nsector == 0) {
-s->status = READY_STAT | SEEK_STAT;
-ide_set_irq(s->bus);
-eot:
-s->bus->dma->ops->add_status(s->bus->dma, BM_STATUS_INT);
-ide_set_inactive(s);
-return;
-}
-
-n = s->nsector;
-s->io_buffer_size = n * 512;
-/* launch next transfer */
-if (s->bus->dma->ops->prepare_buf(s->bus->dma, 0) == 0)
-goto eot;
-#ifdef DEBUG_AIO
-printf("aio_write: sector_num=%" PRId64 " n=%d\n", sector_num, n);
-#endif
-s->bus->dma->aiocb = dma_bdrv_write(s->bs, &s->sg, sector_num,
ide_write_dma_cb, s);
-ide_dma_submit_check(s, ide_write_dma_cb);
-}
-
-static void ide_sector_write_dma(IDEState *s)
-{
-s->status = READY_STAT | SEEK_STAT | DRQ_STAT | BUSY_STAT;
-s->io_buffer_index = 0;
-s->io_buffer_size = 0;
-s->is_read = 0;
-s->bus->dma->ops->start_dma(s->bus->dma, s, ide_write_dma_cb);
-}
-
void ide_atapi_cmd_ok(IDEState *s)
{
s->error = 0;
@@ -1858,7 +1821,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
if (!s->bs)
goto abor
[Qemu-devel] [PATCH 14/23] qed: Refuse to create images on block devices
From: Stefan Hajnoczi
QED relies on the underlying filesystem to extend the file and maintain
its size. Check that images are not created on a block device.
Signed-off-by: Stefan Hajnoczi
Signed-off-by: Kevin Wolf
---
block/qed.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/block/qed.c b/block/qed.c
index 085c4f2..a46f9ef 100644
--- a/block/qed.c
+++ b/block/qed.c
@@ -469,6 +469,12 @@ static int qed_create(const char *filename, uint32_t
cluster_size,
return ret;
}
+/* File must start empty and grow, check truncate is supported */
+ret = bdrv_truncate(bs, 0);
+if (ret < 0) {
+goto out;
+}
+
if (backing_file) {
header.features |= QED_F_BACKING_FILE;
header.backing_filename_offset = sizeof(le_header);
--
1.7.2.3
[Qemu-devel] [PATCH 20/23] scsi-disk: Allow overriding SCSI INQUIRY removable bit
From: Stefan Hajnoczi
Provide the "removable" qdev property bit to override the SCSI INQUIRY
removable (RMB) bit for non-CDROM devices. This will be used by USB
Mass Storage Devices, which sometimes have this guest-visible bit set
and sometimes do not. They therefore requires a means for user
configuration.
Signed-off-by: Stefan Hajnoczi
Signed-off-by: Kevin Wolf
---
hw/scsi-disk.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 6cb317c..488eedd 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -72,6 +72,7 @@ struct SCSIDiskState
/* The qemu block layer uses a fixed 512 byte sector size.
This is the number of 512 byte blocks in a single scsi sector. */
int cluster_size;
+uint32_t removable;
uint64_t max_lba;
QEMUBH *bh;
char *version;
@@ -552,6 +553,7 @@ static int scsi_disk_emulate_inquiry(SCSIRequest *req,
uint8_t *outbuf)
memcpy(&outbuf[16], "QEMU CD-ROM ", 16);
} else {
outbuf[0] = 0;
+outbuf[1] = s->removable ? 0x80 : 0;
memcpy(&outbuf[16], "QEMU HARDDISK ", 16);
}
memcpy(&outbuf[8], "QEMU", 8);
@@ -1295,6 +1297,7 @@ static SCSIDeviceInfo scsi_disk_info = {
DEFINE_BLOCK_PROPERTIES(SCSIDiskState, qdev.conf),
DEFINE_PROP_STRING("ver", SCSIDiskState, version),
DEFINE_PROP_STRING("serial", SCSIDiskState, serial),
+DEFINE_PROP_BIT("removable", SCSIDiskState, removable, 0, false),
DEFINE_PROP_END_OF_LIST(),
},
};
--
1.7.2.3
[Qemu-devel] [PATCH 07/23] ide: also reset io_buffer_index for writes
From: Christoph Hellwig Currenly the code only resets the io_buffer_index field for reads, but the code seems to expect this for all types of I/O. I guess we simply don't hit large enough transfers that would require this often enough. Signed-off-by: Christoph Hellwig Signed-off-by: Kevin Wolf --- hw/ide/core.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/hw/ide/core.c b/hw/ide/core.c index e93dd46..12b9c53 100644 --- a/hw/ide/core.c +++ b/hw/ide/core.c @@ -521,8 +521,7 @@ void ide_dma_cb(void *opaque, int ret) /* launch next transfer */ n = s->nsector; -if (s->is_read) -s->io_buffer_index = 0; +s->io_buffer_index = 0; s->io_buffer_size = n * 512; if (s->bus->dma->ops->prepare_buf(s->bus->dma, s->is_read) == 0) goto eot; -- 1.7.2.3
[Qemu-devel] [PATCH 05/23] Avoid divide by zero when there is no block device to migrate
From: Pierre Riteau
When block migration is requested and no read-write block device is
present, a divide by zero exception is triggered because
total_sector_sum equals zero.
Signed-off-by: Pierre Riteau
Signed-off-by: Kevin Wolf
---
block-migration.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index 1475325..60b9fc0 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -350,7 +350,12 @@ static int blk_mig_save_bulked_block(Monitor *mon,
QEMUFile *f)
}
}
-progress = completed_sector_sum * 100 / block_mig_state.total_sector_sum;
+if (block_mig_state.total_sector_sum != 0) {
+progress = completed_sector_sum * 100 /
+ block_mig_state.total_sector_sum;
+} else {
+progress = 100;
+}
if (progress != block_mig_state.prev_progress) {
block_mig_state.prev_progress = progress;
qemu_put_be64(f, (progress << BDRV_SECTOR_BITS)
--
1.7.2.3
[Qemu-devel] [PATCH 10/23] qcow2: Use QcowCache
Use the new functions of qcow2-cache.c for everything that works on refcount
block and L2 tables.
Signed-off-by: Kevin Wolf
---
block/qcow2-cache.c| 10 ++
block/qcow2-cluster.c | 208 +-
block/qcow2-refcount.c | 260
block/qcow2.c | 48 -
block/qcow2.h | 12 ++-
5 files changed, 240 insertions(+), 298 deletions(-)
diff --git a/block/qcow2-cache.c b/block/qcow2-cache.c
index f7c4e2a..5f1740b 100644
--- a/block/qcow2-cache.c
+++ b/block/qcow2-cache.c
@@ -104,6 +104,12 @@ static int qcow2_cache_entry_flush(BlockDriverState *bs,
Qcow2Cache *c, int i)
}
}
+if (c == s->refcount_block_cache) {
+BLKDBG_EVENT(bs->file, BLKDBG_REFBLOCK_UPDATE_PART);
+} else if (c == s->l2_table_cache) {
+BLKDBG_EVENT(bs->file, BLKDBG_L2_UPDATE);
+}
+
ret = bdrv_pwrite(bs->file, c->entries[i].offset, c->entries[i].table,
s->cluster_size);
if (ret < 0) {
@@ -218,6 +224,10 @@ static int qcow2_cache_do_get(BlockDriverState *bs,
Qcow2Cache *c,
c->entries[i].offset = 0;
if (read_from_disk) {
+if (c == s->l2_table_cache) {
+BLKDBG_EVENT(bs->file, BLKDBG_L2_LOAD);
+}
+
ret = bdrv_pread(bs->file, offset, c->entries[i].table,
s->cluster_size);
if (ret < 0) {
return ret;
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index c3ef550..76e7e07 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -67,7 +67,11 @@ int qcow2_grow_l1_table(BlockDriverState *bs, int min_size,
bool exact_size)
qemu_free(new_l1_table);
return new_l1_table_offset;
}
-bdrv_flush(bs->file);
+
+ret = qcow2_cache_flush(bs, s->refcount_block_cache);
+if (ret < 0) {
+return ret;
+}
BLKDBG_EVENT(bs->file, BLKDBG_L1_GROW_WRITE_TABLE);
for(i = 0; i < s->l1_size; i++)
@@ -98,63 +102,6 @@ int qcow2_grow_l1_table(BlockDriverState *bs, int min_size,
bool exact_size)
return ret;
}
-void qcow2_l2_cache_reset(BlockDriverState *bs)
-{
-BDRVQcowState *s = bs->opaque;
-
-memset(s->l2_cache, 0, s->l2_size * L2_CACHE_SIZE * sizeof(uint64_t));
-memset(s->l2_cache_offsets, 0, L2_CACHE_SIZE * sizeof(uint64_t));
-memset(s->l2_cache_counts, 0, L2_CACHE_SIZE * sizeof(uint32_t));
-}
-
-static inline int l2_cache_new_entry(BlockDriverState *bs)
-{
-BDRVQcowState *s = bs->opaque;
-uint32_t min_count;
-int min_index, i;
-
-/* find a new entry in the least used one */
-min_index = 0;
-min_count = 0x;
-for(i = 0; i < L2_CACHE_SIZE; i++) {
-if (s->l2_cache_counts[i] < min_count) {
-min_count = s->l2_cache_counts[i];
-min_index = i;
-}
-}
-return min_index;
-}
-
-/*
- * seek_l2_table
- *
- * seek l2_offset in the l2_cache table
- * if not found, return NULL,
- * if found,
- * increments the l2 cache hit count of the entry,
- * if counter overflow, divide by two all counters
- * return the pointer to the l2 cache entry
- *
- */
-
-static uint64_t *seek_l2_table(BDRVQcowState *s, uint64_t l2_offset)
-{
-int i, j;
-
-for(i = 0; i < L2_CACHE_SIZE; i++) {
-if (l2_offset == s->l2_cache_offsets[i]) {
-/* increment the hit count */
-if (++s->l2_cache_counts[i] == 0x) {
-for(j = 0; j < L2_CACHE_SIZE; j++) {
-s->l2_cache_counts[j] >>= 1;
-}
-}
-return s->l2_cache + (i << s->l2_bits);
-}
-}
-return NULL;
-}
-
/*
* l2_load
*
@@ -169,33 +116,11 @@ static int l2_load(BlockDriverState *bs, uint64_t
l2_offset,
uint64_t **l2_table)
{
BDRVQcowState *s = bs->opaque;
-int min_index;
int ret;
-/* seek if the table for the given offset is in the cache */
-
-*l2_table = seek_l2_table(s, l2_offset);
-if (*l2_table != NULL) {
-return 0;
-}
-
-/* not found: load a new entry in the least used one */
-
-min_index = l2_cache_new_entry(bs);
-*l2_table = s->l2_cache + (min_index << s->l2_bits);
-
-BLKDBG_EVENT(bs->file, BLKDBG_L2_LOAD);
-ret = bdrv_pread(bs->file, l2_offset, *l2_table,
-s->l2_size * sizeof(uint64_t));
-if (ret < 0) {
-qcow2_l2_cache_reset(bs);
-return ret;
-}
-
-s->l2_cache_offsets[min_index] = l2_offset;
-s->l2_cache_counts[min_index] = 1;
+ret = qcow2_cache_get(bs, s->l2_table_cache, l2_offset, (void**) l2_table);
-return 0;
+return ret;
}
/*
@@ -238,7 +163,6 @@ static int write_l1_entry(BlockDriverState *bs, int
l1_index)
static int l2_allocate(BlockDriverState *bs, int l1_index, uint64_t **table)
{
BDRVQcowState *s = bs->opaque;
-int min_index;
uint64_t old_l2_offset;
uint64_t *l2_table;
int64_t l2_offset;
@@ -252,29 +176,48 @@ static int l2_allocate(BlockDriverState *
[Qemu-devel] [PATCH 02/23] qemu-img snapshot: Use writeback caching
None of the other qemu-img subcommands uses writethrough, and there's no reason
why snapshot should be special.
Signed-off-by: Kevin Wolf
Reviewed-by: Stefan Hajnoczi
---
qemu-img.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-img.c b/qemu-img.c
index afd9ed2..1e65ea8 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -1068,7 +1068,7 @@ static int img_snapshot(int argc, char **argv)
int action = 0;
qemu_timeval tv;
-bdrv_oflags = BDRV_O_RDWR;
+bdrv_oflags = BDRV_O_FLAGS | BDRV_O_RDWR;
/* Parse commandline parameters */
for(;;) {
c = getopt(argc, argv, "la:c:d:h");
--
1.7.2.3
[Qemu-devel] [PATCH 04/23] Make strtosz() return int64_t instead of ssize_t
From: Jes Sorensen
strtosz() needs to return a 64 bit type even on 32 bit
architectures. Otherwise qemu-img will fail to create disk
images >= 2GB
Signed-off-by: Jes Sorensen
Signed-off-by: Kevin Wolf
---
cutils.c |8
monitor.c |2 +-
qemu-common.h |4 ++--
qemu-img.c|2 +-
vl.c |4 ++--
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/cutils.c b/cutils.c
index 7984bc1..4d2e27c 100644
--- a/cutils.c
+++ b/cutils.c
@@ -291,9 +291,9 @@ int fcntl_setfl(int fd, int flag)
* value must be terminated by whitespace, ',' or '\0'. Return -1 on
* error.
*/
-ssize_t strtosz_suffix(const char *nptr, char **end, const char default_suffix)
+int64_t strtosz_suffix(const char *nptr, char **end, const char default_suffix)
{
-ssize_t retval = -1;
+int64_t retval = -1;
char *endptr, c, d;
int mul_required = 0;
double val, mul, integral, fraction;
@@ -365,7 +365,7 @@ ssize_t strtosz_suffix(const char *nptr, char **end, const
char default_suffix)
goto fail;
}
}
-if ((val * mul >= ~(size_t)0) || val < 0) {
+if ((val * mul >= INT64_MAX) || val < 0) {
goto fail;
}
retval = val * mul;
@@ -378,7 +378,7 @@ fail:
return retval;
}
-ssize_t strtosz(const char *nptr, char **end)
+int64_t strtosz(const char *nptr, char **end)
{
return strtosz_suffix(nptr, end, STRTOSZ_DEFSUFFIX_MB);
}
diff --git a/monitor.c b/monitor.c
index d291158..0cda3da 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4162,7 +4162,7 @@ static const mon_cmd_t *monitor_parse_command(Monitor
*mon,
break;
case 'o':
{
-ssize_t val;
+int64_t val;
char *end;
while (qemu_isspace(*p)) {
diff --git a/qemu-common.h b/qemu-common.h
index c766b99..c351131 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -158,8 +158,8 @@ int fcntl_setfl(int fd, int flag);
#define STRTOSZ_DEFSUFFIX_MB 'M'
#define STRTOSZ_DEFSUFFIX_KB 'K'
#define STRTOSZ_DEFSUFFIX_B'B'
-ssize_t strtosz(const char *nptr, char **end);
-ssize_t strtosz_suffix(const char *nptr, char **end, const char
default_suffix);
+int64_t strtosz(const char *nptr, char **end);
+int64_t strtosz_suffix(const char *nptr, char **end, const char
default_suffix);
/* path.c */
void init_paths(const char *prefix);
diff --git a/qemu-img.c b/qemu-img.c
index 1e65ea8..4a37358 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -320,7 +320,7 @@ static int img_create(int argc, char **argv)
/* Get image size, if specified */
if (optind < argc) {
-ssize_t sval;
+int64_t sval;
sval = strtosz_suffix(argv[optind++], NULL, STRTOSZ_DEFSUFFIX_B);
if (sval < 0) {
error_report("Invalid image size specified! You may use k, M, G or
"
diff --git a/vl.c b/vl.c
index 0292184..14255c4 100644
--- a/vl.c
+++ b/vl.c
@@ -804,7 +804,7 @@ static void numa_add(const char *optarg)
if (get_param_value(option, 128, "mem", optarg) == 0) {
node_mem[nodenr] = 0;
} else {
-ssize_t sval;
+int64_t sval;
sval = strtosz(option, NULL);
if (sval < 0) {
fprintf(stderr, "qemu: invalid numa mem size: %s\n", optarg);
@@ -2245,7 +2245,7 @@ int main(int argc, char **argv, char **envp)
exit(0);
break;
case QEMU_OPTION_m: {
-ssize_t value;
+int64_t value;
value = strtosz(optarg, NULL);
if (value < 0) {
--
1.7.2.3
[Qemu-devel] [PATCH 01/23] qcow2: fix unaligned access
From: Aurelien Jarno
cpu_to_be64w() is called with an obviously non-aligned pointer. Use
cpu_to_be64wu() instead. It fixes unaligned accesses errors on IA64
hosts.
Cc: Kevin Wolf
Signed-off-by: Aurelien Jarno
Signed-off-by: Kevin Wolf
---
block/qcow2-cluster.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 6928c63..c3ef550 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -81,7 +81,7 @@ int qcow2_grow_l1_table(BlockDriverState *bs, int min_size,
bool exact_size)
/* set new table */
BLKDBG_EVENT(bs->file, BLKDBG_L1_GROW_ACTIVATE_TABLE);
cpu_to_be32w((uint32_t*)data, new_l1_size);
-cpu_to_be64w((uint64_t*)(data + 4), new_l1_table_offset);
+cpu_to_be64wu((uint64_t*)(data + 4), new_l1_table_offset);
ret = bdrv_pwrite_sync(bs->file, offsetof(QCowHeader, l1_size),
data,sizeof(data));
if (ret < 0) {
goto fail;
--
1.7.2.3
[Qemu-devel] [PATCH 11/23] qcow2: Batch flushes for COW
qcow2 calls bdrv_flush() after performing COW in order to ensure that the
L2 table change is never written before the copy is safe on disk. Now that the
L2 table is cached, we can wait with flushing until we write out the next L2
table.
Signed-off-by: Kevin Wolf
---
block/qcow2-cache.c | 20 +---
block/qcow2-cluster.c |2 +-
block/qcow2.h |1 +
3 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/block/qcow2-cache.c b/block/qcow2-cache.c
index 5f1740b..8f2955b 100644
--- a/block/qcow2-cache.c
+++ b/block/qcow2-cache.c
@@ -38,6 +38,7 @@ struct Qcow2Cache {
int size;
Qcow2CachedTable* entries;
struct Qcow2Cache* depends;
+booldepends_on_flush;
boolwritethrough;
};
@@ -85,13 +86,15 @@ static int qcow2_cache_flush_dependency(BlockDriverState
*bs, Qcow2Cache *c)
}
c->depends = NULL;
+c->depends_on_flush = false;
+
return 0;
}
static int qcow2_cache_entry_flush(BlockDriverState *bs, Qcow2Cache *c, int i)
{
BDRVQcowState *s = bs->opaque;
-int ret;
+int ret = 0;
if (!c->entries[i].dirty || !c->entries[i].offset) {
return 0;
@@ -99,11 +102,17 @@ static int qcow2_cache_entry_flush(BlockDriverState *bs,
Qcow2Cache *c, int i)
if (c->depends) {
ret = qcow2_cache_flush_dependency(bs, c);
-if (ret < 0) {
-return ret;
+} else if (c->depends_on_flush) {
+ret = bdrv_flush(bs->file);
+if (ret >= 0) {
+c->depends_on_flush = false;
}
}
+if (ret < 0) {
+return ret;
+}
+
if (c == s->refcount_block_cache) {
BLKDBG_EVENT(bs->file, BLKDBG_REFBLOCK_UPDATE_PART);
} else if (c == s->l2_table_cache) {
@@ -167,6 +176,11 @@ int qcow2_cache_set_dependency(BlockDriverState *bs,
Qcow2Cache *c,
return 0;
}
+void qcow2_cache_depends_on_flush(Qcow2Cache *c)
+{
+c->depends_on_flush = true;
+}
+
static int qcow2_cache_find_entry_to_replace(Qcow2Cache *c)
{
int i;
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 76e7e07..1c2003a 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -637,7 +637,7 @@ int qcow2_alloc_cluster_link_l2(BlockDriverState *bs,
QCowL2Meta *m)
* handled.
*/
if (cow) {
-bdrv_flush(bs->file);
+qcow2_cache_depends_on_flush(s->l2_table_cache);
}
qcow2_cache_set_dependency(bs, s->l2_table_cache, s->refcount_block_cache);
diff --git a/block/qcow2.h b/block/qcow2.h
index 11cbce3..6d80120 100644
--- a/block/qcow2.h
+++ b/block/qcow2.h
@@ -229,6 +229,7 @@ void qcow2_cache_entry_mark_dirty(Qcow2Cache *c, void
*table);
int qcow2_cache_flush(BlockDriverState *bs, Qcow2Cache *c);
int qcow2_cache_set_dependency(BlockDriverState *bs, Qcow2Cache *c,
Qcow2Cache *dependency);
+void qcow2_cache_depends_on_flush(Qcow2Cache *c);
int qcow2_cache_get(BlockDriverState *bs, Qcow2Cache *c, uint64_t offset,
void **table);
--
1.7.2.3
[Qemu-devel] [RESEND PATCH 3/3] pulseaudio: tweak config
Zap unused divisor field.
Raise the buffer size default.
Signed-off-by: Gerd Hoffmann
---
audio/paaudio.c | 10 +-
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/audio/paaudio.c b/audio/paaudio.c
index 75e3ea0..fb4510e 100644
--- a/audio/paaudio.c
+++ b/audio/paaudio.c
@@ -33,13 +33,11 @@ typedef struct {
static struct {
int samples;
-int divisor;
char *server;
char *sink;
char *source;
} conf = {
-.samples = 1024,
-.divisor = 2,
+.samples = 4096,
};
static void GCC_FMT_ATTR (2, 3) qpa_logerr (int err, const char *fmt, ...)
@@ -478,12 +476,6 @@ struct audio_option qpa_options[] = {
.descr = "buffer size in samples"
},
{
-.name = "DIVISOR",
-.tag = AUD_OPT_INT,
-.valp = &conf.divisor,
-.descr = "threshold divisor"
-},
-{
.name = "SERVER",
.tag = AUD_OPT_STR,
.valp = &conf.server,
--
1.7.1
[Qemu-devel] [PATCH 09/23] qcow2: Add QcowCache
This adds some new cache functions to qcow2 which can be used for caching
refcount blocks and L2 tables. When used with cache=writethrough they work
like the old caching code which is spread all over qcow2, so for this case we
have merely a cleanup.
The interesting case is with writeback caching (this includes cache=none) where
data isn't written to disk immediately but only kept in cache initially. This
leads to some form of metadata write batching which avoids the current "write
to refcount block, flush, write to L2 table" pattern for each single request
when a lot of cluster allocations happen. Instead, cache entries are only
written out if its required to maintain the right order. In the pure cluster
allocation case this means that all metadata updates for requests are done in
memory initially and on sync, first the refcount blocks are written to disk,
then fsync, then L2 tables.
This improves performance of scenarios with lots of cluster allocations
noticably (e.g. installation or after taking a snapshot).
Signed-off-by: Kevin Wolf
---
Makefile.objs |2 +-
block/qcow2-cache.c | 290 +++
block/qcow2.h | 19
3 files changed, 310 insertions(+), 1 deletions(-)
create mode 100644 block/qcow2-cache.c
diff --git a/Makefile.objs b/Makefile.objs
index fda366d..93406ff 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -19,7 +19,7 @@ block-obj-$(CONFIG_POSIX) += posix-aio-compat.o
block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
block-nested-y += raw.o cow.o qcow.o vdi.o vmdk.o cloop.o dmg.o bochs.o vpc.o
vvfat.o
-block-nested-y += qcow2.o qcow2-refcount.o qcow2-cluster.o qcow2-snapshot.o
+block-nested-y += qcow2.o qcow2-refcount.o qcow2-cluster.o qcow2-snapshot.o
qcow2-cache.o
block-nested-y += qed.o qed-gencb.o qed-l2-cache.o qed-table.o qed-cluster.o
block-nested-y += qed-check.o
block-nested-y += parallels.o nbd.o blkdebug.o sheepdog.o blkverify.o
diff --git a/block/qcow2-cache.c b/block/qcow2-cache.c
new file mode 100644
index 000..f7c4e2a
--- /dev/null
+++ b/block/qcow2-cache.c
@@ -0,0 +1,290 @@
+/*
+ * L2/refcount table cache for the QCOW2 format
+ *
+ * Copyright (c) 2010 Kevin Wolf
+ *
+ * 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 "block_int.h"
+#include "qemu-common.h"
+#include "qcow2.h"
+
+typedef struct Qcow2CachedTable {
+void* table;
+int64_t offset;
+booldirty;
+int cache_hits;
+int ref;
+} Qcow2CachedTable;
+
+struct Qcow2Cache {
+int size;
+Qcow2CachedTable* entries;
+struct Qcow2Cache* depends;
+boolwritethrough;
+};
+
+Qcow2Cache *qcow2_cache_create(BlockDriverState *bs, int num_tables,
+bool writethrough)
+{
+BDRVQcowState *s = bs->opaque;
+Qcow2Cache *c;
+int i;
+
+c = qemu_mallocz(sizeof(*c));
+c->size = num_tables;
+c->entries = qemu_mallocz(sizeof(*c->entries) * num_tables);
+c->writethrough = writethrough;
+
+for (i = 0; i < c->size; i++) {
+c->entries[i].table = qemu_blockalign(bs, s->cluster_size);
+}
+
+return c;
+}
+
+int qcow2_cache_destroy(BlockDriverState* bs, Qcow2Cache *c)
+{
+int i;
+
+for (i = 0; i < c->size; i++) {
+assert(c->entries[i].ref == 0);
+qemu_vfree(c->entries[i].table);
+}
+
+qemu_free(c->entries);
+qemu_free(c);
+
+return 0;
+}
+
+static int qcow2_cache_flush_dependency(BlockDriverState *bs, Qcow2Cache *c)
+{
+int ret;
+
+ret = qcow2_cache_flush(bs, c->depends);
+if (ret < 0) {
+return ret;
+}
+
+c->depends = NULL;
+return 0;
+}
+
+static int qcow2_cache_entry_flush(BlockDriverState *bs, Qcow2Cache *c, int i)
+{
+BDRVQcowState *s = bs->opaque;
+int ret;
+
+if (!c->entries[i].dirty || !c->entries[i].offset) {
+return 0;
+}
+
+if (c->depends) {
+ret = qcow2_cache_flush_dependency(
[Qemu-devel] [RESEND PATCH 2/3] pulseaudio: setup buffer attrs
Request reasonable buffer sizes from pulseaudio. Without this
pa_simple_write() can block quite long and lead to dropouts,
especially with guests which use small audio ring buffers.
Signed-off-by: Gerd Hoffmann
---
audio/paaudio.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/audio/paaudio.c b/audio/paaudio.c
index 858ca81..75e3ea0 100644
--- a/audio/paaudio.c
+++ b/audio/paaudio.c
@@ -289,6 +289,7 @@ static int qpa_init_out (HWVoiceOut *hw, struct audsettings
*as)
{
int error;
static pa_sample_spec ss;
+static pa_buffer_attr ba;
struct audsettings obt_as = *as;
PAVoiceOut *pa = (PAVoiceOut *) hw;
@@ -296,6 +297,15 @@ static int qpa_init_out (HWVoiceOut *hw, struct
audsettings *as)
ss.channels = as->nchannels;
ss.rate = as->freq;
+/*
+ * qemu audio tick runs at 250 Hz (by default), so processing
+ * data chunks worth 4 ms of sound should be a good fit.
+ */
+ba.tlength = pa_usec_to_bytes (4 * 1000, &ss);
+ba.minreq = pa_usec_to_bytes (2 * 1000, &ss);
+ba.maxlength = -1;
+ba.prebuf = -1;
+
obt_as.fmt = pa_to_audfmt (ss.format, &obt_as.endianness);
pa->s = pa_simple_new (
@@ -306,7 +316,7 @@ static int qpa_init_out (HWVoiceOut *hw, struct audsettings
*as)
"pcm.playback",
&ss,
NULL, /* channel map */
-NULL, /* buffering attributes */
+&ba,/* buffering attributes */
&error
);
if (!pa->s) {
--
1.7.1
Re: [Qemu-devel] Re: [RFC/PATCH] elfload: add FDPIC support
On 01/24/2011 08:11 PM, Mike Frysinger wrote: On Mon, Jan 24, 2011 at 08:34, Stefano Bonifazi wrote: Is FDPIC something different than simply PIC code (position independent code)? FDPIC ELF is the ELF PIE format used on NOMMU systems so that both the text and data regions may be located anywhere. it is the only ELF format supported under NOMMU systems. I am also trying to fight with the problem of changing the starting address of target code for qemu-user, and I was just moving into the option of using PIC target code .. but the original qemu-user load_elf_binary does not work on them.. and I was just about to try to edit it.. i dont believe my patch accomplishes that in any way. i will need to force all files to be loaded at a higher address than zero for the Blackfin arch (as the first ~4KiB is reserved for the ABI), but that is independent of FDPIC ELF support. -mike I don't understand.. what is the difference between pie binary for pcc and for your architecture? As far as I understood pie code is independent from addresses, so it should not care if the OS running them would have an mmu at all.. it should be just the task of the dynamic linker to relocate it properly, am I wrong? Thank you! Regards, Stefano B.
[Qemu-devel] [RESEND PATCH 1/3] pulseaudio: process 1/4 buffer max at once
Limit the size of data pieces processed by the pulseaudio worker
threads. Never ever process more than 1/4 of the buffer at once.
Background: The buffer area currently processed by the pulseaudio thread
is blocked, i.e. the main thread (or iothread) can't fill in more data
there. The buffer processing time is roughly real-time due to the
pa_simple_write() call blocking when the output queue to the pulse
server is full. Thus processing big chunks at once means blocking
a large part of the buffer for a long time. This brings high latency
and can lead to dropouts.
When processing the buffer in smaller chunks the rpos handling becomes a
problem though. The thread reads hw->rpos without knowing whenever
qpa_run_out has already seen the last (small) chunk processed and
updated rpos accordingly. There is no point in reading hw->rpos though,
pa->rpos can be used instead. We just need to take care to initialize
pa->rpos before kicking the thread.
Signed-off-by: Gerd Hoffmann
---
audio/paaudio.c | 22 +-
1 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/audio/paaudio.c b/audio/paaudio.c
index 9cf685d..858ca81 100644
--- a/audio/paaudio.c
+++ b/audio/paaudio.c
@@ -57,9 +57,6 @@ static void *qpa_thread_out (void *arg)
{
PAVoiceOut *pa = arg;
HWVoiceOut *hw = &pa->hw;
-int threshold;
-
-threshold = conf.divisor ? hw->samples / conf.divisor : 0;
if (audio_pt_lock (&pa->pt, AUDIO_FUNC)) {
return NULL;
@@ -73,7 +70,7 @@ static void *qpa_thread_out (void *arg)
goto exit;
}
-if (pa->live > threshold) {
+if (pa->live > 0) {
break;
}
@@ -82,8 +79,8 @@ static void *qpa_thread_out (void *arg)
}
}
-decr = to_mix = pa->live;
-rpos = hw->rpos;
+decr = to_mix = audio_MIN (pa->live, conf.samples >> 2);
+rpos = pa->rpos;
if (audio_pt_unlock (&pa->pt, AUDIO_FUNC)) {
return NULL;
@@ -110,8 +107,8 @@ static void *qpa_thread_out (void *arg)
return NULL;
}
-pa->live = 0;
pa->rpos = rpos;
+pa->live -= decr;
pa->decr += decr;
}
@@ -152,9 +149,6 @@ static void *qpa_thread_in (void *arg)
{
PAVoiceIn *pa = arg;
HWVoiceIn *hw = &pa->hw;
-int threshold;
-
-threshold = conf.divisor ? hw->samples / conf.divisor : 0;
if (audio_pt_lock (&pa->pt, AUDIO_FUNC)) {
return NULL;
@@ -168,7 +162,7 @@ static void *qpa_thread_in (void *arg)
goto exit;
}
-if (pa->dead > threshold) {
+if (pa->dead > 0) {
break;
}
@@ -177,8 +171,8 @@ static void *qpa_thread_in (void *arg)
}
}
-incr = to_grab = pa->dead;
-wpos = hw->wpos;
+incr = to_grab = audio_MIN (pa->dead, conf.samples >> 2);
+wpos = pa->wpos;
if (audio_pt_unlock (&pa->pt, AUDIO_FUNC)) {
return NULL;
@@ -323,6 +317,7 @@ static int qpa_init_out (HWVoiceOut *hw, struct audsettings
*as)
audio_pcm_init_info (&hw->info, &obt_as);
hw->samples = conf.samples;
pa->pcm_buf = audio_calloc (AUDIO_FUNC, hw->samples, 1 << hw->info.shift);
+pa->rpos = hw->rpos;
if (!pa->pcm_buf) {
dolog ("Could not allocate buffer (%d bytes)\n",
hw->samples << hw->info.shift);
@@ -377,6 +372,7 @@ static int qpa_init_in (HWVoiceIn *hw, struct audsettings
*as)
audio_pcm_init_info (&hw->info, &obt_as);
hw->samples = conf.samples;
pa->pcm_buf = audio_calloc (AUDIO_FUNC, hw->samples, 1 << hw->info.shift);
+pa->wpos = hw->wpos;
if (!pa->pcm_buf) {
dolog ("Could not allocate buffer (%d bytes)\n",
hw->samples << hw->info.shift);
--
1.7.1
[Qemu-devel] [PATCH 03/23] do_snapshot_blkdev() error on missing snapshot_file argument
From: Jes Sorensen
Current code does not support snapshot internally to the running
image. Error in case no snapshot_file is specified.
Signed-off-by: Jes Sorensen
Signed-off-by: Kevin Wolf
---
blockdev.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index d7add36..662f7a9 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -526,6 +526,12 @@ int do_snapshot_blkdev(Monitor *mon, const QDict *qdict,
QObject **ret_data)
int ret = 0;
int flags;
+if (!filename) {
+qerror_report(QERR_MISSING_PARAMETER, "snapshot_file");
+ret = -1;
+goto out;
+}
+
bs = bdrv_find(device);
if (!bs) {
qerror_report(QERR_DEVICE_NOT_FOUND, device);
--
1.7.2.3
[Qemu-devel] [RFC 0/7] Introduce hard dependency on glib
Both the recent I/O loop and threadlet series have me concerned that we're digging ourselves deeper into the NIH hole. I think it's time we look at something radical to let us borrow more code from existing projects instead of reinventing everything through trial and error. This series introduces a hard dependency on glib. The initial use is portable threads but I see this as just the beginning. Glib/Gobject offer many nice things including: - portable threads - rich data structure support - INI parser - JSON parser - generic type system - object oriented infrastructure - IO library - module system - introspection to enable support for dynamic language bindings I see this series as the first step, followed by converting the I/O loop to a GMainLoop instance. Once we're there, we can start making deeper use of GObjects including converting QDev to a GObject hierarchy. I've spent the past few months working on C++ integration for QEMU. I'm more convinced than ever that we desperately in need of structured object oriented mechanisms to be successful but am pretty strongly convinced that incremental additional of C++ is not going to be successful. On the other hand, while GObjects are uglier and require a lot of template code, there's more than enough structure that I think it can guide us into a much better object model implementation. There is some ugliness. GLib does not abstract signals because they're very non-portable but QEMU makes extensive use of signaling. I don't think it's a major issue but some of the ugliness in this series is due to that fact. This series is only lightly tested but also mostly mechanical. I'm pretty confused by the way tcg_halt_cond and friends works so I'm fairly sure I broke that (for non-threaded TCG).
[Qemu-devel] [PATCH 5/7] threads: get rid of QemuCond and teach callers about GCond
Signed-off-by: Anthony Liguori
diff --git a/cpu-defs.h b/cpu-defs.h
index 8d4bf86..9343824 100644
--- a/cpu-defs.h
+++ b/cpu-defs.h
@@ -204,7 +204,7 @@ typedef struct CPUWatchpoint {
uint32_t stop; /* Stop request */ \
uint32_t stopped; /* Artificially stopped */\
struct QemuThread *thread; \
-struct QemuCond *halt_cond; \
+struct _GCond *halt_cond; \
struct qemu_work_item *queued_work_first, *queued_work_last;\
const char *cpu_model_str; \
struct KVMState *kvm_state; \
diff --git a/cpus.c b/cpus.c
index 0f8e33b..bc7363f 100644
--- a/cpus.c
+++ b/cpus.c
@@ -327,15 +327,15 @@ static GStaticMutex qemu_fair_mutex;
static QemuThread io_thread;
static QemuThread *tcg_cpu_thread;
-static QemuCond *tcg_halt_cond;
+static GCond *tcg_halt_cond;
static int qemu_system_ready;
/* cpu creation */
-static QemuCond qemu_cpu_cond;
+static GCond *qemu_cpu_cond;
/* system init */
-static QemuCond qemu_system_cond;
-static QemuCond qemu_pause_cond;
-static QemuCond qemu_work_cond;
+static GCond *qemu_system_cond;
+static GCond *qemu_pause_cond;
+static GCond *qemu_work_cond;
static void tcg_init_ipi(void);
static void kvm_init_ipi(CPUState *env);
@@ -412,10 +412,10 @@ int qemu_init_main_loop(void)
if (ret)
return ret;
-qemu_cond_init(&qemu_cpu_cond);
-qemu_cond_init(&qemu_system_cond);
-qemu_cond_init(&qemu_pause_cond);
-qemu_cond_init(&qemu_work_cond);
+qemu_cpu_cond = g_cond_new();
+qemu_system_cond = g_cond_new();
+qemu_pause_cond = g_cond_new();
+qemu_work_cond = g_cond_new();
g_static_mutex_init(&qemu_fair_mutex);
g_static_mutex_init(&qemu_global_mutex);
g_static_mutex_lock(&qemu_global_mutex);
@@ -428,7 +428,7 @@ int qemu_init_main_loop(void)
void qemu_main_loop_start(void)
{
qemu_system_ready = 1;
-qemu_cond_broadcast(&qemu_system_cond);
+g_cond_broadcast(qemu_system_cond);
}
void run_on_cpu(CPUState *env, void (*func)(void *data), void *data)
@@ -454,8 +454,8 @@ void run_on_cpu(CPUState *env, void (*func)(void *data),
void *data)
while (!wi.done) {
CPUState *self_env = cpu_single_env;
-qemu_cond_wait(&qemu_work_cond,
- g_static_mutex_get_mutex(&qemu_global_mutex));
+g_cond_wait(qemu_work_cond,
+g_static_mutex_get_mutex(&qemu_global_mutex));
cpu_single_env = self_env;
}
}
@@ -473,7 +473,7 @@ static void flush_queued_work(CPUState *env)
wi->done = true;
}
env->queued_work_last = NULL;
-qemu_cond_broadcast(&qemu_work_cond);
+g_cond_broadcast(qemu_work_cond);
}
static void qemu_wait_io_event_common(CPUState *env)
@@ -481,7 +481,7 @@ static void qemu_wait_io_event_common(CPUState *env)
if (env->stop) {
env->stop = 0;
env->stopped = 1;
-qemu_cond_signal(&qemu_pause_cond);
+g_cond_signal(qemu_pause_cond);
}
flush_queued_work(env);
}
@@ -490,9 +490,13 @@ static void qemu_tcg_wait_io_event(void)
{
CPUState *env;
-while (!any_cpu_has_work())
-qemu_cond_timedwait(tcg_halt_cond,
-g_static_mutex_get_mutex(&qemu_global_mutex),
1000);
+while (!any_cpu_has_work()) {
+GTimeVal t;
+g_get_current_time(&t);
+g_time_val_add(&t, 100);
+g_cond_timed_wait(tcg_halt_cond,
+ g_static_mutex_get_mutex(&qemu_global_mutex), &t);
+}
g_static_mutex_unlock(&qemu_global_mutex);
@@ -586,9 +590,13 @@ static void qemu_kvm_eat_signal(CPUState *env, int timeout)
static void qemu_kvm_wait_io_event(CPUState *env)
{
-while (!cpu_has_work(env))
-qemu_cond_timedwait(env->halt_cond,
-g_static_mutex_get_mutex(&qemu_global_mutex),
1000);
+while (!cpu_has_work(env)) {
+GTimeVal t;
+g_get_current_time(&t);
+g_time_val_add(&t, 100);
+g_cond_timed_wait(env->halt_cond,
+ g_static_mutex_get_mutex(&qemu_global_mutex), &t);
+}
qemu_kvm_eat_signal(env, 0);
qemu_wait_io_event_common(env);
@@ -609,12 +617,16 @@ static void *kvm_cpu_thread_fn(void *arg)
/* signal CPU creation */
env->created = 1;
-qemu_cond_signal(&qemu_cpu_cond);
+g_cond_signal(qemu_cpu_cond);
/* and wait for machine initialization */
-while (!qemu_system_ready)
-qemu_cond_timedwait(&qemu_system_cond,
-g_static_mutex_get_mutex(&qemu_global_mutex), 100);
+while (!qemu_system_ready) {
+GTimeVal t;
+g_get_current_time(&t);
+g_time_val_add(&t, 10);
+g_cond_timed_wait(qemu_system_cond,
+
[Qemu-devel] [PATCH] Fix vnc memory corruption with width = 1400
[ note: found while cleaning up my git branches, must be quite old,
rebase worked fine, looks like this one never made it upstream,
resubmitting now ... ]
vnc assumes that the screen width is a multiple of 16 in several places.
If this is not the case vnc will overrun buffers, corrupt memory, make
qemu crash.
This is the minimum fix for this bug. It makes sure we don't overrun the
scanline, thereby fixing the segfault. The rendering is *not* correct
though, there is a black border at the right side of the screen, 8
pixels wide because 1400 % 16 == 8.
Signed-off-by: Gerd Hoffmann
---
ui/vnc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index 495d6d6..592be8e 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -2284,7 +2284,7 @@ static int vnc_refresh_server_surface(VncDisplay *vd)
guest_ptr = guest_row;
server_ptr = server_row;
-for (x = 0; x < vd->guest.ds->width;
+for (x = 0; x + 15 < vd->guest.ds->width;
x += 16, guest_ptr += cmp_bytes, server_ptr += cmp_bytes) {
if (!vnc_get_bit(vd->guest.dirty[y], (x / 16)))
continue;
--
1.7.1
[Qemu-devel] [PATCH 4/7] Get rid of QemuMutex and teach its callers about GStaticMutex
Signed-off-by: Anthony Liguori
diff --git a/cpus.c b/cpus.c
index 9cf7e6e..0f8e33b 100644
--- a/cpus.c
+++ b/cpus.c
@@ -321,8 +321,8 @@ void vm_stop(int reason)
#include "qemu-thread.h"
-QemuMutex qemu_global_mutex;
-static QemuMutex qemu_fair_mutex;
+GStaticMutex qemu_global_mutex;
+static GStaticMutex qemu_fair_mutex;
static QemuThread io_thread;
@@ -416,9 +416,9 @@ int qemu_init_main_loop(void)
qemu_cond_init(&qemu_system_cond);
qemu_cond_init(&qemu_pause_cond);
qemu_cond_init(&qemu_work_cond);
-qemu_mutex_init(&qemu_fair_mutex);
-qemu_mutex_init(&qemu_global_mutex);
-qemu_mutex_lock(&qemu_global_mutex);
+g_static_mutex_init(&qemu_fair_mutex);
+g_static_mutex_init(&qemu_global_mutex);
+g_static_mutex_lock(&qemu_global_mutex);
qemu_thread_self(&io_thread);
@@ -454,7 +454,8 @@ void run_on_cpu(CPUState *env, void (*func)(void *data),
void *data)
while (!wi.done) {
CPUState *self_env = cpu_single_env;
-qemu_cond_wait(&qemu_work_cond, &qemu_global_mutex);
+qemu_cond_wait(&qemu_work_cond,
+ g_static_mutex_get_mutex(&qemu_global_mutex));
cpu_single_env = self_env;
}
}
@@ -490,19 +491,20 @@ static void qemu_tcg_wait_io_event(void)
CPUState *env;
while (!any_cpu_has_work())
-qemu_cond_timedwait(tcg_halt_cond, &qemu_global_mutex, 1000);
+qemu_cond_timedwait(tcg_halt_cond,
+g_static_mutex_get_mutex(&qemu_global_mutex),
1000);
-qemu_mutex_unlock(&qemu_global_mutex);
+g_static_mutex_unlock(&qemu_global_mutex);
/*
* Users of qemu_global_mutex can be starved, having no chance
* to acquire it since this path will get to it first.
* So use another lock to provide fairness.
*/
-qemu_mutex_lock(&qemu_fair_mutex);
-qemu_mutex_unlock(&qemu_fair_mutex);
+g_static_mutex_lock(&qemu_fair_mutex);
+g_static_mutex_unlock(&qemu_fair_mutex);
-qemu_mutex_lock(&qemu_global_mutex);
+g_static_mutex_lock(&qemu_global_mutex);
for (env = first_cpu; env != NULL; env = env->next_cpu) {
qemu_wait_io_event_common(env);
@@ -551,12 +553,12 @@ static void qemu_kvm_eat_signal(CPUState *env, int
timeout)
sigaddset(&waitset, SIGBUS);
do {
-qemu_mutex_unlock(&qemu_global_mutex);
+g_static_mutex_unlock(&qemu_global_mutex);
r = sigtimedwait(&waitset, &siginfo, &ts);
e = errno;
-qemu_mutex_lock(&qemu_global_mutex);
+g_static_mutex_lock(&qemu_global_mutex);
if (r == -1 && !(e == EAGAIN || e == EINTR)) {
fprintf(stderr, "sigtimedwait: %s\n", strerror(e));
@@ -585,7 +587,8 @@ static void qemu_kvm_eat_signal(CPUState *env, int timeout)
static void qemu_kvm_wait_io_event(CPUState *env)
{
while (!cpu_has_work(env))
-qemu_cond_timedwait(env->halt_cond, &qemu_global_mutex, 1000);
+qemu_cond_timedwait(env->halt_cond,
+g_static_mutex_get_mutex(&qemu_global_mutex),
1000);
qemu_kvm_eat_signal(env, 0);
qemu_wait_io_event_common(env);
@@ -597,7 +600,7 @@ static void *kvm_cpu_thread_fn(void *arg)
{
CPUState *env = arg;
-qemu_mutex_lock(&qemu_global_mutex);
+g_static_mutex_lock(&qemu_global_mutex);
qemu_thread_self(env->thread);
if (kvm_enabled())
kvm_init_vcpu(env);
@@ -610,7 +613,8 @@ static void *kvm_cpu_thread_fn(void *arg)
/* and wait for machine initialization */
while (!qemu_system_ready)
-qemu_cond_timedwait(&qemu_system_cond, &qemu_global_mutex, 100);
+qemu_cond_timedwait(&qemu_system_cond,
+g_static_mutex_get_mutex(&qemu_global_mutex), 100);
while (1) {
if (cpu_can_run(env))
@@ -629,14 +633,15 @@ static void *tcg_cpu_thread_fn(void *arg)
qemu_thread_self(env->thread);
/* signal CPU creation */
-qemu_mutex_lock(&qemu_global_mutex);
+g_static_mutex_lock(&qemu_global_mutex);
for (env = first_cpu; env != NULL; env = env->next_cpu)
env->created = 1;
qemu_cond_signal(&qemu_cpu_cond);
/* and wait for machine initialization */
while (!qemu_system_ready)
-qemu_cond_timedwait(&qemu_system_cond, &qemu_global_mutex, 100);
+qemu_cond_timedwait(&qemu_system_cond,
+g_static_mutex_get_mutex(&qemu_global_mutex), 100);
while (1) {
cpu_exec_all();
@@ -737,22 +742,22 @@ static sigset_t block_io_signals(void)
void qemu_mutex_lock_iothread(void)
{
if (kvm_enabled()) {
-qemu_mutex_lock(&qemu_fair_mutex);
-qemu_mutex_lock(&qemu_global_mutex);
-qemu_mutex_unlock(&qemu_fair_mutex);
+g_static_mutex_lock(&qemu_fair_mutex);
+g_static_mutex_lock(&qemu_global_mutex);
+g_static_mutex_unlock(&qemu_fair_mutex);
} else {
-qemu_mutex_lock(&qemu_fair_mutex);
-if (qemu_mutex_trylock(&qemu_gl
[Qemu-devel] [PATCH 1/7] io-thread: make sure to initialize qemu_work_cond and qemu_cpu_cond
Signed-off-by: Anthony Liguori diff --git a/cpus.c b/cpus.c index 0309189..9cf7e6e 100644 --- a/cpus.c +++ b/cpus.c @@ -412,8 +412,10 @@ int qemu_init_main_loop(void) if (ret) return ret; -qemu_cond_init(&qemu_pause_cond); +qemu_cond_init(&qemu_cpu_cond); qemu_cond_init(&qemu_system_cond); +qemu_cond_init(&qemu_pause_cond); +qemu_cond_init(&qemu_work_cond); qemu_mutex_init(&qemu_fair_mutex); qemu_mutex_init(&qemu_global_mutex); qemu_mutex_lock(&qemu_global_mutex); -- 1.7.0.4
[Qemu-devel] [PATCH 7/7] Rename QemuThread to QemuSThread to indicate that it is not a generic thread
This is an abstraction to support signalable threads. Signaling is inheritedly
non-portable so this type of thread should only be used when absolutely
necessary. I think the current users are the only users that should ever need
to exist so strongly discourage future use.
Signed-off-by: Anthony Liguori
diff --git a/cpu-defs.h b/cpu-defs.h
index 9343824..ed2a209 100644
--- a/cpu-defs.h
+++ b/cpu-defs.h
@@ -203,7 +203,7 @@ typedef struct CPUWatchpoint {
uint32_t created; \
uint32_t stop; /* Stop request */ \
uint32_t stopped; /* Artificially stopped */\
-struct QemuThread *thread; \
+struct QemuSThread *thread; \
struct _GCond *halt_cond; \
struct qemu_work_item *queued_work_first, *queued_work_last;\
const char *cpu_model_str; \
diff --git a/cpus.c b/cpus.c
index bc7363f..eebfe11 100644
--- a/cpus.c
+++ b/cpus.c
@@ -324,9 +324,9 @@ void vm_stop(int reason)
GStaticMutex qemu_global_mutex;
static GStaticMutex qemu_fair_mutex;
-static QemuThread io_thread;
+static QemuSThread io_thread;
-static QemuThread *tcg_cpu_thread;
+static QemuSThread *tcg_cpu_thread;
static GCond *tcg_halt_cond;
static int qemu_system_ready;
@@ -420,7 +420,7 @@ int qemu_init_main_loop(void)
g_static_mutex_init(&qemu_global_mutex);
g_static_mutex_lock(&qemu_global_mutex);
-qemu_thread_self(&io_thread);
+qemu_sthread_self(&io_thread);
return 0;
}
@@ -609,7 +609,7 @@ static void *kvm_cpu_thread_fn(void *arg)
CPUState *env = arg;
g_static_mutex_lock(&qemu_global_mutex);
-qemu_thread_self(env->thread);
+qemu_sthread_self(env->thread);
if (kvm_enabled())
kvm_init_vcpu(env);
@@ -642,7 +642,7 @@ static void *tcg_cpu_thread_fn(void *arg)
CPUState *env = arg;
tcg_init_ipi();
-qemu_thread_self(env->thread);
+qemu_sthread_self(env->thread);
/* signal CPU creation */
g_static_mutex_lock(&qemu_global_mutex);
@@ -671,17 +671,17 @@ void qemu_cpu_kick(void *_env)
{
CPUState *env = _env;
g_cond_broadcast(env->halt_cond);
-qemu_thread_signal(env->thread, SIG_IPI);
+qemu_sthread_signal(env->thread, SIG_IPI);
}
int qemu_cpu_self(void *_env)
{
CPUState *env = _env;
-QemuThread this;
+QemuSThread this;
-qemu_thread_self(&this);
+qemu_sthread_self(&this);
-return qemu_thread_equal(&this, env->thread);
+return qemu_sthread_equal(&this, env->thread);
}
static void cpu_signal(int sig)
@@ -764,7 +764,7 @@ void qemu_mutex_lock_iothread(void)
} else {
g_static_mutex_lock(&qemu_fair_mutex);
if (g_static_mutex_trylock(&qemu_global_mutex)) {
-qemu_thread_signal(tcg_cpu_thread, SIG_IPI);
+qemu_sthread_signal(tcg_cpu_thread, SIG_IPI);
g_static_mutex_lock(&qemu_global_mutex);
}
g_static_mutex_unlock(&qemu_fair_mutex);
@@ -830,9 +830,9 @@ static void tcg_init_vcpu(void *_env)
CPUState *env = _env;
/* share a single thread for all cpus with TCG */
if (!tcg_cpu_thread) {
-env->thread = qemu_mallocz(sizeof(QemuThread));
+env->thread = qemu_mallocz(sizeof(QemuSThread));
env->halt_cond = g_cond_new();
-qemu_thread_create(env->thread, tcg_cpu_thread_fn, env);
+qemu_sthread_create(env->thread, tcg_cpu_thread_fn, env);
while (env->created == 0) {
GTimeVal t;
g_get_current_time(&t);
@@ -850,9 +850,9 @@ static void tcg_init_vcpu(void *_env)
static void kvm_start_vcpu(CPUState *env)
{
-env->thread = qemu_mallocz(sizeof(QemuThread));
+env->thread = qemu_mallocz(sizeof(QemuSThread));
env->halt_cond = g_cond_new();
-qemu_thread_create(env->thread, kvm_cpu_thread_fn, env);
+qemu_sthread_create(env->thread, kvm_cpu_thread_fn, env);
while (env->created == 0) {
GTimeVal t;
g_get_current_time(&t);
@@ -887,10 +887,10 @@ static void qemu_system_vmstop_request(int reason)
void vm_stop(int reason)
{
-QemuThread me;
-qemu_thread_self(&me);
+QemuSThread me;
+qemu_sthread_self(&me);
-if (!qemu_thread_equal(&me, &io_thread)) {
+if (!qemu_sthread_equal(&me, &io_thread)) {
qemu_system_vmstop_request(reason);
/*
* FIXME: should not return to device code in case
diff --git a/qemu-thread.c b/qemu-thread.c
index 6d0c51e..7ba4950 100644
--- a/qemu-thread.c
+++ b/qemu-thread.c
@@ -41,7 +41,7 @@ GThread *q_thread_create_nosignal(GThreadFunc func,
struct trampoline_data
{
-QemuThread *thread;
+QemuSThread *thread;
void *(*startfn)(void *);
void *opaque;
GStaticMutex lock;
@@ -61,7 +61,7 @@ static gpointer thread_trampoline(gpointe
[Qemu-devel] [PATCH 6/7] Teach vnc server to use GThread directly
Signed-off-by: Anthony Liguori
diff --git a/qemu-thread.c b/qemu-thread.c
index 748da5e..6d0c51e 100644
--- a/qemu-thread.c
+++ b/qemu-thread.c
@@ -14,6 +14,31 @@
#include "qemu-common.h"
#include "qemu-thread.h"
+#ifdef _WIN32
+GThread *q_thread_create_nosignal(GThreadFunc func,
+ gpointer data,
+ gboolean joinable,
+ GError **error)
+{
+return g_thread_create(func, data, joinable, NULL);
+}
+#else
+GThread *q_thread_create_nosignal(GThreadFunc func,
+ gpointer data,
+ gboolean joinable,
+ GError **error)
+{
+GThread *tid;
+sigset_t set, old;
+
+sigfillset(&set);
+pthread_sigmask(SIG_SETMASK, &set, &old);
+tid = g_thread_create(func, data, joinable, error);
+pthread_sigmask(SIG_SETMASK, &old, NULL);
+return tid;
+}
+#endif
+
struct trampoline_data
{
QemuThread *thread;
diff --git a/qemu-thread.h b/qemu-thread.h
index 2c99c94..ec7fabd 100644
--- a/qemu-thread.h
+++ b/qemu-thread.h
@@ -10,6 +10,11 @@ struct QemuThread {
typedef struct QemuThread QemuThread;
+GThread *q_thread_create_nosignal(GThreadFunc func,
+ gpointer data,
+ gboolean joinable,
+ GError **error);
+
void qemu_thread_create(QemuThread *thread,
void *(*start_routine)(void*),
void *arg);
diff --git a/ui/vnc-jobs-async.c b/ui/vnc-jobs-async.c
index 0c2b1a0..2df245d 100644
--- a/ui/vnc-jobs-async.c
+++ b/ui/vnc-jobs-async.c
@@ -51,7 +51,7 @@
struct VncJobQueue {
GCond *cond;
GStaticMutex mutex;
-QemuThread thread;
+GThread *thread;
Buffer buffer;
bool exit;
QTAILQ_HEAD(, VncJob) jobs;
@@ -289,11 +289,11 @@ static void vnc_queue_clear(VncJobQueue *q)
queue = NULL; /* Unset global queue */
}
-static void *vnc_worker_thread(void *arg)
+static gpointer vnc_worker_thread(gpointer arg)
{
VncJobQueue *queue = arg;
-qemu_thread_self(&queue->thread);
+queue->thread = g_thread_self();
while (!vnc_worker_thread_loop(queue)) ;
vnc_queue_clear(queue);
@@ -308,7 +308,7 @@ void vnc_start_worker_thread(void)
return ;
q = vnc_queue_init();
-qemu_thread_create(&q->thread, vnc_worker_thread, q);
+q->thread = q_thread_create_nosignal(vnc_worker_thread, q, FALSE, NULL);
queue = q; /* Set global queue */
}
--
1.7.0.4
[Qemu-devel] [PATCH 3/7] Add support for glib based threading and convert qemu thread to use it
GLib is an extremely common library that has a portable thread implementation
along with tons of other goodies.
GLib and GObject have a fantastic amount of infrastructure we can leverage in
QEMU including an object oriented programming infrastructure.
Short term, it has a very nice thread pool implementation that we could leverage
in something like virtio-9p.
Signed-off-by: Anthony Liguori
diff --git a/Makefile b/Makefile
index 6d601ee..bf24d1b 100644
--- a/Makefile
+++ b/Makefile
@@ -104,6 +104,8 @@ audio/audio.o audio/fmodaudio.o: QEMU_CFLAGS +=
$(FMOD_CFLAGS)
QEMU_CFLAGS+=$(CURL_CFLAGS)
+QEMU_CFLAGS+=$(GLIB_CFLAGS)
+
ui/cocoa.o: ui/cocoa.m
ui/sdl.o audio/sdlaudio.o ui/sdl_zoom.o baum.o: QEMU_CFLAGS += $(SDL_CFLAGS)
diff --git a/Makefile.objs b/Makefile.objs
index c3e52c5..283e62a 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -316,3 +316,5 @@ vl.o: QEMU_CFLAGS+=$(GPROF_CFLAGS)
vl.o: QEMU_CFLAGS+=$(SDL_CFLAGS)
+vl.o: QEMU_CFLAGS+=$(GLIB_CFLAGS)
+
diff --git a/Makefile.target b/Makefile.target
index e15b1c4..2c1c90e 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -204,6 +204,7 @@ QEMU_CFLAGS += $(VNC_TLS_CFLAGS)
QEMU_CFLAGS += $(VNC_SASL_CFLAGS)
QEMU_CFLAGS += $(VNC_JPEG_CFLAGS)
QEMU_CFLAGS += $(VNC_PNG_CFLAGS)
+QEMU_CFLAGS += $(GLIB_CFLAGS)
# xen backend driver support
obj-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o
diff --git a/configure b/configure
index d5ac074..820fde9 100755
--- a/configure
+++ b/configure
@@ -1658,6 +1658,17 @@ EOF
fi
##
+# glib support probe
+if $pkg_config --modversion gthread-2.0 > /dev/null 2>&1 ; then
+glib_cflags=`$pkg_config --cflags gthread-2.0 2>/dev/null`
+glib_libs=`$pkg_config --libs gthread-2.0 2>/dev/null`
+libs_softmmu="$glib_libs $libs_softmmu"
+else
+echo "glib-2.0 required to compile QEMU"
+exit 1
+fi
+
+##
# kvm probe
if test "$kvm" != "no" ; then
cat > $TMPC <> $config_host_mak
echo "BLUEZ_CFLAGS=$bluez_cflags" >> $config_host_mak
fi
+echo "GLIB_CFLAGS=$glib_cflags" >> $config_host_mak
if test "$xen" = "yes" ; then
echo "CONFIG_XEN=y" >> $config_host_mak
fi
diff --git a/qemu-thread.c b/qemu-thread.c
index fbc78fe..2c521ab 100644
--- a/qemu-thread.c
+++ b/qemu-thread.c
@@ -10,183 +10,142 @@
* See the COPYING file in the top-level directory.
*
*/
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include "qemu-thread.h"
-static void error_exit(int err, const char *msg)
-{
-fprintf(stderr, "qemu: %s: %s\n", msg, strerror(err));
-exit(1);
-}
+#include "qemu-common.h"
+#include "qemu-thread.h"
void qemu_mutex_init(QemuMutex *mutex)
{
-int err;
-
-err = pthread_mutex_init(&mutex->lock, NULL);
-if (err)
-error_exit(err, __func__);
+g_static_mutex_init(&mutex->lock);
}
void qemu_mutex_destroy(QemuMutex *mutex)
{
-int err;
-
-err = pthread_mutex_destroy(&mutex->lock);
-if (err)
-error_exit(err, __func__);
+g_static_mutex_free(&mutex->lock);
}
void qemu_mutex_lock(QemuMutex *mutex)
{
-int err;
-
-err = pthread_mutex_lock(&mutex->lock);
-if (err)
-error_exit(err, __func__);
+g_static_mutex_lock(&mutex->lock);
}
int qemu_mutex_trylock(QemuMutex *mutex)
{
-return pthread_mutex_trylock(&mutex->lock);
-}
-
-static void timespec_add_ms(struct timespec *ts, uint64_t msecs)
-{
-ts->tv_sec = ts->tv_sec + (long)(msecs / 1000);
-ts->tv_nsec = (ts->tv_nsec + ((long)msecs % 1000) * 100);
-if (ts->tv_nsec >= 10) {
-ts->tv_nsec -= 10;
-ts->tv_sec++;
-}
-}
-
-int qemu_mutex_timedlock(QemuMutex *mutex, uint64_t msecs)
-{
-int err;
-struct timespec ts;
-
-clock_gettime(CLOCK_REALTIME, &ts);
-timespec_add_ms(&ts, msecs);
-
-err = pthread_mutex_timedlock(&mutex->lock, &ts);
-if (err && err != ETIMEDOUT)
-error_exit(err, __func__);
-return err;
+return g_static_mutex_trylock(&mutex->lock);
}
void qemu_mutex_unlock(QemuMutex *mutex)
{
-int err;
-
-err = pthread_mutex_unlock(&mutex->lock);
-if (err)
-error_exit(err, __func__);
+g_static_mutex_unlock(&mutex->lock);
}
void qemu_cond_init(QemuCond *cond)
{
-int err;
-
-err = pthread_cond_init(&cond->cond, NULL);
-if (err)
-error_exit(err, __func__);
+cond->cond = g_cond_new();
}
void qemu_cond_destroy(QemuCond *cond)
{
-int err;
-
-err = pthread_cond_destroy(&cond->cond);
-if (err)
-error_exit(err, __func__);
+g_cond_free(cond->cond);
}
void qemu_cond_signal(QemuCond *cond)
{
-int err;
-
-err = pthread_cond_signal(&cond->cond);
-if (err)
-error_exit(err, __func__);
+g_cond_signal(cond->cond);
}
void qemu_cond_broadcast(QemuCond *cond)
{
-int err;
-
-err = pthread_cond_broadcast(&cond->cond);
-if (err)
-error_exit(err, __f
[Qemu-devel] [PATCH 2/7] Enable I/O thread and VNC threads by default
Leave the disable options for now to help with testing but these will be removed once we're confident in the thread implementations. Disabled code bit rots. These have been in tree long enough that we need to either commit to making them work or just remove them entirely. Signed-off-by: Anthony Liguori diff --git a/configure b/configure index d68f862..d5ac074 100755 --- a/configure +++ b/configure @@ -124,7 +124,7 @@ vnc_tls="" vnc_sasl="" vnc_jpeg="" vnc_png="" -vnc_thread="no" +vnc_thread="yes" xen="" linux_aio="" attr="" @@ -161,7 +161,7 @@ darwin_user="no" bsd_user="no" guest_base="" uname_release="" -io_thread="no" +io_thread="yes" mixemu="no" kerneldir="" aix="no" @@ -699,6 +699,8 @@ for opt do ;; --enable-io-thread) io_thread="yes" ;; + --disable-io-thread) io_thread="no" + ;; --disable-blobs) blobs="no" ;; --kerneldir=*) kerneldir="$optarg" @@ -901,6 +903,7 @@ echo " --enable-linux-aio enable Linux AIO support" echo " --disable-attr disables attr and xattr support" echo " --enable-attrenable attr and xattr support" echo " --enable-io-thread enable IO thread" +echo " --disable-io-thread disable IO thread" echo " --disable-blobs disable installing provided firmware blobs" echo " --kerneldir=PATH look for kernel includes in PATH" echo " --enable-docsenable documentation build" -- 1.7.0.4
Re: [Qemu-devel] qemu-user: relocating target code weakness
Hi! Thank you for your answer! he is telling you what ELF_START_MMAP is all about. it is the base address that the linux kernel for that architecture will start giving out addresses. so when running Linux on an x86 system, the first mmap() a process does will start at 0x8000 and move up. although looking at the elfload code quickly, it doesnt seem that this is really used anymore. so it probably can be ignored. Uhmm that makes sense and explains many things like why they can simply consider always possible that the target is allocated at elf_ppnt->p_vaddr, without risking it to clash with qemu-user code.. Inside load_elf_binary the call to mmap has elf_ppnt->p_vaddr as required starting address (plus alignment) and MAP_FIXED flag. review the mmap() man page ... MAP_FIXED is always a *suggestion* and never a requirement. the app must check the return value to see what the kernel actually gave it. Sorry, wrong! *MAP_FIXED* Don't interpret/addr/ as a hint: place the mapping at exactly that address. [] If the specified address cannot be used,*mmap*() will fail.[] http://www.kernel.org/doc/man-pages/online/pages/man2/mmap.2.html Thank you! Best regards! Stefano B.
Re: [Qemu-devel] [PATCH v4 0/5][RFC] New SPARC machine: Leon3
Thanks, applied all. On Mon, Jan 24, 2011 at 11:56 AM, Fabien Chouteau wrote: > Hello Qemu-devel, > > Here is the fourth version of Leon3 emulation patch-set. > > Modifications since v3: > - Tracepoints in leon3.c > - Fix compilation error in user mode (target-sparc/op_helper.c) > - Remove unused variable in leon3. > - Minor reformating (style errors from checkpatch.pl) > > Please feel free to comment. > > Regards, > > --- > > This patch set introduces a new SPARC V8 machine: Leon3. It's an open-source > VHDL System-On-Chip, well known in space industry (more information on > http://www.gaisler.com). > > Leon3 is made of multiple components available in the GrLib VHDL library. > Three devices are implemented: uart, timers and IRQ manager. > You can find code for these peripherals in the grlib_* files. > > Modifications have been done to the SPARC cpu emulation code to handle > Leon3's specific behavior: > - IRQ management > - Cache control > - Asr17 (implementation-dependent Ancillary State Registers) > - Shutdown > > Fabien Chouteau (5): > SPARC: Emulation of GRLIB GPTimer > SPARC: Emulation of GRLIB IRQMP > SPARC: Emulation of GRLIB APB UART > SPARC: Emulation of Leon3 > SPARC: Add asr17 register support > > Makefile.target | 5 +- > hw/grlib.h | 126 +++ > hw/grlib_apbuart.c | 187 ++ > hw/grlib_gptimer.c | 395 > ++ > hw/grlib_irqmp.c | 376 +++ > hw/leon3.c | 218 + > target-sparc/cpu.h | 38 +++-- > target-sparc/helper.c | 8 +- > target-sparc/helper.h | 1 + > target-sparc/op_helper.c | 156 ++- > target-sparc/translate.c | 24 +++- > trace-events | 24 +++ > 12 files changed, 1536 insertions(+), 22 deletions(-) > create mode 100644 hw/grlib.h > create mode 100644 hw/grlib_apbuart.c > create mode 100644 hw/grlib_gptimer.c > create mode 100644 hw/grlib_irqmp.c > create mode 100644 hw/leon3.c > > >
[Qemu-devel] [Bug 688085] Re: Guest kernel hang during boot when KVM is active on i386 host
Error still can be reproduced on patched 2.6.35-24-generic-pae, amd64, Athlon II X2 220, 4Gb, Maverick. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/688085 Title: Guest kernel hang during boot when KVM is active on i386 host Status in meego project: In Progress Status in QEMU: Fix Released Status in qemu-kvm: Fix Released Status in “kvm” package in Ubuntu: Invalid Status in “linux” package in Ubuntu: Fix Committed Status in “qemu” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: Invalid Status in “kvm” source package in Maverick: New Status in “linux” source package in Maverick: New Status in “qemu” source package in Maverick: New Status in “qemu-kvm” source package in Maverick: New Bug description: Binary package hint: qemu Guest kernel hang during boot when KVM is active on i386 host See the patch. http://www.spinics.net/lists/kvm/msg40800.html How to reproduce: 1. install Maversick x86 (not amd64) 2. ensure you have kvm support in processor 3. kvm -kernel /boot/initrd.img-2.6.35-24-generic-pae 4. kvm -no-kvm -kernel /boot/initrd.img-2.6.35-24-generic-pae works OK. SRU Justification: Impact: Users cannot boot KVM guests on i386 hosts 2. How bug addressed: The upstream commit at http://www.spinics.net/lists/kvm/msg40800.html fixed it 3. Patch: A kernel patch is attached to this bug. 4. Reproduce: boot an i386 kernel on a kvm-capable host. Try to boot a kvm guest. 5. Regression potential: since this is cherrypicking a commit from a future upstream which had already been changed, regression is possible. However if there is a regression, it should only affect users of KVM on i386 hosts, which currently fail anyway.
Re: [Qemu-devel] [PATCH v5 2/4] virtio-pci: Use ioeventfd for virtqueue notify
Am 24.01.2011 20:47, schrieb Michael S. Tsirkin: > On Mon, Jan 24, 2011 at 08:48:05PM +0100, Kevin Wolf wrote: >> Am 24.01.2011 20:36, schrieb Michael S. Tsirkin: >>> On Mon, Jan 24, 2011 at 07:54:20PM +0100, Kevin Wolf wrote: Am 12.12.2010 16:02, schrieb Stefan Hajnoczi: > Virtqueue notify is currently handled synchronously in userspace virtio. > This > prevents the vcpu from executing guest code while hardware emulation code > handles the notify. > > On systems that support KVM, the ioeventfd mechanism can be used to make > virtqueue notify a lightweight exit by deferring hardware emulation to the > iothread and allowing the VM to continue execution. This model is > similar to > how vhost receives virtqueue notifies. > > The result of this change is improved performance for userspace virtio > devices. > Virtio-blk throughput increases especially for multithreaded scenarios and > virtio-net transmit throughput increases substantially. > > Some virtio devices are known to have guest drivers which expect a notify > to be > processed synchronously and spin waiting for completion. Only enable > ioeventfd > for virtio-blk and virtio-net for now. > > Care must be taken not to interfere with vhost-net, which uses host > notifiers. If the set_host_notifier() API is used by a device > virtio-pci will disable virtio-ioeventfd and let the device deal with > host notifiers as it wishes. > > After migration and on VM change state (running/paused) virtio-ioeventfd > will enable/disable itself. > > * VIRTIO_CONFIG_S_DRIVER_OK -> enable virtio-ioeventfd > * !VIRTIO_CONFIG_S_DRIVER_OK -> disable virtio-ioeventfd > * virtio_pci_set_host_notifier() -> disable virtio-ioeventfd > * vm_change_state(running=0) -> disable virtio-ioeventfd > * vm_change_state(running=1) -> enable virtio-ioeventfd > > Signed-off-by: Stefan Hajnoczi On current git master I'm getting hangs when running iozone on a virtio-blk disk. "Hang" means that it's not responsive any more and has 100% CPU consumption. I bisected the problem to this patch. Any ideas? Kevin >>> >>> Does it help if you set ioeventfd=off on command line? >> >> Yes, with ioeventfd=off it seems to work fine. >> >> Kevin > > Then it's the ioeventfd that is to blame. > Is it the io thread that consumes 100% CPU? > Or the vcpu thread? I was building with the default options, i.e. there is no IO thread. Now I'm just running the test with IO threads enabled, and so far everything looks good. So I can only reproduce the problem with IO threads disabled. Kevin
Re: [Qemu-devel] qemu-user: relocating target code weakness
On Mon, Jan 24, 2011 at 13:16, Stefano Bonifazi wrote: >> Start address in which address the ELF code section, in reality (not >> under qemu-user) should be mapped. in x86 32 bit it's 08048000, you >> can check it by yourself by executing: >> cat /proc/self/maps > > Wait, like that I don't understand anything more.. As far as I understood > when calling mmap from within a process, its result, when no error happen, > would be the virtual address where the mapping starts.. so if I get > 0x1000 from mmap why should it be 08048000 instead?? he is telling you what ELF_START_MMAP is all about. it is the base address that the linux kernel for that architecture will start giving out addresses. so when running Linux on an x86 system, the first mmap() a process does will start at 0x8000 and move up. although looking at the elfload code quickly, it doesnt seem that this is really used anymore. so it probably can be ignored. > Inside load_elf_binary the call to mmap has elf_ppnt->p_vaddr as required > starting address (plus alignment) and MAP_FIXED flag. review the mmap() man page ... MAP_FIXED is always a *suggestion* and never a requirement. the app must check the return value to see what the kernel actually gave it. -mike
Re: [Qemu-devel] [PATCH v5 2/4] virtio-pci: Use ioeventfd for virtqueue notify
On Mon, Jan 24, 2011 at 08:48:05PM +0100, Kevin Wolf wrote: > Am 24.01.2011 20:36, schrieb Michael S. Tsirkin: > > On Mon, Jan 24, 2011 at 07:54:20PM +0100, Kevin Wolf wrote: > >> Am 12.12.2010 16:02, schrieb Stefan Hajnoczi: > >>> Virtqueue notify is currently handled synchronously in userspace virtio. > >>> This > >>> prevents the vcpu from executing guest code while hardware emulation code > >>> handles the notify. > >>> > >>> On systems that support KVM, the ioeventfd mechanism can be used to make > >>> virtqueue notify a lightweight exit by deferring hardware emulation to the > >>> iothread and allowing the VM to continue execution. This model is > >>> similar to > >>> how vhost receives virtqueue notifies. > >>> > >>> The result of this change is improved performance for userspace virtio > >>> devices. > >>> Virtio-blk throughput increases especially for multithreaded scenarios and > >>> virtio-net transmit throughput increases substantially. > >>> > >>> Some virtio devices are known to have guest drivers which expect a notify > >>> to be > >>> processed synchronously and spin waiting for completion. Only enable > >>> ioeventfd > >>> for virtio-blk and virtio-net for now. > >>> > >>> Care must be taken not to interfere with vhost-net, which uses host > >>> notifiers. If the set_host_notifier() API is used by a device > >>> virtio-pci will disable virtio-ioeventfd and let the device deal with > >>> host notifiers as it wishes. > >>> > >>> After migration and on VM change state (running/paused) virtio-ioeventfd > >>> will enable/disable itself. > >>> > >>> * VIRTIO_CONFIG_S_DRIVER_OK -> enable virtio-ioeventfd > >>> * !VIRTIO_CONFIG_S_DRIVER_OK -> disable virtio-ioeventfd > >>> * virtio_pci_set_host_notifier() -> disable virtio-ioeventfd > >>> * vm_change_state(running=0) -> disable virtio-ioeventfd > >>> * vm_change_state(running=1) -> enable virtio-ioeventfd > >>> > >>> Signed-off-by: Stefan Hajnoczi > >> > >> On current git master I'm getting hangs when running iozone on a > >> virtio-blk disk. "Hang" means that it's not responsive any more and has > >> 100% CPU consumption. > >> > >> I bisected the problem to this patch. Any ideas? > >> > >> Kevin > > > > Does it help if you set ioeventfd=off on command line? > > Yes, with ioeventfd=off it seems to work fine. > > Kevin Then it's the ioeventfd that is to blame. Is it the io thread that consumes 100% CPU? Or the vcpu thread? -- MST
Re: [Qemu-devel] [PATCH v5 2/4] virtio-pci: Use ioeventfd for virtqueue notify
Am 24.01.2011 20:36, schrieb Michael S. Tsirkin: > On Mon, Jan 24, 2011 at 07:54:20PM +0100, Kevin Wolf wrote: >> Am 12.12.2010 16:02, schrieb Stefan Hajnoczi: >>> Virtqueue notify is currently handled synchronously in userspace virtio. >>> This >>> prevents the vcpu from executing guest code while hardware emulation code >>> handles the notify. >>> >>> On systems that support KVM, the ioeventfd mechanism can be used to make >>> virtqueue notify a lightweight exit by deferring hardware emulation to the >>> iothread and allowing the VM to continue execution. This model is similar >>> to >>> how vhost receives virtqueue notifies. >>> >>> The result of this change is improved performance for userspace virtio >>> devices. >>> Virtio-blk throughput increases especially for multithreaded scenarios and >>> virtio-net transmit throughput increases substantially. >>> >>> Some virtio devices are known to have guest drivers which expect a notify >>> to be >>> processed synchronously and spin waiting for completion. Only enable >>> ioeventfd >>> for virtio-blk and virtio-net for now. >>> >>> Care must be taken not to interfere with vhost-net, which uses host >>> notifiers. If the set_host_notifier() API is used by a device >>> virtio-pci will disable virtio-ioeventfd and let the device deal with >>> host notifiers as it wishes. >>> >>> After migration and on VM change state (running/paused) virtio-ioeventfd >>> will enable/disable itself. >>> >>> * VIRTIO_CONFIG_S_DRIVER_OK -> enable virtio-ioeventfd >>> * !VIRTIO_CONFIG_S_DRIVER_OK -> disable virtio-ioeventfd >>> * virtio_pci_set_host_notifier() -> disable virtio-ioeventfd >>> * vm_change_state(running=0) -> disable virtio-ioeventfd >>> * vm_change_state(running=1) -> enable virtio-ioeventfd >>> >>> Signed-off-by: Stefan Hajnoczi >> >> On current git master I'm getting hangs when running iozone on a >> virtio-blk disk. "Hang" means that it's not responsive any more and has >> 100% CPU consumption. >> >> I bisected the problem to this patch. Any ideas? >> >> Kevin > > Does it help if you set ioeventfd=off on command line? Yes, with ioeventfd=off it seems to work fine. Kevin
Re: [Qemu-devel] qemu-user: relocating target code weakness
On 01/24/2011 03:34 AM, Stefano Bonifazi wrote: > I am working on a project based on qemu-user. More exactly it is > qemu-ppc (version 0.13.0) with x86 host. All the project and > documentation about qemu will be open for everybody as it is a > project for my university that is a public one.. I have the need to > relocate the target code in the memory space to some other starting > address. So I went inside linux-user/elfload.c: load_elf_binary and > there I found many things that according to me are someway buggy or > just "weak" .. Yes. Have a look at http://lists.gnu.org/archive/html/qemu-devel/2010-07/msg01626.html where I tried to clean this up last year. The patch never got properly reviewed, however. All that said, unless you have an executable that's been properly prepared for relocation, e.g. an ET_DYN binary instead of a normal ET_EXEC binary, you will *not* have enough information to do what you're suggesting. r~
Re: [Qemu-devel] TCG flow vs dyngen
On 01/24/2011 07:02 PM, Dushyant Bansal wrote: On Monday 24 January 2011 08:26 PM, Stefano Bonifazi wrote: On 01/24/2011 03:32 PM, Peter Maydell wrote: Being a JIT doesn't prohibit counting target instructions executed. It just means that counting them generally requires generating code to do the counting at runtime, so it's a more complicated change to make than it would be in a non-JIT emulator. What do you mean? Should I change the code of qemu-user for counting the instructions, or should I add code into the target binaries? You should see this pdf (www.ecs.syr.edu/faculty/yin/Teaching/TC2010/Proj4.pdf). It talks about tracing the instructions. -- Dushyant Wow thank you! It sounds incredibly interesting!! What we really need is to insert a function call into the translated code, so when each instruction is executed at runtime, our inserted function will be executed. Again wow!! Is that really possible? Some sort of callback triggered at every instruction execution? Do you have any another document explaining that? This pdf just gives instructions on how to do it on an old version of qemu (disas_insn doesn't exist at all on my code now), and does not explain what it is, what's behind that suggested code .. Also the code for single step would be of great help to me! I really needed that.. but when I tried it on qemu-user didn't work at all.. Thank you very much! Best regards, Stefano B.
Re: [Qemu-devel] [PATCH v5 2/4] virtio-pci: Use ioeventfd for virtqueue notify
On Mon, Jan 24, 2011 at 07:54:20PM +0100, Kevin Wolf wrote: > Am 12.12.2010 16:02, schrieb Stefan Hajnoczi: > > Virtqueue notify is currently handled synchronously in userspace virtio. > > This > > prevents the vcpu from executing guest code while hardware emulation code > > handles the notify. > > > > On systems that support KVM, the ioeventfd mechanism can be used to make > > virtqueue notify a lightweight exit by deferring hardware emulation to the > > iothread and allowing the VM to continue execution. This model is similar > > to > > how vhost receives virtqueue notifies. > > > > The result of this change is improved performance for userspace virtio > > devices. > > Virtio-blk throughput increases especially for multithreaded scenarios and > > virtio-net transmit throughput increases substantially. > > > > Some virtio devices are known to have guest drivers which expect a notify > > to be > > processed synchronously and spin waiting for completion. Only enable > > ioeventfd > > for virtio-blk and virtio-net for now. > > > > Care must be taken not to interfere with vhost-net, which uses host > > notifiers. If the set_host_notifier() API is used by a device > > virtio-pci will disable virtio-ioeventfd and let the device deal with > > host notifiers as it wishes. > > > > After migration and on VM change state (running/paused) virtio-ioeventfd > > will enable/disable itself. > > > > * VIRTIO_CONFIG_S_DRIVER_OK -> enable virtio-ioeventfd > > * !VIRTIO_CONFIG_S_DRIVER_OK -> disable virtio-ioeventfd > > * virtio_pci_set_host_notifier() -> disable virtio-ioeventfd > > * vm_change_state(running=0) -> disable virtio-ioeventfd > > * vm_change_state(running=1) -> enable virtio-ioeventfd > > > > Signed-off-by: Stefan Hajnoczi > > On current git master I'm getting hangs when running iozone on a > virtio-blk disk. "Hang" means that it's not responsive any more and has > 100% CPU consumption. > > I bisected the problem to this patch. Any ideas? > > Kevin Does it help if you set ioeventfd=off on command line?
Re: [Qemu-devel] Re: IRC channel movement -> FreeNode to OFTC
Le 24 janv. 2011 à 20:13, Mike Frysinger a écrit : > On Thu, Dec 9, 2010 at 17:44, Brian Jackson wrote: >> A. Must be registered to talk in a channel > > i'm fairly certain that is a per-channel setting Indeed, only on #qemu do I have to identify to talk, other channels don't require it. >> D. Their non-profit status in the US was terminated for failure to file >> paperwork properly > > not terribly relevant if the network continues to function ... just > dont give them money +1 François.
Re: [Qemu-devel] Re: IRC channel movement -> FreeNode to OFTC
On Thu, Dec 9, 2010 at 17:44, Brian Jackson wrote: > A. Must be registered to talk in a channel i'm fairly certain that is a per-channel setting > C. They have strange rules about groups and channel ownership ive never had a problem > D. Their non-profit status in the US was terminated for failure to file > paperwork properly not terribly relevant if the network continues to function ... just dont give them money -mike
Re: [Qemu-devel] Re: [RFC/PATCH] elfload: add FDPIC support
On Mon, Jan 24, 2011 at 08:34, Stefano Bonifazi wrote: > Is FDPIC something different than simply PIC code (position independent > code)? FDPIC ELF is the ELF PIE format used on NOMMU systems so that both the text and data regions may be located anywhere. it is the only ELF format supported under NOMMU systems. > I am also trying to fight with the problem of changing the starting address > of target code for qemu-user, and I was just moving into the option of using > PIC target code .. but the original qemu-user load_elf_binary does not work > on them.. and I was just about to try to edit it.. i dont believe my patch accomplishes that in any way. i will need to force all files to be loaded at a higher address than zero for the Blackfin arch (as the first ~4KiB is reserved for the ABI), but that is independent of FDPIC ELF support. -mike
Re: [Qemu-devel] [PATCH v5 2/4] virtio-pci: Use ioeventfd for virtqueue notify
Am 12.12.2010 16:02, schrieb Stefan Hajnoczi: > Virtqueue notify is currently handled synchronously in userspace virtio. This > prevents the vcpu from executing guest code while hardware emulation code > handles the notify. > > On systems that support KVM, the ioeventfd mechanism can be used to make > virtqueue notify a lightweight exit by deferring hardware emulation to the > iothread and allowing the VM to continue execution. This model is similar to > how vhost receives virtqueue notifies. > > The result of this change is improved performance for userspace virtio > devices. > Virtio-blk throughput increases especially for multithreaded scenarios and > virtio-net transmit throughput increases substantially. > > Some virtio devices are known to have guest drivers which expect a notify to > be > processed synchronously and spin waiting for completion. Only enable > ioeventfd > for virtio-blk and virtio-net for now. > > Care must be taken not to interfere with vhost-net, which uses host > notifiers. If the set_host_notifier() API is used by a device > virtio-pci will disable virtio-ioeventfd and let the device deal with > host notifiers as it wishes. > > After migration and on VM change state (running/paused) virtio-ioeventfd > will enable/disable itself. > > * VIRTIO_CONFIG_S_DRIVER_OK -> enable virtio-ioeventfd > * !VIRTIO_CONFIG_S_DRIVER_OK -> disable virtio-ioeventfd > * virtio_pci_set_host_notifier() -> disable virtio-ioeventfd > * vm_change_state(running=0) -> disable virtio-ioeventfd > * vm_change_state(running=1) -> enable virtio-ioeventfd > > Signed-off-by: Stefan Hajnoczi On current git master I'm getting hangs when running iozone on a virtio-blk disk. "Hang" means that it's not responsive any more and has 100% CPU consumption. I bisected the problem to this patch. Any ideas? Kevin
Re: [Qemu-devel] Playing with virtfs.
On 01/24/2011 10:15 AM, Aneesh Kumar K. V wrote: > On Sun, 23 Jan 2011 13:33:14 -0600, Rob Landley wrote: >> Using yesterday's -git, following the instructions in >> http://wiki.qemu.org/Documentation/9psetup (which is missing a kernel >> symbol, you need to add CONFIG_VIRTIO_PCI to your kernel too), I managed >> to mount a read-only virtfs filesystem, adding this to the >> qemu-system-x86_64 command line: > > With top of the kernel tree 52cfd503ad7176d23a5dd7af3981744feb60622f > I am able to build the kernel without CONFIG_VIRTIO_PCI. What is the > exact error you are finding ? It wasn't a runtime error, it's that some of the config symbols the instructions told me to switch on were hidden. CONFIG_NET_9P_VIRTIO depends on CONFIG_VIRTIO which is selected by CONFIG_VIRTIO_PCI. If CONFIG_VIRTIO isn't forced on by something, you can't select CONFIG_NET_9P_VIRTIO. >> >> -virtfs >> local,security_model=passthrough,mount_tag=kvm,path=/home/landley/9ptest >> >> And then in the emulated Linux: >> >> root@kvm:~# mount -t 9p -o trans=virtio,version=9p2000.L kvm woot >> root@kvm:~# ls -l woot >> total 80 >> -rw-r--r-- 1 1000 1000 77874 Jan 22 23:33 config-linux >> root@kvm:~# cd woot >> root@kvm:~/woot# touch fred >> touch: setting times of `fred': No such file or directory >> root@kvm:~/woot# >> >> I.E. It seems to work fine read only, but changes are discarded. >> >> Am I doing something wrong, or is this expected? (If so, when is write >> support likely to go in?) >> > > Are you running qemu as root ? Nope, I try to avoid doing that where possible. > Using passthrough security model require > the ability to change the ownership of the file. Otherwise you can use > security=none, but the credentials with which files are created will > not be correct. Yup, that was it. I note that security=mapped behaves like security=passthrough. (Which is a pity, because it would have been the first legitimate use for extended attributes I've seen since I stopped using OS/2.) > -aneesh It works! Thanks. Rob
[Qemu-devel] Re: Errors on MMIO read access on VM suspend / resume operations
On 01/18/2011 03:53 AM, Jan Kiszka wrote: On 2011-01-18 04:03, Stefan Berger wrote: On 01/16/2011 09:43 AM, Avi Kivity wrote: On 01/14/2011 09:27 PM, Stefan Berger wrote: Can you sprinkle some printfs() arount kvm_run (in qemu-kvm.c) to verify this? Here's what I did: interrupt exit requested It appears from this you're using qemu.git. Please try qemu-kvm.git, where the code appears to be correct. Cc'ing qemu-devel now. For reference, here the initial problem description: http://www.spinics.net/lists/kvm/msg48274.html I didn't know there was another tree... I have seen now a couple of suspends-while-reading with patches applied to the qemu-kvm.git tree and indeed, when run with the same host kernel and VM I do not see the debugging dumps due to double-reads that I would have anticipated seeing by now. Now what? Can this be easily fixed in the other Qemu tree as well? Please give this a try: git://git.kiszka.org/qemu-kvm.git queues/kvm-upstream I bet (& hope) "kvm: Unconditionally reenter kernel after IO exits" fixes the issue for you. If other problems pop up with that tree, also try resetting to that particular commit. I'm currently trying to shake all those hidden or forgotten bug fixes out of qemu-kvm and port them upstream. Most of those subtle differences should hopefully soon be history. I did the same test as I did with Avi's tree and haven't seen the consequences of possible double-reads. So, I would say that you should upstream those patches... I searched for the text you mention above using 'gitk' but couldn't find a patch with that headline in your tree. There were others that seem to be related: Gleb Natapov: "do not enter vcpu again if it was stopped during IO" One thing I'd like to mention is that I have seen what I think are interrupt stalls when running my tests inside the qemu-kvm.git tree version and not suspending at all. A some point the interrupt counter in the guest kernel does not increase anymore even though I see the device model raising the IRQ and lowering it. The same tests run literally forever in the qemu.git tree version of Qemu. What about qemu-kmv and -no-kvm-irqchip? That seems to be necessary for both trees, yours and the one Avi pointed me to. If applied, then I did not see the interrupt problem. Stefan Jan
Re: [Qemu-devel] TCG flow vs dyngen
On 01/24/2011 04:17 AM, Stefano Bonifazi wrote: > I read your post, and yup you also noticed the weird of load_bias.. and > wondered how it can work on x86.. > But I think your work was on qemu-system.. I am working on qemu-user.. My post wasn't on qemu-anything, it was while I was trying to debug the uClibc dynamic loader on a new platform (the Qualcomm Hexagon) that Linux support still hasn't gone upstream for yet. The thing is, the kernel currently _does_ work, so studying the relevant kernel code (and possibly the dynamic loader code) is one way to learn how it currently works. Rob
