Thank you for this patch.
I found a few places where you have 32-bit integer overflows that result
in failure. They are marked inline below.
On 03/04/2015 09:18 AM, Xiaodong Gong wrote:
diff --git a/block/vpc.c b/block/vpc.c
index 46803b1..d9a8d19 100644
--- a/block/vpc.c
+++ b/block/vpc.c
@@
I assume Windows 7 or newer?
In order to speed boot time, Windows will remove the AHCI driver from
the critical driver database when you boot with no AHCI controller on
the bus. If you later want to switch to AHCI mode, you have to boot with
IDE again, and re-add the AHCI driver, reboot, and t
Can you post your options to configure? The tip seems to be working here...
On 04/01/2014 11:01 AM, Fabio Fantoni wrote:
Today I tried latest qemu 2.0 compiled from git (commit
63678e17cf399ff81b93417fe7bee8d6ef6b6b1b) on this dom0:
Debian 7 (Wheezy) 64 bit with kernel from package
linux-image-
From: "John V. Baboval"
Hook for adding another QemuConsole to the active display adapter.
Signed-off-by: John V. Baboval
---
include/ui/console.h |2 ++
ui/console.c |8
2 files changed, 10 insertions(+)
diff --git a/include/ui/console.h b/include/ui/console.h
index
From: "John V. Baboval"
Add a hook in GraphicHwOps for the ui to inform the hw of display orientation
changes
Signed-off-by: John V. Baboval
---
include/ui/console.h |2 ++
ui/console.c | 10 ++
2 files changed, 12 insertions(+)
diff --git a/include/ui/console.h b/incl
From: "John V. Baboval"
To be called by graphics adapter to have the ui re-initialize monitor state.
Signed-off-by: John V. Baboval
---
include/ui/console.h |3 +++
ui/console.c |8
2 files changed, 11 insertions(+)
diff --git a/include/ui/console.h b/include/ui/conso
From: "John V. Baboval"
Add a hook in GraphicHwOps to pass monitor EDID for a QemuConsole
from the ui to the hw.
Signed-off-by: John V. Baboval
---
include/ui/console.h |2 ++
ui/console.c | 10 ++
2 files changed, 12 insertions(+)
diff --git a/include/ui/console.h b/in
From: "John V. Baboval"
Hook to notify a display adapter of interesting UI changes such as
monitor hotplug, orientation changes, etc...
Signed-off-by: John V. Baboval
---
include/ui/console.h |9 +
ui/console.c |7 +++
2 files changed, 16 insertions(+)
diff --git
From: "John V. Baboval"
This is mostly just RFC at this point, since I'm not quite ready to submit the
associated multi-head video adapter, drivers and UI that consume this stuff.
(I still have to remove some Xen/XenClient specific stuff from it).
These are the infrastructure hooks I needed to a
From: "John V. Baboval"
The pointer is a place for the UI to hang a structure off of. In the multi-head
case, the UI can use this pointer to distinguish which QemuConsole a dpy_* call
was made for.
Signed-off-by: John V. Baboval
---
include/ui/console.h |1 +
1 file changed, 1 insertion(+
From: "John V. Baboval"
This is an optimization to allow the UI to show/hide the current cursor without
setting it to a new bitmap.
In-guest screen sharing applications which show/hide the cursor when capturing
the screen every frame (GoToMeeting, WebEx, etc.) cause high QEMU CPU usage if
cursor
Perhaps this should just return the mask instead of a boolean? It would
be nice at some point to handle a USB HID style device that can send
both relative and absolute events, for example.
Though perhaps that would be better as future work, since this is a nice
drop-in replacement for the old
I'm not sure this is correct. Generally when the display gets rotated,
the input device coordinates do not, and the in-guest code handles the math.
On 11/28/2013 09:30 AM, Gerd Hoffmann wrote:
Transform absolute mouse events according to graphic_rotate.
Legacy input code does it for both absol
On 11/26/2013 11:29 PM, Dave Airlie wrote:
On Fri, Nov 22, 2013 at 6:41 PM, Gerd Hoffmann wrote:
Hi,
While thinking about this: A completely different approach to tackle
this would be to implement touchscreen emulation. So we don't have a
single usb-tablet, but multiple (one per display)
On 11/20/2013 10:14 AM, Gerd Hoffmann wrote:
On Mi, 2013-11-20 at 09:32 -0500, John Baboval wrote:
On 11/20/2013 03:12 AM, Gerd Hoffmann wrote:
Hi,
I think you are only considering output here, for input we definitely
need some idea of screen layout, and this needs to be stored
somewhere
On 11/20/2013 03:12 AM, Gerd Hoffmann wrote:
Hi,
I think you are only considering output here, for input we definitely
need some idea of screen layout, and this needs to be stored
somewhere.
Oh yea, input. That needs quite some work for multihead / multiseat.
I think we should *not* try t
On Nov 19, 2013, at 9:59 PM, Dave Airlie wrote:
> On Tue, Nov 19, 2013 at 6:11 PM, Gerd Hoffmann wrote:
>> Hi,
>>
>>> So I felt I had a choice here for sharing a single output surface
>>> amongst outputs:
>>>
>>> a) have multiple QemuConsole reference multiple DisplaySurface wihch
>>> refer
On 11/19/2013 1:57 AM, Gerd Hoffmann wrote:
Hi,
I think it would be better if the HwOps calls all took a QemuConsole
instead of the opaque structure. The hw implementations can dig their
opaque structure out from there.
QemuConsole is private to ui/console.c though (and I prefer to keep it
's the price of
progress I suppose.) I'd love you're opinion on the matter before I
spend the time making the changes though...
On 11/7/2013 10:54 AM, John Baboval wrote:
On 11/7/2013 8:46 AM, Gerd Hoffmann wrote:
Hi,
As far as the EDID is concerned, there can only be one
On 11/06/2013 06:44 PM, Dave Airlie wrote:
On Wed, Nov 6, 2013 at 8:57 PM, Gerd Hoffmann wrote:
Hi,
It currently just adds multiple DisplaySurfaces to the QemuConsole,
now Gerd said he thought I should be using multiple QemuConsoles but I
really didn't think this was a good idea,
Why?
It
On 11/7/2013 8:46 AM, Gerd Hoffmann wrote:
Hi,
As far as the EDID is concerned, there can only be one EDID for a
display+hw pair, or the guest won't know what to do. In my use-case, I
simply pass real EDIDs through, and create a full-screen window for each
real monitor.
Ok, makes sense.
I
On 11/06/2013 05:55 AM, Gerd Hoffmann wrote:
Hi,
In QEMU 1.3, there was a DisplayState list. We used one DisplayState per
monitor. The DisplayChangeListener has a new hw_add_display vector, so
that when the UI requests a second monitor the new display gets attached
to the emulated hardware.
On 11/05/2013 08:46 PM, Dave Airlie wrote:
On Wed, Nov 6, 2013 at 6:42 AM, John Baboval wrote:
Hello,
I am currently the device model maintainer for XenClient Enterprise. As you
may or may not know, we maintain a patch queue on top of QEMU (currently
1.3) that adds functionality needed to
Hello,
I am currently the device model maintainer for XenClient Enterprise. As
you may or may not know, we maintain a patch queue on top of QEMU
(currently 1.3) that adds functionality needed to support XCE features.
One of the major things we add is robust multi-head support. This
includes
On 05/10/2013 11:28 PM, Eric Blake wrote:
On 05/07/2013 04:39 PM, John Baboval wrote:
From: "John V. Baboval"
This parameter will cause writes to tty backed chardevs to return
-EAGAIN if the backing tty has buffered more than the specified
number of characters. When data is sent, th
ers in the TTY output buffer are
still sent. The device buffer overflows and data is lost. In this
case the user could set maxqdepth=1.
Signed-off-by: John Baboval
---
Includes changes recommended by Eric Blake and Paolo Bonzini:
Parameter documentation includes a (since 1.6)
Documentation for s
Sorry about fumbling with the tools. The wiki link is very helpful. I'll give
it another go in a little while.
-Original Message-
From: Eric Blake [mailto:ebl...@redhat.com]
Sent: Tuesday, May 07, 2013 1:17 PM
To: John Baboval
Cc: qemu-devel@nongnu.org; John Baboval
Subject: Re:
Includes changes requested by Eric Blake and Paolo Bonzini
ers in the TTY output buffer are
still sent. The device buffer overflows and data is lost. In this
case the user could set maxqdepth=1.
Signed-off-by: John Baboval
---
include/sysemu/char.h |2 ++
qapi-schema.json |5 -
qemu-char.c
Hmm. I seem to have screwed up the "In-Reply-To" on this one. Sorry
about that.
On 05/07/2013 12:36 PM, John Baboval wrote:
From: "John V. Baboval"
This parameter will cause writes to tty backed chardevs to return
-EAGAIN if the backing tty has buffered more than the
ers in the TTY output buffer are
still sent. The device buffer overflows and data is lost. In this
case the user could set maxqdepth=1.
Signed-off-by: John Baboval
---
include/sysemu/char.h |2 ++
qapi-schema.json |5 -
qemu-char.c
Thanks for the feedback. I've made the maxqdepth parameter optional as
requested.
ers in the TTY output buffer are
still sent. The device buffer overflows and data is lost. In this
case the user could set maxqdepth=1.
Signed-off-by: John Baboval
---
include/sysemu/char.h |2 ++
qapi-schema.json |5 -
qemu-char.c
Josh,
Somehow missed this message going by. Sorry about that.
The 720p support patch (and variable VRAM size) slipped off my radar.
I'm going to try and get another batch of interesting patches from the
XenClient Enterprise device model ready to submit in the coming weeks,
and I'll add that o
On 11/07/2011 11:43 AM, Stefano Stabellini wrote:
On Fri, 28 Oct 2011, John Baboval wrote:
Call xc_domain_shutdown with the reboot flag when the guest requests a
reboot.
Thanks for the patch!
Sorry for the delay in replaying but away for XenSummit Asia.
Signed-off-by: John V. Baboval
This is a good idea. I'm going to re-work the patch, but I have a lot of
other stuff going on too, so it may be a week or so before I get back to it.
On 11/01/2011 12:57 PM, Gerd Hoffmann wrote:
On 11/01/11 14:39, John Baboval wrote:
I don't know of any reason for it.
I
I don't know of any reason for it.
-John
On Nov 1, 2011, at 4:58 AM, "Gerd Hoffmann" wrote:
> On 10/28/11 21:24, John Baboval wrote:
>> 760p TV panels have a 1366x768 resolution, and have been popular
>> recently as low-cost monitors. The 1366 resolution doesn
This fixes up a few compiler warnings/errors when building with
IDE_DEBUG or AHCI_DEBUG enabled.
Signed-off-by: John V. Baboval
---
hw/ide/ahci.c |2 +-
hw/ide/pci.c |2 +-
hw/ide/piix.c |4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/ide/ahci.c b/hw/ide/
Don't perform RTC or APIC setup when running in xen mode.
Signed-off-by: John V. Baboval
---
hw/pc.c | 56
+---
hw/pc_piix.c |2 +-
2 files changed, 30 insertions(+), 28 deletions(-)
diff --git a/hw/pc.c b/hw/pc.c
index eb4c2d8..
When in xen mode, handle the view of pm ioport appropriately.
I'm not entirely comfortable with this patch, since it relies on values
that are hard coded into the DSDT that is shipped with Xen. There has to
be a better way to handle it, but I haven't thought of what that might
be yet... Perhaps
Call xc_domain_shutdown with the reboot flag when the guest requests a
reboot.
Signed-off-by: John V. Baboval
Signed-off-by: Tom Goetz
---
xen-all.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/xen-all.c b/xen-all.c
index b5e28ab..cd71b24 1006
These are some xen related patches that have been sitting around in are
queue waiting for us to re-base onto a modern qemu. Now that we're
up-to-date, they're ready to share with the list.
They are all things that enable successfully running windows in xen HVM
guests.
Support guest reboots w
High resolution VGA modes require more than the default 8MB of VGA
RAM. Add a command line parameter to allow larger sizes.
Signed-off-by: John V. Baboval
---
hw/vga.c| 64
++
hw/vga_int.h|4 +++
qemu-options.hx |3 ++
This is a pair of VGA related patches.
The first allows the use of a 1366x768 VGA resolution.
The second allows the user to specify an alternate VRAM size with a
command line parameter.
-John
760p TV panels have a 1366x768 resolution, and have been popular
recently as low-cost monitors. The 1366 resolution doesn't pass
the (xres & 7) == 0 test.
Signed-off-by: John V. Baboval
---
hw/vga.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/vga.c b/hw/vga.c
in
So I've figured out the answer to my own question... I was, in fact,
missing something.
The destructor for the subregion is not overwritten. It's the parent
region's destructor that is written.
On 10/26/2011 09:52 AM, John Baboval wrote:
Sorry for coming late to the party on
Sorry for coming late to the party on this... I only read qemu-devel
through a filter so I missed all the discussions on the new memory API.
I have a question as to how it works and how it's supposed to work in
certain scenarios.
It's a question of flow. I'm following the code path through the
ul 30, 2011, at 2:41 AM, "Blue Swirl" wrote:
> Thanks, applied.
>
> On Fri, Jul 29, 2011 at 4:49 AM, Isaku Yamahata
> wrote:
>> On Fri, Jul 15, 2011 at 07:51:43PM +0300, Blue Swirl wrote:
>>> On Fri, Jul 15, 2011 at 6:18 PM, John Baboval
>>> wrote:
Is there something I can do to help take this patch the rest of the way?
I'd hate to see it die because of a style issue and a compiler warning.
-John
On 06/15/2011 02:19 PM, Blue Swirl wrote:
On Sat, Jun 11, 2011 at 1:29 AM, Michael Tokarev wrote:
I've given up on this one. Personally I do
I find I have to point at the src directories, and not the dist
directory. My extra-cflags looks something like this:
--extra-cflags=-I /path/to/xen/tools/include -L /path/to/xen/tools/libxc
-I /path/to/xen/tools/libxc -L /path/to/xen/tools/xenstore -I
/path/to/xen/tools/xenstore'
-John
On
Sorry for coming late to this thread.
I've tested this patch, after fixing the format specifier, and it works.
(Though I did test with Xen, and not KVM.)
It's quite convenient. I'm planning on including it in the build we ship
with our product.
It would be nice to see the style issues clean
This seems to leak entries on the map cache locked entries list. Patch
below:
Signed-off-by: John Baboval
---
exec.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/exec.c b/exec.c
index 1f88d6a..f18cb7d 100644
--- a/exec.c
+++ b/exec.c
@@ -3759,9 +3759,8 @@ void
52 matches
Mail list logo
