Hi,
On 09/05/2014 02:00 PM, Gianni Pirozzi wrote:
Hello,
I tried this patch and observed a great improvement in cursor positioning,
thanks!
But I'm confused about dynamic resizing of the guest screen, it seems too tied
to the presentation.
I'm using spice-html5 in a web application which has i
Hello,
I tried this patch and observed a great improvement in cursor positioning,
thanks!
But I'm confused about dynamic resizing of the guest screen, it seems too tied
to the presentation.
I'm using spice-html5 in a web application which has it's own layout replacing
spice.html and spice.css, b
Hey,
Thanks for the detailed analysis, and as usual, very late answer :(
On Fri, Aug 22, 2014 at 01:41:11PM -0500, Jeremy White wrote:
> I'm hoping to ask for some advice on the spice server.
>
> Background:
> I've hit a bug with Xspice. The current implementation uses a separate
> thread to gr
Many systems don't use rsyslog, others don't need seperate syslog files
for vdagent. Instead, /var/log/messages can be grep for spice-vdagent,
or system with the journal can call journalctl
SYSLOG_IDENTIFIER=spice-vdagent.
This simplify spice-vdagent packaging and updates, since there are no
conf
ranch 'remotes/spice/tags/pull-spice-20140902-1'
> into staging (2014-09-02 10:26:10 +0100)
>
> are available in the git repository at:
>
>
> git://git.kraxel.org/qemu tags/pull-cve-2014-3615-20140905-1
>
> for you to fetch changes up to ab9509cceabef28071e41b
VgaState->vram_size is the size of the pci bar. In case of qxl not the
whole pci bar can be used as vga framebuffer. Add a new variable
vbe_size to handle that case. By default (if unset) it equals
vram_size, but qxl can set vbe_size to something else.
This makes sure VBE_DISPI_INDEX_VIDEO_MEMO
Related spice-only bug. We have a fixed 16 MB buffer here, being
presented to the spice-server as qxl video memory in case spice is
used with a non-qxl card. It's also used with qxl in vga mode.
When using display resolutions requiring more than 16 MB of memory we
are going to overflow that buff
0100)
are available in the git repository at:
git://git.kraxel.org/qemu tags/pull-cve-2014-3615-20140905-1
for you to fetch changes up to ab9509cceabef28071e41bdfa073083859c949a7:
spice: make sure we don't overflow ssd->buf (2014-09
Plug a bunch of holes in the bochs dispi interface parameter checking.
Add a function doing verification on all registers. Call that
unconditionally on every register write. That way we should catch
everything, even changing one register affecting the valid range of
another register.
Some of the
On 09/05/14 11:33, Gerd Hoffmann wrote:
> On Fr, 2014-09-05 at 11:06 +0200, Laszlo Ersek wrote:
>>> > > Makes sense. I think it is easier to just multiply in 64bit, then
>> > check
>>> > > the result is small enougth (new patch attached).
>> >
>> > Okay, if you can guarantee that the product fits
On 09/05/14 10:58, Gerd Hoffmann wrote:
> Hi,
>
>> I can't track this back far enough. I'd feel safer if you checked that
>> the multiplication can't overflow even in uint64_t.
>
> Effectively it comes from the emulated graphics hardware (anything in
> hw/display/*). The gfx emulation must mak
On Fr, 2014-09-05 at 11:06 +0200, Laszlo Ersek wrote:
> > Makes sense. I think it is easier to just multiply in 64bit, then
> check
> > the result is small enougth (new patch attached).
>
> Okay, if you can guarantee that the product fits in uint64_t, then
> such
> a check would suffice.
>
> New
Hi,
> I can't track this back far enough. I'd feel safer if you checked that
> the multiplication can't overflow even in uint64_t.
Effectively it comes from the emulated graphics hardware (anything in
hw/display/*). The gfx emulation must make sure that the framebuffer
fits into the video memo
On 09/04/14 09:04, Gerd Hoffmann wrote:
> Related spice-only bug. We have a fixed 16 MB buffer here, being
> presented to the spice-server as qxl video memory in case spice is
> used with a non-qxl card. It's also used with qxl in vga mode.
>
> When using display resolutions requiring more than
14 matches
Mail list logo
