On 05/16/2010 11:04 PM, Juan Quintela wrote:
So, to make the story short: I know what is happening, and I know how to
fix it, just that fix is not trivial. I just need time.
Meanwhile, we have a broken 0.12.4. Is there a quick'n'dirty
workaround that will be forward compatible with
Avi Kivity wrote:
> On 05/17/2010 03:12 AM, Anthony Liguori wrote:
>> On Sun, May 16, 2010 at 12:38 PM, Jamie Lokier
>> wrote:
>>
>>> Anthony Liguori wrote:
>>>
Instead of encoding just as a string, it would be a good idea to encode
it as something like:
{'__class__': '
On 05/17/2010 10:40 AM, Jan Kiszka wrote:
The alternative is to have a schema. Sun RPC/XDR doesn't carry any type
information (you can't even distinguish between a number and text) yet C
clients have to problem extracting typed information from it.
Having __class__ everywhere means we're carr
Avi Kivity wrote:
> On 05/17/2010 10:40 AM, Jan Kiszka wrote:
>>> The alternative is to have a schema. Sun RPC/XDR doesn't carry any type
>>> information (you can't even distinguish between a number and text) yet C
>>> clients have to problem extracting typed information from it.
>>>
>>> Having __
On 05/17/2010 10:57 AM, Jan Kiszka wrote:
Avi Kivity wrote:
On 05/17/2010 10:40 AM, Jan Kiszka wrote:
The alternative is to have a schema. Sun RPC/XDR doesn't carry any type
information (you can't even distinguish between a number and text) yet C
clients have to problem extracting ty
On 05/17/2010 11:10 AM, Avi Kivity wrote:
Another way of looking at it: if the client sees { __class__: foo, f1:
10, f2: 9 }, it cannot derive any information from __class__ unless it
was aware of foo beforehand. If that's the case, let's make it part
of the schema so it is available at comp
17.05.2010 11:00, Avi Kivity wrote:
On 05/16/2010 11:04 PM, Juan Quintela wrote:
[]
We've regressed from failing some migrations to failing all migrations.
Humm, 0.12.4 -> 0.12.4 should work. My advise is just revert the patch
and live with it for another week, what do you think?
A week is f
Avi Kivity writes:
> On 05/14/2010 08:03 PM, Markus Armbruster wrote:
>> Avi Kivity writes:
>>
>>
>>> On 05/14/2010 11:50 AM, Markus Armbruster wrote:
[...]
We have a list of buses, each containing a list of device functions.
Not sure the additional level of nesting you propose buy
Avi Kivity writes:
> On 05/15/2010 01:54 AM, Luiz Capitulino wrote:
>> On Fri, 14 May 2010 19:03:36 +0200
>> Markus Armbruster wrote:
>>
>>
What about PCI domains?
>>> Good point. Better to provide for them neatly now, instead of kludging
>>> them in later.
>>>
>>
Would you mind sending patch series with proper References: headers, so
that the parts of the series are properly threaded?
You can ask either git-format-patch or git-send-email to add them.
We need to close the file even in error case. While at it, make the callers
catch all kind of errors. ENOENT is allowed for default config files, they
are optional.
Reported-by: Luiz Capitulino
Signed-off-by: Kevin Wolf
---
qemu-config.c | 12
vl.c |4 ++--
2 files c
Blue Swirl writes:
> On 5/16/10, Stefan Weil wrote:
>> Am 15.05.2010 22:49, schrieb Blue Swirl:
>>
>>
>> > Hi,
>> >
>> > With this mingw32 compiler:
>> >
>> > $ i586-mingw32msvc-gcc -v
>> > Using built-in specs.
>> > Target: i586-mingw32msvc
>> > Configured with:
[...]
>> > build will not succee
Avi Kivity wrote:
> On 05/17/2010 10:57 AM, Jan Kiszka wrote:
>> Avi Kivity wrote:
>>
>>> On 05/17/2010 10:40 AM, Jan Kiszka wrote:
>>>
> The alternative is to have a schema. Sun RPC/XDR doesn't carry any type
> information (you can't even distinguish between a number and text) y
Miguel Di Ciurcio Filho wrote:
> On Fri, May 14, 2010 at 2:03 PM, Jan Kiszka wrote:
>>> In both cases the info_str string is written inside
>>> net_socket_fd_init_(stream|dgram), and after that, it is
>>> overwritten on a subsequent snprintf() in net_socket_accept().
>>>
>> There is non-zero time
On 05/17/2010 11:55 AM, Jan Kiszka wrote:
The names of fields are also type information.
Not in the case of device_show. The clients have no idea of the vmstate
structures before they were transfered. Granted, that will likely remain
a special case in the QMP command set.
For that
On 05/17/2010 11:27 AM, Markus Armbruster wrote:
A slot is the hotpluggable entity. Open your computer and you can
actually see them.
QEMU doesn't really know that.
How can that be? Do we signal hotplug notifications to a function or
to a slot?
Can we hotplug a sing
Am 16.05.2010 13:59, schrieb Avi Kivity:
> Not all block format drivers expose an io_flush method (reasonable for
> read-only protocols), so calling io_flush there will immediately segfault.
>
> Fix by checking for the method's existence before calling it.
>
> Signed-off-by: Avi Kivity
Thanks,
Michael Tokarev wrote:
> 17.05.2010 11:00, Avi Kivity wrote:
>> On 05/16/2010 11:04 PM, Juan Quintela wrote:
> []
We've regressed from failing some migrations to failing all migrations.
>>> Humm, 0.12.4 -> 0.12.4 should work. My advise is just revert the patch
>>> and live with it for another
17.05.2010 13:07, Juan Quintela wrote:
Michael Tokarev wrote:
[]
http://www.mail-archive.com/k...@vger.kernel.org/msg34051.html
I wonder why it is not noticed before -- it's broken since 0.12...
People has become rich and everybody has a 64 bit hardware :-)
Actually I don't think there's a
Avi Kivity wrote:
> On 05/17/2010 11:55 AM, Jan Kiszka wrote:
>>> The names of fields are also type information.
>>>
>> Not in the case of device_show. The clients have no idea of the vmstate
>> structures before they were transfered. Granted, that will likely remain
>> a special case in the
On 05/17/2010 12:17 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 05/17/2010 11:55 AM, Jan Kiszka wrote:
The names of fields are also type information.
Not in the case of device_show. The clients have no idea of the vmstate
structures before they were transfered. Granted, tha
On 17.05.2010, at 11:11, Michael Tokarev wrote:
> 17.05.2010 13:07, Juan Quintela wrote:
>> Michael Tokarev wrote:
> []
>>> http://www.mail-archive.com/k...@vger.kernel.org/msg34051.html
>>> I wonder why it is not noticed before -- it's broken since 0.12...
>>
>> People has become rich and ever
When snapshot handlers are not defined in the format driver, it is
better to call the ones of the protocol driver. This enables us to
implement snapshot support in the protocol driver.
We need to call bdrv_close() and bdrv_open() handlers of the format
driver before and after bdrv_snapshot_goto()
This patch calls the close handler of the block driver before the qemu
process exits.
This is necessary because the sheepdog block driver releases the lock
of VM images in the close handler.
Signed-off-by: MORITA Kazutaka
---
block.c |9 +
block.h |1 +
vl.c|1 +
3 files
Hi all,
This patch adds a block driver for Sheepdog distributed storage
system.
Changes from v2 to v3 are:
- add drv->bdrv_close() and drv->bdrv_open() before and after
bdrv_snapshot_goto() call of the protocol.
- address the review comments on the sheepdog driver code.
I'll send the det
Sheepdog is a distributed storage system for QEMU. It provides highly
available block level storage volumes to VMs like Amazon EBS. This
patch adds a qemu block driver for Sheepdog.
Sheepdog features are:
- No node in the cluster is special (no metadata node, no control
node, etc)
- Linear scal
Usually the guest can tell the host to flush data to disk. In some cases we
don't want to flush though, but try to keep everything in cache.
So let's add a new cache value to -drive that allows us to set the cache
policy to most aggressive, disabling flushes. We call this mode "volatile",
as guest
Hi,
Thank you very much for the reviewing!
At Fri, 14 May 2010 13:08:06 +0200,
Kevin Wolf wrote:
> > +
> > +struct sd_req {
> > + uint8_t proto_ver;
> > + uint8_t opcode;
> > + uint16_tflags;
> > + uint32_tepoch;
> > + uint32_tid;
> > + uint32_
Juan Quintela wrote:
> Jan Kiszka wrote:
>> Juan Quintela wrote:
>>> Lack of "proper" subsections. IDE is something like:
>>>
>>> const VMStateDescription vmstate_ide_drive = {
>>> .version_id = 4,
>>>
>>> }
>>>
>>> static const VMStateDescription vmstate_bmdma = {
>>> .name = "ide b
Am 17.05.2010 12:14, schrieb Alexander Graf:
> Usually the guest can tell the host to flush data to disk. In some cases we
> don't want to flush though, but try to keep everything in cache.
>
> So let's add a new cache value to -drive that allows us to set the cache
> policy to most aggressive, di
+directfb="no"
Should be ="" (aka autodetect).
+if test "$directfb" = "yes" ; then
+ directfb_libs=`directfb-config --libs`
+ directfb_cflags=`directfb-config --cflags`
+ libs_softmmu="$directfb_libs $libs_softmmu"
+fi
use pkgconfig here. directfb-config most likely is just a pkgconfig
Hi,
Can you provide some performance data to justify this since SDL provides
the same ability?
IMHO no performance data is needed to justify this because SDL running
on top of the linux framebuffer is simply unusable IMHO.
cheers,
Gerd
Am 17.05.2010 12:19, schrieb MORITA Kazutaka:
> When snapshot handlers are not defined in the format driver, it is
> better to call the ones of the protocol driver. This enables us to
> implement snapshot support in the protocol driver.
>
> We need to call bdrv_close() and bdrv_open() handlers of
Avi Kivity writes:
> On 05/17/2010 11:27 AM, Markus Armbruster wrote:
>>
>>
> A slot is the hotpluggable entity. Open your computer and you can
> actually see them.
>
>
QEMU doesn't really know that.
>>> How can that be? Do we signal hotplug
Blue Swirl writes:
> Thanks, applied all.
Thanks indeed! 13 versions and I-don't-remember-how-many months, must
have taxed your patience.
> > > In 2/2, A20 logic changes a bit but I doubt any guest would be broken
> > > if A20 line written through I/O port 92 couldn't be read via i8042.
> > > The reverse (write using i8042 and read port 92) will work.
> > >
> >
> > Why take the risk?
>
> The alternative is to route a signal from po
On Fri, May 14, 2010 at 05:58:50PM +0100, Julian Pidancet wrote:
> This patch implements a DirectFB driver for QEMU. It allows Qemu to
> draw a VM graphic output directly in the framebuffer of the host,
> without having to rely on X11.
> DirectFB also provides with a generic interface take advantag
At Mon, 17 May 2010 13:08:08 +0200,
Kevin Wolf wrote:
>
> Am 17.05.2010 12:19, schrieb MORITA Kazutaka:
> >
> > int bdrv_snapshot_goto(BlockDriverState *bs,
> > const char *snapshot_id)
> > {
> > BlockDriver *drv = bs->drv;
> > +int ret, open_ret;
> > +
> >
On 05/17/2010 11:53 AM, Gerd Hoffmann wrote:
>> +directfb="no"
>
> Should be ="" (aka autodetect).
>
>> +if test "$directfb" = "yes" ; then
>> + directfb_libs=`directfb-config --libs`
>> + directfb_cflags=`directfb-config --cflags`
>> + libs_softmmu="$directfb_libs $libs_softmmu"
>> +fi
>
>
On 05/17/2010 12:44 PM, Christoph Hellwig wrote:
> On Fri, May 14, 2010 at 05:58:50PM +0100, Julian Pidancet wrote:
>> This patch implements a DirectFB driver for QEMU. It allows Qemu to
>> draw a VM graphic output directly in the framebuffer of the host,
>> without having to rely on X11.
>> Direct
Am 17.05.2010 14:19, schrieb MORITA Kazutaka:
> At Mon, 17 May 2010 13:08:08 +0200,
> Kevin Wolf wrote:
>>
>> Am 17.05.2010 12:19, schrieb MORITA Kazutaka:
>>>
>>> int bdrv_snapshot_goto(BlockDriverState *bs,
>>> const char *snapshot_id)
>>> {
>>> BlockDriver *drv =
Hello,
shouldn't it be in that way?
Dmitry
--- qemu-0.12.4/target-mips/translate.c 2010-05-17 16:12:58.048661610 +0400
+++ qemu-0.12.4/target-mips/translate.c 2010-05-17 16:13:12.281656754 +0400
@@ -2761,7 +2761,7 @@
case OPC_DINSU:
if (lsb > msb)
goto fail;
-
On Mon, May 17, 2010 at 01:14:05PM +0100, Julian Pidancet wrote:
> I have not heard about that, sorry.
> My test configuration has an i915-like Intel graphic card, and a nearly
> standard 2.6.32 linux kernel. No specific patching was required.
You're right. I've checked it and the horrible kerne
On Tue, May 11, 2010 at 11:11:12PM +0100, Paul Brook wrote:
> .. though it may be a kernel bug rather that a qemu bug, depending on the
> exact details. Either way, I consider any mode that inhibits host filesystem
> write cache but not volatile drive cache to be pretty worthless. Either we
>
On Fri, May 14, 2010 at 11:16:47AM +0200, Markus Armbruster wrote:
> If you change -drive, please keep the coming separation in mind, and
> avoid parameters that mix up guest and host.
This new option seems to be exactly that, unfortunately..
On 17.05.2010, at 14:41, Christoph Hellwig wrote:
> On Fri, May 14, 2010 at 11:16:47AM +0200, Markus Armbruster wrote:
>> If you change -drive, please keep the coming separation in mind, and
>> avoid parameters that mix up guest and host.
>
> This new option seems to be exactly that, unfortunate
On 05/17/2010 05:14 AM, Alexander Graf wrote:
Usually the guest can tell the host to flush data to disk. In some cases we
don't want to flush though, but try to keep everything in cache.
So let's add a new cache value to -drive that allows us to set the cache
policy to most aggressive, disabling
On 17.05.2010, at 14:58, Anthony Liguori wrote:
> On 05/17/2010 05:14 AM, Alexander Graf wrote:
>> Usually the guest can tell the host to flush data to disk. In some cases we
>> don't want to flush though, but try to keep everything in cache.
>>
>> So let's add a new cache value to -drive that a
On Mon, May 17, 2010 at 9:20 PM, Kevin Wolf wrote:
> Am 17.05.2010 14:19, schrieb MORITA Kazutaka:
>> At Mon, 17 May 2010 13:08:08 +0200,
>> Kevin Wolf wrote:
>>>
>>> Am 17.05.2010 12:19, schrieb MORITA Kazutaka:
int bdrv_snapshot_goto(BlockDriverState *bs,
On 05/17/2010 02:45 AM, Avi Kivity wrote:
On 05/17/2010 10:40 AM, Jan Kiszka wrote:
The alternative is to have a schema. Sun RPC/XDR doesn't carry any
type
information (you can't even distinguish between a number and text)
yet C
clients have to problem extracting typed information from it.
On 05/17/2010 08:02 AM, Alexander Graf wrote:
My concern is that ext3 exaggerates the cost of fsync() which will result in
diminishing value over time for this feature as people move to ext4/btrfs.
There will be ext3 file systems for years out. Just because people can use
better and fast
On 17.05.2010, at 15:09, Anthony Liguori wrote:
> On 05/17/2010 08:02 AM, Alexander Graf wrote:
>>> My concern is that ext3 exaggerates the cost of fsync() which will result
>>> in diminishing value over time for this feature as people move to
>>> ext4/btrfs.
>>>
>> There will be ext3 file
On Sat, 15 May 2010 10:42:44 +0200
Jan Kiszka wrote:
> Luiz Capitulino wrote:
> > On Fri, 14 May 2010 19:08:07 +0200
> > Jan Kiszka wrote:
> >
> >> Avi Kivity wrote:
> >>> On 05/14/2010 08:01 PM, Avi Kivity wrote:
> On 05/14/2010 07:52 PM, Jan Kiszka wrote:
> >> In order not to comprom
On 05/17/2010 08:17 AM, Alexander Graf wrote:
On 17.05.2010, at 15:09, Anthony Liguori wrote:
On 05/17/2010 08:02 AM, Alexander Graf wrote:
My concern is that ext3 exaggerates the cost of fsync() which will result in
diminishing value over time for this feature as people move to ext
On 05/15/2010 08:10 PM, Paul Brook wrote:
The other solution would be to use the DirectFB driver for SDL which
would allow to do slightly the same as this patch. But that would mean
having to deal with an additional layer in the graphical stack, which is
not exactly what one wants from a performa
Anthony Liguori wrote:
> On 05/17/2010 08:17 AM, Alexander Graf wrote:
>> On 17.05.2010, at 15:09, Anthony Liguori wrote:
>>
>>
>>> On 05/17/2010 08:02 AM, Alexander Graf wrote:
>>>
> My concern is that ext3 exaggerates the cost of fsync() which will
> result in diminishing value ov
Alexander Graf wrote:
> Anthony Liguori wrote:
>
>> On 05/17/2010 08:17 AM, Alexander Graf wrote:
>>
>>> On 17.05.2010, at 15:09, Anthony Liguori wrote:
>>>
>>>
>>>
On 05/17/2010 08:02 AM, Alexander Graf wrote:
>> My concern is that ext3 exaggerate
On 05/17/2010 02:30 PM, Anthony Liguori wrote:
> On 05/15/2010 08:10 PM, Paul Brook wrote:
>>> The other solution would be to use the DirectFB driver for SDL which
>>> would allow to do slightly the same as this patch. But that would mean
>>> having to deal with an additional layer in the graphical
On 05/17/2010 05:14 AM, Alexander Graf wrote:
Usually the guest can tell the host to flush data to disk. In some cases we
don't want to flush though, but try to keep everything in cache.
So let's add a new cache value to -drive that allows us to set the cache
policy to most aggressive, disabling
Hi,
i have a VM where I just did a dist-upgrade in Ubuntu and the VM entered
paused state without any obvious reason.
Is there a way to debug why this happened? I have not touched the VM by
now to leave the opportunity to debug.
Peter
On 05/17/2010 09:04 AM, Alexander Graf wrote:
Anthony Liguori wrote:
On 05/17/2010 08:17 AM, Alexander Graf wrote:
On 17.05.2010, at 15:09, Anthony Liguori wrote:
On 05/17/2010 08:02 AM, Alexander Graf wrote:
My concern is that ext3 exaggerates the cost of fsync
On 5/17/10, Markus Armbruster wrote:
> Blue Swirl writes:
>
> > On 5/16/10, Stefan Weil wrote:
> >> Am 15.05.2010 22:49, schrieb Blue Swirl:
> >>
> >>
> >> > Hi,
> >> >
> >> > With this mingw32 compiler:
> >> >
> >> > $ i586-mingw32msvc-gcc -v
> >> > Using built-in specs.
> >> > Targe
> > I don't see a difference between the results. Apparently the barrier
> > option doesn't change a thing.
>
> Ok. I don't like it, but I can see how it's compelling. I'd like to
> see the documentation improved though. I also think a warning printed
> on stdio about the safety of the option w
On 05/17/2010 11:23 AM, Paul Brook wrote:
I don't see a difference between the results. Apparently the barrier
option doesn't change a thing.
Ok. I don't like it, but I can see how it's compelling. I'd like to
see the documentation improved though. I also think a warning printed
on st
On 05/17/2010 10:16 AM, Peter Lieven wrote:
Hi,
i have a VM where I just did a dist-upgrade in Ubuntu and the VM entered
paused state without any obvious reason.
Is there a way to debug why this happened? I have not touched the VM by
now to leave the opportunity to debug.
You have run out
On 17.05.2010, at 18:26, Anthony Liguori wrote:
> On 05/17/2010 11:23 AM, Paul Brook wrote:
I don't see a difference between the results. Apparently the barrier
option doesn't change a thing.
>>> Ok. I don't like it, but I can see how it's compelling. I'd like to
>>> see t
On 05/17/2010 10:09 AM, Julian Pidancet wrote:
On 05/17/2010 02:30 PM, Anthony Liguori wrote:
On 05/15/2010 08:10 PM, Paul Brook wrote:
The other solution would be to use the DirectFB driver for SDL which
would allow to do slightly the same as this patch. But that would mean
having to
On 5/17/10, Paolo Bonzini wrote:
> > > > In 2/2, A20 logic changes a bit but I doubt any guest would be broken
> > > > if A20 line written through I/O port 92 couldn't be read via i8042.
> > > > The reverse (write using i8042 and read port 92) will work.
> > > >
> > >
> > > Why take the risk
Blue Swirl writes:
> On 5/17/10, Markus Armbruster wrote:
>> Blue Swirl writes:
>>
>> > On 5/16/10, Stefan Weil wrote:
>> >> Am 15.05.2010 22:49, schrieb Blue Swirl:
>> >>
>> >>
>> >> > Hi,
>> >> >
>> >> > With this mingw32 compiler:
>> >> >
>> >> > $ i586-mingw32msvc-gcc -v
>> >> >
Blue Swirl writes:
> Signed-off-by: Blue Swirl
> ---
> audio/audio_template.h |2 +-
> block/curl.c|9 ---
> block/parallels.c |7 -
> block/qcow2.c |8 --
> darwin-user/commpage.c |2 +-
> darwin-user/syscall.c |2 +-
> hw/vga
This version should not change the i8042 vs. port 92 logic.
Blue Swirl (2):
Compile pckbd only once
pckbd: improve debugging
Makefile.objs|1 +
Makefile.target |8 +-
default-configs/i386-softmmu.mak |1 +
default-configs/mips-soft
Use a qemu_irq to indicate A20 line changes. Move I/O port 92
to pckbd.c.
Signed-off-by: Blue Swirl
---
Makefile.objs|1 +
Makefile.target |8 ++--
default-configs/i386-softmmu.mak |1 +
default-configs/mips-softmmu.mak |1 +
d
On 05/12/2010 05:37 PM, Michael S. Tsirkin wrote:
The following changes since commit 54d7cf136f040713095cbc064f62d753bff6f9d2:
doc: Clean up monitor command function index (2010-05-10 11:36:04 -0500)
Pulled. Thanks.
Regards,
Anthony Liguori
are available in the git repository at:
On 05/17/2010 06:19 AM, Markus Armbruster wrote:
Avi Kivity writes:
On 05/17/2010 11:27 AM, Markus Armbruster wrote:
A slot is the hotpluggable entity. Open your computer and you can
actually see them.
QEMU doesn't really know that.
How can
On 05/15/2010 01:19 AM, Avi Kivity wrote:
On 05/15/2010 01:54 AM, Luiz Capitulino wrote:
On Fri, 14 May 2010 19:03:36 +0200
Markus Armbruster wrote:
What about PCI domains?
Good point. Better to provide for them neatly now, instead of kludging
them in later.
When I did this conversion I a
On 05/12/2010 04:24 PM, Marcelo Tosatti wrote:
The following changes since commit 54d7cf136f040713095cbc064f62d753bff6f9d2:
Markus Armbruster (1):
doc: Clean up monitor command function index
Pulled. Thanks.
Regards,
Anthony Liguori
are available in the git repository at:
On 05/17/2010 09:10 PM, Anthony Liguori wrote:
The protocol must be forward looking, or we will need endless fixes
for it.
But we can always add a domain property to extend the address (with a
default domain of 0).
That's what I meant by endless fixes. Each one is reasonable by itself,
On 05/14/2010 12:10 PM, Kevin Wolf wrote:
The following changes since commit 14ac15d3ac8e0ef1c91204e2ac772b6412a6b99e:
Anthony Liguori (1):
Update SeaBIOS
are available in the git repository at:
git://repo.or.cz/qemu/kevin.git block
Pulled, thanks.
Regards,
Anthony Liguor
Ping?
On 04/28/2010 11:24 AM, Richard Henderson wrote:
> Changes v1->v2:
> * Dropped controversial bswap changes; bswap16 continues to use rolw.
> * Tidy data16 as the last of the hard-coded constants.
>
>
> r~
>
>
> Richard Henderson (22):
> tcg-i386: Allocate call-saved registers first
Ping? This options really doesn't work atm...
r~
On 05/03/2010 03:54 PM, Richard Henderson wrote:
> We forgot to propagate -fpie to the libdis-user directory.
>
> Signed-off-by: Richard Henderson
> ---
> configure |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git
Ping?
Update: The TYPE parameter to tcg_out_mov would be helpful
for the S390 port as well. The 32-bit LR is 2 bytes, while
the 64-bit LGR is 4 bytes.
r~
On 05/03/2010 04:30 PM, Richard Henderson wrote:
> The first patch allows the x86-64 port to avoid the REX.W prefix
> on moves, by allowing
Signed-off-by: Blue Swirl
---
hw/pckbd.c | 28 +++-
1 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/hw/pckbd.c b/hw/pckbd.c
index 5d268b4..3812284 100644
--- a/hw/pckbd.c
+++ b/hw/pckbd.c
@@ -29,6 +29,12 @@
/* debug PC keyboard */
//#define DEBUG_KBD
Hi,
IMO, that's a serious bug. A slot is a user visible entity, both in
that devices can only be hotplugged only as slots, not functions, and
to determine the maximum number of devices you can add. If the user
knows about it, qemu should too.
We can easily represent a slot/device as a qbus wi
On 05/17/10 14:04, Julian Pidancet wrote:
On 05/17/2010 11:53 AM, Gerd Hoffmann wrote:
+directfb="no"
Should be ="" (aka autodetect).
+if test "$directfb" = "yes" ; then
+ directfb_libs=`directfb-config --libs`
+ directfb_cflags=`directfb-config --cflags`
+ libs_softmmu="$directfb_lib
Pong.
Sorry -ENOTIME for QEMU
On Mon, May 17, 2010 at 11:26:37AM -0700, Richard Henderson wrote:
> Ping?
>
> On 04/28/2010 11:24 AM, Richard Henderson wrote:
> > Changes v1->v2:
> > * Dropped controversial bswap changes; bswap16 continues to use rolw.
> > * Tidy data16 as the last of the har
Blue Swirl wrote:
> On 5/16/10, Jamie Lokier wrote:
> > Blue Swirl wrote:
> > > On 5/16/10, Paolo Bonzini wrote:
> > > > On 05/15/2010 11:49 AM, Blue Swirl wrote:
> > > >
> > > > > In 2/2, A20 logic changes a bit but I doubt any guest would be broken
> > > > > if A20 line written through I/O
Alexander Graf wrote:
>
> On 17.05.2010, at 18:26, Anthony Liguori wrote:
>
> > On 05/17/2010 11:23 AM, Paul Brook wrote:
> I don't see a difference between the results. Apparently the barrier
> option doesn't change a thing.
>
> >>> Ok. I don't like it, but I can see how i
On 05/16/10 03:10, Paul Brook wrote:
The other solution would be to use the DirectFB driver for SDL which
would allow to do slightly the same as this patch. But that would mean
having to deal with an additional layer in the graphical stack, which is
not exactly what one wants from a performance o
Jan Kiszka wrote:
> Jamie Lokier wrote:
> > Anthony Liguori wrote:
> >> Instead of encoding just as a string, it would be a good idea to encode
> >> it as something like:
> >>
> >> {'__class__': 'base64', 'data': ...}
> >
> > Is there a benefit to the class indirection, over simply a keyword?:
>
On 05/17/2010 03:20 PM, Gerd Hoffmann wrote:
On 05/16/10 03:10, Paul Brook wrote:
The other solution would be to use the DirectFB driver for SDL which
would allow to do slightly the same as this patch. But that would mean
having to deal with an additional layer in the graphical stack,
which is
On Fri, 2010-05-14 at 02:42 -0700, Nicholas A. Bellinger wrote:
> On Fri, 2010-05-14 at 09:22 +0200, Hannes Reinecke wrote:
> > Nicholas A. Bellinger wrote:
> > > Greetings Hannes and co,
> > >
>
> > Let's see if I can find some time working on the megasas emulation.
> > Maybe I find something.
>
On Mon, 17 May 2010, Anthony Liguori wrote:
> On 05/17/2010 03:20 PM, Gerd Hoffmann wrote:
> > On 05/16/10 03:10, Paul Brook wrote:
> > > > The other solution would be to use the DirectFB driver for SDL which
> > > > would allow to do slightly the same as this patch. But that would mean
> > > > ha
On 05/17/2010 04:35 PM, malc wrote:
There's one thing that SDL does marvelously well - it's just one fairly
small and self contained library that doesn't unleash dependency hell on
the user.
The fact that we have cocoa support in the tree is basically an admission of
failure with SDL.
On Mon, 17 May 2010, Anthony Liguori wrote:
> On 05/17/2010 04:35 PM, malc wrote:
> > There's one thing that SDL does marvelously well - it's just one fairly
> > small and self contained library that doesn't unleash dependency hell on
> > the user.
> >
> > > The fact that we have cocoa support
On 17.05.2010, at 23:45, malc wrote:
> On Mon, 17 May 2010, Anthony Liguori wrote:
>
>> On 05/17/2010 04:35 PM, malc wrote:
>>> There's one thing that SDL does marvelously well - it's just one fairly
>>> small and self contained library that doesn't unleash dependency hell on
>>> the user.
>>>
On Tue, 18 May 2010, Alexander Graf wrote:
>
> On 17.05.2010, at 23:45, malc wrote:
>
> > On Mon, 17 May 2010, Anthony Liguori wrote:
> >
> >> On 05/17/2010 04:35 PM, malc wrote:
> >>> There's one thing that SDL does marvelously well - it's just one fairly
> >>> small and self contained library
On 05/17/2010 05:26 PM, Alexander Graf wrote:
I'm trying to think of a project where the clean separation between multiple
video outputs implemented in the backend and a separate frontend worked out. So
far the only case that has a strikingly similar architecture coming to my mind
is mplayer.
On 05/17/2010 05:42 PM, malc wrote:
In fact, couldn't we rather keep all graphic output out of qemu and
just expose VNC, possibly with self-made additions to the protocol
to speed up local rendering (thinking an SHM extension here)? Then
we could still offer a separate SDL based viewer that could
On 18.05.2010, at 00:46, Anthony Liguori wrote:
> On 05/17/2010 05:26 PM, Alexander Graf wrote:
>> I'm trying to think of a project where the clean separation between multiple
>> video outputs implemented in the backend and a separate frontend worked out.
>> So far the only case that has a stri
On 05/17/2010 05:49 PM, Alexander Graf wrote:
Then we could still offer a separate SDL based viewer that could do the same
things it does now. But we'd also open up the gate for a whole new integration
level with possible GUIs.
You could, but I think it introduces more complexity wh
1 - 100 of 105 matches
Mail list logo
