On Thu, Jun 30, 2011 at 2:57 AM, Fam Zheng wrote:
> On Wed, Jun 29, 2011 at 11:57 PM, Stefan Hajnoczi wrote:
>> On Tue, Jun 28, 2011 at 2:32 AM, Fam Zheng wrote:
>>> + /* trim the quotation marks around */
>>> + if (fname[0] == '"') {
>>> + memmove(fname, fname + 1, strl
The Buildbot has detected a new failure on builder ppc-next_x86_64_debian_5_0
while building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/ppc-next_x86_64_debian_5_0/builds/19
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: yuzuki
The Buildbot has detected a new failure on builder ppc-next_i386_debian_5_0
while building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/ppc-next_i386_debian_5_0/builds/19
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: yuzuki
Bui
[I've sent this patch couple of months ago and noticed it
didn't make it's way in - so I'm sending it again]
It is possible to create CPU-less NUMA nodes, node amount shouldn't be
limited by amount of CPUs.
Tested-by: Michael Roth
Signed-off-by: Sasha Levin
---
vl.c |4 ++--
1 files chang
Thank for your answer.
Beside nbench, I'm also using Dhrystone to measure the guest cpu performance.
The performance does not much diffetence too.
Is the emulated guest performance not depend on guest processor clock?
Tai
Từ: Mulyadi Santosa
Đến: Lê Đức Tài
On Wed, Jun 29, 2011 at 11:57 PM, Stefan Hajnoczi wrote:
> On Tue, Jun 28, 2011 at 2:32 AM, Fam Zheng wrote:
>> +/* find an option value out of descriptor file */
>> +static int vmdk_parse_description(const char *desc, const char *opt_name,
>> + char *buf, int buf_size)
>> +{
>> + char
On Wed, Jun 29, 2011 at 1:10 AM, Bob Breuer wrote:
> Super Bisquit wrote:
> >
> ...
> >
> > It builds, doesn't run. More like it runs and hangs.
> >
> > $ qemu-system-sparc -cpu LEON3 -hda test.img -cdrom
> Downloads/debian-6.0.2.1-sparc-businesscard.iso -m 256 -boot d
> >
>
> That command line w
Hi Andreas,
> This fixes Darwin/ppc64 (and ppc) v10.5.
> Don't know whether v10.6 / i386 might have a working implementation (cc'ing
> Alexand{re,er}).
In 10.6, I get the following error when I try to compile a simple getcontext():
/usr/include/ucontext.h:42:2: error: #error ucontext routines are
The Buildbot has detected a new failure on builder block_i386_debian_5_0 while
building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/block_i386_debian_5_0/builds/19
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: yuzuki
Build Rea
The Buildbot has detected a new failure on builder block_x86_64_debian_5_0
while building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/block_x86_64_debian_5_0/builds/19
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: yuzuki
Build
On Wed, Jun 29, 2011 at 09:39:52PM +0100, Peter Maydell wrote:
> On 29 June 2011 21:07, Edgar E. Iglesias wrote:
> > On Wed, Jun 29, 2011 at 07:53:10PM +0100, Peter Maydell wrote:
> >> Don't complain about some writes to r/o OMAP2 GPIO registers, because the
> >> kernel will do them anyway.
> >>
>
On Wed, Jun 29, 2011 at 04:50:10PM +0200, Gerd Hoffmann wrote:
> >>>+case QXL_IO_FLUSH_RELEASE: {
> >>>+QXLReleaseRing *ring =&d->ram->release_ring;
> >>>+if (ring->prod - ring->cons + 1 == ring->num_items) {
> >>>+// TODO - "return" a value to the guest and let it l
On 29 June 2011 21:07, Edgar E. Iglesias wrote:
> On Wed, Jun 29, 2011 at 07:53:10PM +0100, Peter Maydell wrote:
>> Don't complain about some writes to r/o OMAP2 GPIO registers, because the
>> kernel will do them anyway.
>>
>> Signed-off-by: Peter Maydell
>
> Hi Peter,
>
> I usually find this kin
On 29 June 2011 18:08, d...@ucore.info wrote:
> On Wed, Jun 29, 2011 at 4:52 PM, Peter Maydell
> wrote:
>> Which machine are you using? The default (integratorcp) does not
>> have a USB controller modelled, so there's nothing to plug the
>> tablet into and QEMU fails with the above slightly cryp
On Wed, Jun 29, 2011 at 07:53:10PM +0100, Peter Maydell wrote:
> Don't complain about some writes to r/o OMAP2 GPIO registers, because the
> kernel will do them anyway.
>
> Signed-off-by: Peter Maydell
Hi Peter,
I usually find this kind of logs useful.
Maybe we should turn them into _log_mask(~
On Wed, Jun 29, 2011 at 4:52 PM, Peter Maydell wrote:
> Which machine are you using? The default (integratorcp) does not
> have a USB controller modelled, so there's nothing to plug the
> tablet into and QEMU fails with the above slightly cryptic message...
> Try "-M versatilepb".
Hmmm. I'm using
From: Juha Riihimäki
Add helper function omap_l4_base() to return the base address of a
particular region of an L4 target agent.
Signed-off-by: Juha Riihimäki
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio
[Peter Maydell: More fixes and cleanups for upstream submiss
Hi,
Am 29.06.2011 um 10:33 schrieb Gerd Hoffmann:
Erm, I'm not aware that my qdev bool patch got committed yet, so the
question of how to parse/print bool properties (on/off vs. yes/no) is
still undecided, no comments so far. It would be entirely possible to
let the author decide that on a case
From: Juha Riihimäki
Convert the OMAP GPIO module to qdev.
Signed-off-by: Juha Riihimäki
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by: Peter Maydell
---
hw/nseries.c | 47 +--
These patches are changes from the meego omap3 tree which convert
the omap GPIO module device to use qdev.
My general plan for landing the omap3 changes is to start by peeling
off reasonably independent chunks which can be presented as fixes
or cleanups to the existing omap1/omap2 code, and this i
Don't complain about some writes to r/o OMAP2 GPIO registers, because the
kernel will do them anyway.
Signed-off-by: Peter Maydell
---
hw/omap_gpio.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/omap_gpio.c b/hw/omap_gpio.c
index 478f7d9..b53b13b 100644
--- a/hw
On Wed, Jun 29, 2011 at 05:00:20PM +0200, Gerd Hoffmann wrote:
> On 06/29/11 16:29, Alon Levy wrote:
> >On Wed, Jun 29, 2011 at 03:09:36PM +0200, Gerd Hoffmann wrote:
> >>Hi,
> >>
> >>>+case QXL_IO_DESTROY_ALL_SURFACES_ASYNC: +d->mode =
> >>>QXL_MODE_UNDEFINED;
> >>
> >>Should go to the
On Wed, Jun 29, 2011 at 05:30:24PM +0200, Alexander Graf wrote:
>
> On 29.06.2011, at 17:28, Michael S. Tsirkin wrote:
>
> > On Wed, Jun 29, 2011 at 04:07:50PM +0200, Alexander Graf wrote:
> >>
> >> On 29.06.2011, at 15:59, Michael S. Tsirkin wrote:
> >>
> >>> On Wed, Jun 29, 2011 at 03:22:33PM
On Wed, Jun 29, 2011 at 04:07:50PM +0200, Alexander Graf wrote:
>
> On 29.06.2011, at 15:59, Michael S. Tsirkin wrote:
>
> > On Wed, Jun 29, 2011 at 03:22:33PM +0200, Alexander Graf wrote:
> >>
> >> On 29.06.2011, at 15:11, Michael S. Tsirkin wrote:
> >>
> >>> On Wed, Jun 29, 2011 at 03:02:46PM
On Tue, Jun 28, 2011 at 2:32 AM, Fam Zheng wrote:
Please use "block:" as the commit message tag instead of BlockDriver.
Usually the easiest way to find out which tag to use it by doing
git-log(1) on the main file you have modified and looking at previous
commit messages.
> +static int64_t vmdk_ge
On Wed, Jun 29, 2011 at 09:20:03AM -0500, Anthony Liguori wrote:
> Sorry, I meant having a new cache option (maybe diskcache). Semantics
> would be:
>
> diskcache=on,wce=on0
> diskcache=on,wce=off O_SYNC
> diskcache=off,wce=on O_DIRECT
> diskcache=off,wce=off O_DIRECT | O_SYNC
>
> ignore
On Wed, Jun 29, 2011 at 3:13 PM, Anthony Liguori wrote:
> On 06/29/2011 08:50 AM, Christoph Hellwig wrote:
>>
>> On Wed, Jun 29, 2011 at 07:23:31AM -0500, Anthony Liguori wrote:
>>>
>>> Which file system on the host?
>>
>> Any filesystem. Although extN and btrfs are particularly bad.
>>
>>> At an
On Tue, Jun 28, 2011 at 2:32 AM, Fam Zheng wrote:
> +/* find an option value out of descriptor file */
> +static int vmdk_parse_description(const char *desc, const char *opt_name,
> + char *buf, int buf_size)
> +{
> + char *opt_pos, *opt_end;
> + const char *end = desc + strlen(desc);
On Wed, Jun 29, 2011 at 06:17:02PM +0400, Michael Tokarev wrote:
> > Honestly, I don't know. Usually the problem is resolved with setting a
> > different cache option, so nobody bothers to ask for details. I'd guess
> > that it's ext4 in most cases.
>
> Extremly poor performance also happens on ra
On Wed, Jun 29, 2011 at 11:08:23AM +0100, Stefan Hajnoczi wrote:
> On Wed, Jun 29, 2011 at 8:57 AM, Kevin Wolf wrote:
> > Am 28.06.2011 21:41, schrieb Marcelo Tosatti:
> >> stream
> >> --
> >>
> >> 1) base <- remote
> >> 2) base <- remote <- local
> >> 3) base <- local
> >>
> >> "local" image
On 06/29/2011 09:52 AM, Christoph Hellwig wrote:
On Wed, Jun 29, 2011 at 09:20:03AM -0500, Anthony Liguori wrote:
Sorry, I meant having a new cache option (maybe diskcache). Semantics
would be:
diskcache=on,wce=on0
diskcache=on,wce=off O_SYNC
diskcache=off,wce=on O_DIRECT
diskcache=off
Hi,
Hmm, this looks pretty much like something added to debug a specific
issue, not something useful for tracing in general ...
ok. can you just drop it from the queue so I can avoid sending a v4?
Pushed a new bz700134 branch version with bits cherry-picked, just
resend anything which isn
29.06.2011 18:50, Christoph Hellwig wrote:
> On Wed, Jun 29, 2011 at 06:17:02PM +0400, Michael Tokarev wrote:
>>> Honestly, I don't know. Usually the problem is resolved with setting a
>>> different cache option, so nobody bothers to ask for details. I'd guess
>>> that it's ext4 in most cases.
>>
>
29.06.2011 16:32, Kevin Wolf wrote:
> Am 29.06.2011 14:23, schrieb Anthony Liguori:
>> On 06/29/2011 07:16 AM, Kevin Wolf wrote:
>>> No, people are also complaining about bad performance with raw. Which
>>> isn't really surprising when you do a flush after each single write
>>> request. O_SYNC is
Hi,
Agreed. So keep PANIC_ON but remove a lot of it's users, or add some wrapper
that depends on a "guest_panic" parameter that defaults off.
Maybe keep PANIC_ON in case there are any which can trigger on qemu bugs
only. Add a new one where the name makes clear this triggers on case
the g
On 06/29/2011 03:22 PM, Alexander Graf wrote:
Well, you need to make sure that it only gets included on Linux
systems and if there's ever some more compatibility wrapping around
the syscall (unlikely, but you never know), this could potentially
break.
Also, who defines SYS_eventfd? What if you'r
On Wed, Jun 29, 2011 at 04:11:53PM +0200, Kevin Wolf wrote:
> If the guest is acting correctly, then this assumption is definitely
> true with cache=none/writeback. What needs to happen is that the guest
> issues a disk flush before sending your "transaction ok" message. If it
> doesn't do that it
On Wed, Jun 29, 2011 at 03:11:56PM +0200, Gerd Hoffmann wrote:
> On 06/29/11 13:57, Alon Levy wrote:
> >---
> > pc-bios/bios.bin| Bin 131072 -> 26 bytes
> > pc-bios/vgabios-qxl.bin | Bin 40448 -> 41 bytes
> > 2 files changed, 0 insertions(+), 0 deletions(-)
> > mode change 100644 =>
This path works regardless of the current compilation directory.
Signed-off-by: Lluís Vilanova
---
Makefile.target |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile.target b/Makefile.target
index 38afdb8..9967198 100644
--- a/Makefile.target
+++ b/Makefile.target
Hi,
ok - so I guess I'll wait for that and then send the S3-S4 using ASYNC
for the FLUSH_SURFACES patch separately. (I guess I'll call it
FLUSH_SURFACES_ASYNC
and FLUSH_RELEASE_ASYNC? or just the former ASYNC?
Just the surfaces. The release one doesn't go sleep.
cheers,
Gerd
Am 29.06.2011 15:53, schrieb Frediano Ziglio:
> 2011/6/29 Anthony Liguori :
>> On 06/29/2011 07:16 AM, Kevin Wolf wrote:
>>>
>>> Am 29.06.2011 14:06, schrieb Anthony Liguori:
On 06/29/2011 06:59 AM, Kevin Wolf wrote:
>
> Hi,
>
> I think we have touched this topic before du
On Wed, Jun 29, 2011 at 03:09:36PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> >+case QXL_IO_DESTROY_ALL_SURFACES_ASYNC:
> >+d->mode = QXL_MODE_UNDEFINED;
>
> Should go to the async thread.
doesn't it make more sense to do all state changes from the vcpu thread? async
thread can run muc
On 29.06.2011, at 17:28, Michael S. Tsirkin wrote:
> On Wed, Jun 29, 2011 at 04:07:50PM +0200, Alexander Graf wrote:
>>
>> On 29.06.2011, at 15:59, Michael S. Tsirkin wrote:
>>
>>> On Wed, Jun 29, 2011 at 03:22:33PM +0200, Alexander Graf wrote:
On 29.06.2011, at 15:11, Michael S. Tsi
On 06/29/11 16:29, Alon Levy wrote:
On Wed, Jun 29, 2011 at 03:09:36PM +0200, Gerd Hoffmann wrote:
Hi,
+case QXL_IO_DESTROY_ALL_SURFACES_ASYNC: +d->mode =
QXL_MODE_UNDEFINED;
Should go to the async thread.
doesn't it make more sense to do all state changes from the vcpu
thread?
On Wed, Jun 29, 2011 at 03:22:33PM +0200, Alexander Graf wrote:
>
> On 29.06.2011, at 15:11, Michael S. Tsirkin wrote:
>
> > On Wed, Jun 29, 2011 at 03:02:46PM +0200, Alexander Graf wrote:
> >>
> >> On 28.06.2011, at 17:35, Michael S. Tsirkin wrote:
> >>
> >>> Support build on RHEL 5.X where we
On Wed, Jun 29, 2011 at 03:06:33PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> >+case QXL_IO_FLUSH_SURFACES:
> >+dprint(d, 1, "QXL_IO_FLUSH_SURFACES (%d) entry (%s, s#=%d,
> >res#=%d)\n",
> >+val, qxl_mode_to_string(d->mode), d->guest_surfaces.count,
> >+d->num_fre
On 29 June 2011 14:21, d...@ucore.info wrote:
> I'm trying to get the tablet emulation for Qemu's VNC server to handle
> the mouse better. I'm using `qemu-system-arm` and everything is OK
> except for the mouse movement.
>
> After I add `-usb -usbdevie table` argument to `qemu-system-arm`
> invoca
On Wed, Jun 29, 2011 at 03:03:32PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> >-dprint(d, 1, "%s: unexpected port 0x%x in vga mode\n",
> >__FUNCTION__, io_port);
> >+dprint(d, 1, "%s: unexpected port 0x%x (%s) in vga mode\n",
> >+__FUNCTION__, io_port, io_port_to_string(i
On Wed, Jun 29, 2011 at 09:13:35AM -0500, Anthony Liguori wrote:
> Is WCE ever persisted by a disk? Would it make sense to have a mechanism
> to persist the WCE setting for a guest?
Only for SCSI, which has persistant mode pages. For ATA I've not found
a way to make it persistent yet.
2011/6/29 Anthony Liguori :
> On 06/29/2011 07:16 AM, Kevin Wolf wrote:
>>
>> Am 29.06.2011 14:06, schrieb Anthony Liguori:
>>>
>>> On 06/29/2011 06:59 AM, Kevin Wolf wrote:
Hi,
I think we have touched this topic before during some IRC discussions or
somewhere deep in a mai
+case QXL_IO_FLUSH_RELEASE: {
+QXLReleaseRing *ring =&d->ram->release_ring;
+if (ring->prod - ring->cons + 1 == ring->num_items) {
+// TODO - "return" a value to the guest and let it loop?
Hmm.
So the story goes: I wrote this, but didn't ac
On Wed, Jun 29, 2011 at 03:06:33PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> >+case QXL_IO_FLUSH_SURFACES:
> >+dprint(d, 1, "QXL_IO_FLUSH_SURFACES (%d) entry (%s, s#=%d,
> >res#=%d)\n",
> >+val, qxl_mode_to_string(d->mode), d->guest_surfaces.count,
> >+d->num_fre
On Wed, Jun 29, 2011 at 07:23:31AM -0500, Anthony Liguori wrote:
> Which file system on the host?
Any filesystem. Although extN and btrfs are particularly bad.
> At any rate, I'm a big fan of making wce tunable in the guest and then I
> think setting wce=1 is quite reasonable to do by default.
On 06/29/2011 08:55 AM, Christoph Hellwig wrote:
On Wed, Jun 29, 2011 at 07:08:18AM -0500, Anthony Liguori wrote:
As long as we advertise wce and wce can be toggled from the guest, I don't
think the default is all that important. I think cache=on is the right
default for most common use cases.
Am 29.06.2011 16:12, schrieb Christoph Hellwig:
> On Wed, Jun 29, 2011 at 04:11:53PM +0200, Kevin Wolf wrote:
>> If the guest is acting correctly, then this assumption is definitely
>> true with cache=none/writeback. What needs to happen is that the guest
>> issues a disk flush before sending your
On Linux x86_64 host with 32bit userspace, running
qemu or even just "qemu-img create -f qcow2 some.img 1G"
causes a kernel warning:
ioctl32(qemu-img:5296): Unknown cmd fd(3) cmd(5326){t:'S';sz:0}
arg(7fff) on some.img
ioctl32(qemu-img:5296): Unknown cmd fd(3) cmd(801c0204){t:02;sz:28}
a
On Linux x86_64 host with 32bit userspace, running
qemu or even just "qemu-img create -f qcow2 some.img 1G"
causes a kernel warning:
ioctl32(qemu-img:5296): Unknown cmd fd(3) cmd(5326){t:'S';sz:0}
arg(7fff) on some.img
ioctl32(qemu-img:5296): Unknown cmd fd(3) cmd(801c0204){t:02;sz:28}
a
On 29.06.2011, at 15:57, Stefan Hajnoczi wrote:
> On Wed, Jun 29, 2011 at 1:21 PM, Alexander Graf wrote:
>> On 29.06.2011, at 13:59, Kevin Wolf wrote:
>>> I'm not entirely sure if I should suggest writeback or none as the new
>>> default, but I think it could make sense to change it.
>>
>> None
On 29.06.2011, at 15:59, Michael S. Tsirkin wrote:
> On Wed, Jun 29, 2011 at 03:22:33PM +0200, Alexander Graf wrote:
>>
>> On 29.06.2011, at 15:11, Michael S. Tsirkin wrote:
>>
>>> On Wed, Jun 29, 2011 at 03:02:46PM +0200, Alexander Graf wrote:
On 28.06.2011, at 17:35, Michael S. Tsi
On Wed, Jun 29, 2011 at 03:01:30PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> >-dprint(d, 1, "%s: done\n", __FUNCTION__);
> >+dprint(d, 1, "%s: done (num_free_res %d, %p)\n", __FUNCTION__,
> >+d->num_free_res, d->last_release);
>
> > case QXL_IO_RESET:
> >-dprint(d, 1, "
Hi, QEMU folks
I know that I might have a bad title for this post, but I just don't
have better idea for the title.
I'm developing virtio support for Xen pv guest, hoping to reuse the
virtio infrastructure in qemu, i.e. I'm planning to use qemu as
"virtio backend" for Xen pv. And qemu can be run
This patch series adds support for some ioctls related to the Linux
frame-buffer/console. It was fully tested for the SH4 target and
partially tested for the x86_64 and ARM targets, this latter fails the
"setleds" tests (embedded within the first commit message) but it
seems the problem doesn't co
On Wed, Jun 29, 2011 at 01:52:19PM +0100, Stefan Hajnoczi wrote:
> Whether it is safe to transition to cache=none or not depends on what
> broken guests are still widely deployed. Does CentOS 5 flush the disk
> cache?
Unless you use ext3 it does. The same unfortunate story still applies to
curre
On Wed, Jun 29, 2011 at 02:44:11PM +0200, Gerd Hoffmann wrote:
> On 06/29/11 13:57, Alon Levy wrote:
> >---
> > hw/qxl.h |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> >diff --git a/hw/qxl.h b/hw/qxl.h
> >index 7df594e..bf875a0 100644
> >--- a/hw/qxl.h
> >+++ b/hw/qxl.h
> >@
On Wed, Jun 29, 2011 at 1:21 PM, Alexander Graf wrote:
> On 29.06.2011, at 13:59, Kevin Wolf wrote:
>> I'm not entirely sure if I should suggest writeback or none as the new
>> default, but I think it could make sense to change it.
>
> None as default would be a bad choice, as not all underlying f
This patch was validated with programs from DirectFB-1.0 and
WebKit/DirectFB.
Signed-off-by: Cédric VINCENT
Cc: Riku Voipio
---
linux-user/ioctls.h|5 +
linux-user/syscall_defs.h |5 +
linux-user/syscall_types.h | 13 +
3 files changed, 23 insertions(+), 0
On 06/29/2011 08:50 AM, Christoph Hellwig wrote:
On Wed, Jun 29, 2011 at 07:23:31AM -0500, Anthony Liguori wrote:
Which file system on the host?
Any filesystem. Although extN and btrfs are particularly bad.
At any rate, I'm a big fan of making wce tunable in the guest and then I
think setti
On Wed, Jun 29, 2011 at 07:08:18AM -0500, Anthony Liguori wrote:
> As long as we advertise wce and wce can be toggled from the guest, I don't
> think the default is all that important. I think cache=on is the right
> default for most common use cases.
What do you mean with cache=on? We have
ca
Hi,
-dprint(d, 1, "%s: done\n", __FUNCTION__);
+dprint(d, 1, "%s: done (num_free_res %d, %p)\n", __FUNCTION__,
+d->num_free_res, d->last_release);
case QXL_IO_RESET:
-dprint(d, 1, "QXL_IO_RESET\n");
+dprint(d, 1, "QXL_IO_RESET %d (%p)\n", d->num_free_re
On 06/29/2011 04:05 PM, Anthony Liguori wrote:
So long as -M old retains the old behaviour, I'm in favour.
wce needs to be preserved but cache wouldn't need to be AFAICT.
Right.
--
error compiling committee.c: too many arguments to function
On Wed, Jun 29, 2011 at 02:32:34PM +0200, Kevin Wolf wrote:
> Christoph, it looks like we're back to your WCE patches then. Do you
> still work on them?
The IDE patch is ready once the bdrv_reopen from the hostcache patches
goes in. Virtio still needs to be redesigned to use a command instead
of
On 06/29/2011 02:59 PM, Kevin Wolf wrote:
Hi,
I think we have touched this topic before during some IRC discussions or
somewhere deep in a mailing list thread, but I think it hasn't been
discussed on the list.
Our default cache mode of cache=writethrough is extremely conservative
and provides a
Am 29.06.2011 15:36, schrieb Johannes Stezenbach:
> On Linux x86_64 host with 32bit userspace, running
> qemu or even just "qemu-img create -f qcow2 some.img 1G"
> causes a kernel warning:
>
> ioctl32(qemu-img:5296): Unknown cmd fd(3) cmd(5326){t:'S';sz:0}
> arg(7fff) on some.img
> ioctl3
On 29.06.2011, at 15:11, Michael S. Tsirkin wrote:
> On Wed, Jun 29, 2011 at 03:02:46PM +0200, Alexander Graf wrote:
>>
>> On 28.06.2011, at 17:35, Michael S. Tsirkin wrote:
>>
>>> Support build on RHEL 5.X where we have syscall for eventfd but not
>>> userspace wrapper.
>>>
>>> (cherry-picked
On Wed, Jun 29, 2011 at 07:06:03AM -0500, Anthony Liguori wrote:
> But for the most part, we track bare metal fairly well in terms of block
> performance, no?
only if using cache=none and fmt=raw on either a blockdevice or a fully
preallocated (not fallocated) file on a modern filesystem.
Hi,
I'm trying to get the tablet emulation for Qemu's VNC server to handle
the mouse better. I'm using `qemu-system-arm` and everything is OK
except for the mouse movement.
After I add `-usb -usbdevie table` argument to `qemu-system-arm`
invocation I get:
qemu: hardware error: Failed to create U
On Wed, Jun 29, 2011 at 12:59 PM, Kevin Wolf wrote:
> I'm not entirely sure if I should suggest writeback or none as the new
> default, but I think it could make sense to change it.
I agree that cache=none is safe and fast with correct guests and local
disks. It is beaten by cache=writeback in c
DirectFB-1.0 uses at least two of the four added ioctls, and the two
others were added for completeness. This patch was validated with the
program "vlock -all/-new".
Signed-off-by: Cédric VINCENT
Cc: Riku Voipio
---
linux-user/ioctls.h|4
linux-user/syscall_defs.h |4
On 06/29/11 13:57, Alon Levy wrote:
---
hw/qxl.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/qxl.h b/hw/qxl.h
index 7df594e..bf875a0 100644
--- a/hw/qxl.h
+++ b/hw/qxl.h
@@ -89,7 +89,7 @@ typedef struct PCIQXLDevice {
#define PANIC_ON(x) if ((x)) {
Hi,
+case QXL_IO_FLUSH_SURFACES:
+dprint(d, 1, "QXL_IO_FLUSH_SURFACES (%d) entry (%s, s#=%d, res#=%d)\n",
+val, qxl_mode_to_string(d->mode), d->guest_surfaces.count,
+d->num_free_res);
+qemu_spice_stop(&d->ssd);
+qemu_spice_start(&d->ssd);
+
On 06/29/11 13:57, Alon Levy wrote:
---
pc-bios/bios.bin| Bin 131072 -> 26 bytes
pc-bios/vgabios-qxl.bin | Bin 40448 -> 41 bytes
2 files changed, 0 insertions(+), 0 deletions(-)
mode change 100644 => 12 pc-bios/bios.bin
mode change 100644 => 12 pc-bios/vgabios-qxl.
DirectFB-1.0 uses at least one of the four added ioctls, and the three
others were added for completeness. This patch was validated with the
program "setleds" and the following Makefile:
SETLEDS_INIT = setleds -v -num -caps -scroll
SETLEDS_TESTS = sh -c ' \
setleds -v +num +caps
On Wed, Jun 29, 2011 at 03:02:46PM +0200, Alexander Graf wrote:
>
> On 28.06.2011, at 17:35, Michael S. Tsirkin wrote:
>
> > Support build on RHEL 5.X where we have syscall for eventfd but not
> > userspace wrapper.
> >
> > (cherry-picked from commit 9e3269181e9bc56feb43bcd4e8ce0b82cd543e65
> >
On 28.06.2011, at 17:35, Michael S. Tsirkin wrote:
> Support build on RHEL 5.X where we have syscall for eventfd but not
> userspace wrapper.
>
> (cherry-picked from commit 9e3269181e9bc56feb43bcd4e8ce0b82cd543e65
> in qemu-kvm.git).
>
> Signed-off-by: Michael S. Tsirkin
> ---
> compat/sys/eve
Am 29.06.2011 14:23, schrieb Anthony Liguori:
> On 06/29/2011 07:16 AM, Kevin Wolf wrote:
>> Am 29.06.2011 14:06, schrieb Anthony Liguori:
>>> On 06/29/2011 06:59 AM, Kevin Wolf wrote:
Hi,
I think we have touched this topic before during some IRC discussions or
somewhere deep in
Hi,
+case QXL_IO_DESTROY_ALL_SURFACES_ASYNC:
+d->mode = QXL_MODE_UNDEFINED;
Should go to the async thread.
cheers,
Gerd
On 06/29/2011 08:00 AM, Avi Kivity wrote:
On 06/29/2011 02:59 PM, Kevin Wolf wrote:
Hi,
I think we have touched this topic before during some IRC discussions or
somewhere deep in a mailing list thread, but I think it hasn't been
discussed on the list.
Our default cache mode of cache=writethrou
On Wed, Jun 29, 2011 at 01:05:07PM +0200, Alexander Graf wrote:
>
> On 27.06.2011, at 14:21, Stefano Stabellini wrote:
>
> > On Sun, 26 Jun 2011, Michael S. Tsirkin wrote:
> >> move ids to pci info structure
> >>
> >> Signed-off-by: Michael S. Tsirkin
> >>
> >> Untested.
> >>
> >
> > tested
Am 29.06.2011 15:00, schrieb Avi Kivity:
> On 06/29/2011 02:59 PM, Kevin Wolf wrote:
>> Hi,
>>
>> I think we have touched this topic before during some IRC discussions or
>> somewhere deep in a mailing list thread, but I think it hasn't been
>> discussed on the list.
>>
>> Our default cache mode of
Hi,
-dprint(d, 1, "%s: unexpected port 0x%x in vga mode\n", __FUNCTION__,
io_port);
+dprint(d, 1, "%s: unexpected port 0x%x (%s) in vga mode\n",
+__FUNCTION__, io_port, io_port_to_string(io_port));
Is this worth it? Should be a quite rare event ...
cheers,
Ge
On 29 June 2011 05:02, Edgar E. Iglesias wrote:
> On Wed, Jun 08, 2011 at 12:32:40PM +1000, Matthew Fernandez wrote:
>> Add command line support for logging to a location other than /tmp/qemu.log.
>>
>> With logging enabled (command line option -d), the log is written to
>> the hard-coded path /tm
On Wed, Jun 29, 2011 at 01:05:37PM +0200, Alexander Graf wrote:
>
> On 27.06.2011, at 14:21, Stefano Stabellini wrote:
>
> > On Sun, 26 Jun 2011, Michael S. Tsirkin wrote:
> >> Sync xen names to ones used by linux. Add
> >> xen platform device id as well.
> >>
> >> Signed-off-by: Michael S. Tsir
Hi,
I agree, but there is a reason why I went with a usb_bus_register_companion
function instead of with a usb_bus_register_companion_port function, the
uhci controller needs to know how many companion controllers it has
(to report this in one of its registers). When we're registering
ports 1
---
hw/qxl.c | 64 +-
1 files changed, 63 insertions(+), 1 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 22455af..0ab8074 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -433,6 +433,67 @@ static const char *qxl_mode_to_string(int mode)
---
hw/qxl.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 8895b14..22455af 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1136,7 +1136,8 @@ static void ioport_write(void *opaque, uint32_t addr,
uint32_t val)
break;
case QXL_IO_LOG:
Am 29.06.2011 14:06, schrieb Anthony Liguori:
> On 06/29/2011 06:59 AM, Kevin Wolf wrote:
>> Hi,
>>
>> I think we have touched this topic before during some IRC discussions or
>> somewhere deep in a mailing list thread, but I think it hasn't been
>> discussed on the list.
>>
>> Our default cache mo
On 06/29/2011 07:16 AM, Kevin Wolf wrote:
Am 29.06.2011 14:06, schrieb Anthony Liguori:
On 06/29/2011 06:59 AM, Kevin Wolf wrote:
Hi,
I think we have touched this topic before during some IRC discussions or
somewhere deep in a mailing list thread, but I think it hasn't been
discussed on the li
---
hw/qxl.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/qxl.h b/hw/qxl.h
index 7df594e..bf875a0 100644
--- a/hw/qxl.h
+++ b/hw/qxl.h
@@ -89,7 +89,7 @@ typedef struct PCIQXLDevice {
#define PANIC_ON(x) if ((x)) { \
printf("%s: PANIC
On 06/29/2011 06:59 AM, Kevin Wolf wrote:
Hi,
I think we have touched this topic before during some IRC discussions or
somewhere deep in a mailing list thread, but I think it hasn't been
discussed on the list.
Our default cache mode of cache=writethrough is extremely conservative
and provides a
On 06/29/2011 06:59 AM, Kevin Wolf wrote:
Hi,
I think we have touched this topic before during some IRC discussions or
somewhere deep in a mailing list thread, but I think it hasn't been
discussed on the list.
Our default cache mode of cache=writethrough is extremely conservative
and provides a
1 - 100 of 158 matches
Mail list logo
