When testing the latest master branch, qemu dies with the above error
message. The issue seems to have been introduced by the following
recent patch:
xen: convert to MemoryListener API (20581d207853fe4b1af88b116f077516dfa888cd)
Commenting the assert() prevents qemu from dying, but there may be
an
On Mon, Nov 14, 2011 at 8:35 PM, Julian Pidancet
wrote:
> This patch makes iPXE work with the rtl8139 emulation. The rtl8139
> driver in iPXE issues a 16bit access on the ChipCmd register
> (offset 0x37) to check the status of the rx buffer. The offset of the
> ioport access was gett
.
This fixes an issue with iPXE reporting timeouts during TFTP transfers.
v2: Remove completely the 0xff masks as they're useless since the
calling functions already do the job.
Signed-off-by: Julian Pidancet
---
hw/rtl8139.c | 14 +-
1 files changed, 1 insertions(+), 13 dele
On Mon, Nov 14, 2011 at 2:38 PM, Stefan Hajnoczi wrote:
> On Sun, Nov 13, 2011 at 6:13 PM, Julian Pidancet
> wrote:
>> This patch makes iPXE work with the rtl8139 emulation. The rtl8139
>> driver in iPXE issues a 16bit access on the ChipCmd register
>> (offset 0x37) to ch
.
This fixes an issue with iPXE reporting timeouts during TFTP transfers.
Signed-off-by: Julian Pidancet
---
hw/rtl8139.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index 4c37993..0ff06da 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
On 06/15/2010 11:05 AM, Gerd Hoffmann wrote:
> Hi,
>
> This patch series features the linux fbdev display driver and a few
> more patches the fbdev driver depends on. Most of the patches have been
> on the list before. If you wondered what they are good for -- here is
> the big picture ;)
>
>
usage counter in the display allocator code,
so the fbdev driver can know whether or not the surface is read by other
drivers at the same time.
--
Julian Pidancet
On 06/17/2010 03:29 PM, Julian Pidancet wrote:
>
> Hi,
>
> Thanks for spotting these errors. Here is a respin of my patch to address you
> concerns.
> (The munmap call is included).
>
> Cheers,
>
> Julian
>
Oh, I actually tested the last patch only with the
On 06/17/2010 11:43 AM, Gerd Hoffmann wrote:
>Hi,
>
> You register the display allocator, but don't unregister in
> fbdev_display_uninit().
>
> You are just lucky that fbdev_cleanup() forgets to unmap the framebuffer.
>
> Apply the attached fix, start qemu with vnc, then do "change fbdev on
y_resize = fbdev_resize;
dcl->dpy_refresh = fbdev_refresh;
+dcl->dpy_setdata = fbdev_setdata;
register_displaychangelistener(ds, dcl);
+
+da = qemu_mallocz(sizeof (DisplayAllocator));
+da->create_displaysurface = fbdev_create_displaysurface;
+da->resize_displaysurface =
..
>
When loosing the focus, you can force display surface reallocation by calling
hw_invalidate(), this way you can give qemu a temporary pointer to prevent
drawing on the framebuffer.
When switching back, you just have to copy the content of the temporary pointer
location to the framebuffer.
Cheers,
Julian Pidancet
On 05/20/2010 09:20 PM, Gerd Hoffmann wrote:
> Display works with 32 bpp (both host + guest) only.
> Which surprisingly didn't cause much problems so far in my testing.
> Host runs with kms and inteldrmfb.
>
> Mouse support isn't available yet.
> I've cheated by passed through the hosts usb mouse
On 05/19/2010 02:52 PM, Stefano Stabellini wrote:
> On Wed, 19 May 2010, Gerd Hoffmann wrote:
>>Hi,
>>
>>> I think the only way to fix this is to handle VT acquire and release
>>> events ourselves.
>>
>> Hmm. I suspect sdl and directfb wanna do this too, so I'm not sure this
>> will actually
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 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
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
>
>
s not fullscreen. For this reason, you can never
assume that SDL will not perform extra copy operations on your behalf
without notifying you.
[1] http://www.libsdl.org/cgi/docwiki.cgi/SDL_SetVideoMode
Signed-off-by: Julian Pidancet
---
Makefile|4 +
Makefile.objs |1 +
conf
which is
not exactly what one wants from a performance or a complexity point of
view.
Signed-off-by: Julian Pidancet
---
Makefile|4 +
Makefile.objs |1 +
configure | 21 +++
console.h |3 +
directfb.c |
s not fullscreen. For this reason, you can never
assume that SDL will not perform extra copy operations on your behalf
without notifying you.
[1] http://www.libsdl.org/cgi/docwiki.cgi/SDL_SetVideoMode
Signed-off-by: Julian Pidancet
---
Makefile|4 +
Makefile.objs |1 +
conf
19 matches
Mail list logo
