directly as a device?
> >
> > The basic vhost-user stuff isn't actually that hard; if you aren't
> > actually shuffling commands over the queues you should find it pretty
> > simple - so I think your assumption about it being simpler if you
> > avoid
> > it
he guest to get the guest display scanned out
to the host?
Unfortunately no, NVidia and AMD devices do not support mirroring their
outputs to a separate GPU unless it's a professional-grade GPU such as a
Quadro or Firepro.
-Geoff
cheers,
Gerd
you
avoid
it might be wrong. It might be easier if you use it!
I have been looking into this and I am yet to find some decent
documentation or a simple device example I can use to understand how to
create such a device. Do you know of any reading or examples I can
obtain
on how to get an initi
use it!
I have been looking into this and I am yet to find some decent
documentation or a simple device example I can use to understand how to
create such a device. Do you know of any reading or examples I can
obtain
on how to get an initial do nothing device up and running?
-Geoff
Dave
>
> thanks
> -- PMM
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
On 2019-11-01 01:52, Peter Maydell wrote:
On Thu, 31 Oct 2019 at 14:26, wrote:
As the author of Looking Glass, I also have to consider the
maintenance
and the complexity of implementing the vhost protocol into the
project.
At this time a complete Porthole client can be implemented in 150
l
however, it's authors have also implemented transport via shared RAM.
While vhost-user would make much more sense here as vring buffers
would be very useful, the barrier to entry is too high and as such the
developers have instead opted to use the simple IVSHMEM device instead.
That said, I will
/77e7fb54604b42a1a98ecb8bf3d2cf46
-Geoff
On 2019-10-31 13:55, ge...@hostfission.com wrote:
Hi Dave,
On 2019-10-31 05:52, Dr. David Alan Gilbert wrote:
* ge...@hostfission.com (ge...@hostfission.com) wrote:
Hi All,
Over the past week, I have been working to come up with a solution to
the
memory transfer performance
ou still believe that vhost-user should be used, I will do what I
can to
implement it, but for such a simple device I honestly believe it is
overkill.
-Geoff
This device and the windows driver have been designed in such a way
that
it's a
utility device for any project and/or app
ple client application for this
device
https://gist.github.com/gnif/77e7fb54604b42a1a98ecb8bf3d2cf46
-Geoff
On 2019-10-30 01:31, ge...@hostfission.com wrote:
Hi All,
Over the past week, I have been working to come up with a solution to
the
memory transfer performance issues that hinder the Looking Glas
Just to follow this up, here is a sample client application for this
device
https://gist.github.com/gnif/77e7fb54604b42a1a98ecb8bf3d2cf46
-Geoff
On 2019-10-30 01:31, ge...@hostfission.com wrote:
Hi All,
Over the past week, I have been working to come up with a solution to
the
memory
Hi All,
Over the past week, I have been working to come up with a solution to
the
memory transfer performance issues that hinder the Looking Glass
Project.
Currently Looking Glass works by using the IVSHMEM shared memory device
which
is fed by an application that captures the guest's video o
Hi Phil
On 2019-10-24 22:07, Philippe Mathieu-Daudé wrote:
Hi Geoffrey,
On 10/24/19 10:27 AM, ge...@hostfission.com wrote:
Hi All,
I have been working on adding a feature as a proof of concept to
improve the performance of applications like Looking Glass by avoiding
additional memory copies
Hi All,
I have been working on adding a feature as a proof of concept to improve
the performance of applications like Looking Glass by avoiding
additional memory copies. My goal is to alias part of the IVSHMEM shared
memory over a pointer provided by the guest OS capture API (DXGI Desktop
Dup
I can confirm that these patches work as expected. Thank you kindly Alex
for your hard work!
Tested-by: Geoffrey McRae
On 2018-11-15 07:50, Alex Williamson wrote:
QEMU exposes gen1 PCI-express interconnect devices supporting only
2.5GT/s and x1 width. It might not seem obvious that a virtual
On 2018-05-07 22:41, Gerd Hoffmann wrote:
On Mon, May 07, 2018 at 10:26:24PM +1000, geoff--- via Qemu-devel
wrote:
On 2018-05-07 22:21, Gerd Hoffmann wrote:
> On Mon, May 07, 2018 at 10:00:22PM +1000, geoff--- via Qemu-devel wrote:
> > This allows guest's to correctly reinitializ
2_queue_bytes(PS2State *s, const int length, ...)
Ack.
I'd prefer to not use vaargs here as gcc can't check the arguments
then.
Suggest to just have ps2_queue_{2,3,4}() helpers instead to queue
multibyte messages.
Ack.
cheers,
Gerd
Thanks,
Geoff
On 2018-05-07 22:21, Gerd Hoffmann wrote:
On Mon, May 07, 2018 at 10:00:22PM +1000, geoff--- via Qemu-devel
wrote:
This allows guest's to correctly reinitialize and identify the mouse
should the guest decide to re-scan or reset during mouse input events.
Signed-off-by: Geoffrey McRae
--
This fixes an issue by adding bounds checking to multi-byte packets
where the PS/2 mouse data stream may become corrupted due to data
being discarded when the PS/2 ringbuffer is full.
Interrupts for Multi-byte responses are postponed until the final
byte has been queued.
These changes fix a bug
This allows guest's to correctly reinitialize and identify the mouse
should the guest decide to re-scan or reset during mouse input events.
Signed-off-by: Geoffrey McRae
---
hw/input/ps2.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/input/ps2.c b/hw/input/ps2.c
index 06f5d2ac4a..
Works well for me, thanks!
Tested-by: Geoffrey McRae
On 2018-04-27 02:26, Babu Moger wrote:
This series enables the TOPOEXT feature for AMD CPUs. This is required
to
support hyperthreading on kvm guests.
This addresses the issues reported in these bugs:
https://bugzilla.redhat.com/show_bug.c
ny insight as to why this might be?
I am running master @ 11ed801d3df3c6e46b2f1f97dcfbf4ca3a2a2f4f
Host: AMD Thread Ripper 1950x
Guest launch parameters:
/usr/local/bin/qemu-system-x86_64 \
-nographic \
-runas geoff \
-monitor stdio \
-name guest=Aeryn,debug-threads=on \
-machine q35,acce
I just updated to the latest build and applied this patch set, now on VM
reset the qemu crashes with the following assert:
ivshmem.c:467: ivshmem_add_kvm_msi_virq: Assertion
`!s->msi_vectors[vector].pdev' failed.
On 2017-11-15 18:31, Ladi Prosek wrote:
Fixes bugs in the ivshmem device implem
can trigger it by simply unloading the windows
driver and then attempting to re-load it.
-Geoff
Thanks Ladi, I had not yet had time to dig into these, this patch set
resolves all issues I was aware of.
Tested-by: Geoffrey McRae
On 2017-11-11 04:34, Ladi Prosek wrote:
As of commit 660c97eef6f8 ("ivshmem: use kvm irqfd for msi
notifications"),
QEMU crashes with:
kvm_irqchip_commit_rou
Hi All,
I have started to dig into why ntp seems to slow down graphics
performance on
AMD systems using PCI passthrough and figured I would report what I have
so far
discovered. I have noted the primary point of failure seems to be
specifically
with PhysX. This is why people only see a slow do
On 2017-10-19 20:51, Ladi Prosek wrote:
On Thu, Oct 19, 2017 at 11:41 AM, wrote:
On 2017-10-19 20:07, ge...@hostfission.com wrote:
On 2017-10-19 20:01, Ladi Prosek wrote:
On Thu, Oct 19, 2017 at 10:44 AM, wrote:
On 2017-10-19 19:35, Ladi Prosek wrote:
On Wed, Oct 18, 2017 at 5:04 PM
On 2017-10-19 20:07, ge...@hostfission.com wrote:
On 2017-10-19 20:01, Ladi Prosek wrote:
On Thu, Oct 19, 2017 at 10:44 AM, wrote:
On 2017-10-19 19:35, Ladi Prosek wrote:
On Wed, Oct 18, 2017 at 5:04 PM, wrote:
Hi Ladi & Yan,
I am pleased to present the completed driver for review, ple
On 2017-10-19 20:01, Ladi Prosek wrote:
On Thu, Oct 19, 2017 at 10:44 AM, wrote:
On 2017-10-19 19:35, Ladi Prosek wrote:
On Wed, Oct 18, 2017 at 5:04 PM, wrote:
Hi Ladi & Yan,
I am pleased to present the completed driver for review, please see:
https://github.com/gnif/kvm-guest-drivers
On 2017-10-19 19:35, Ladi Prosek wrote:
On Wed, Oct 18, 2017 at 5:04 PM, wrote:
Hi Ladi & Yan,
I am pleased to present the completed driver for review, please see:
https://github.com/gnif/kvm-guest-drivers-windows
Awesome!
Feel free to open pull request, it should be easier to comment on.
Hi Ladi & Yan,
I am pleased to present the completed driver for review, please see:
https://github.com/gnif/kvm-guest-drivers-windows
All issues previously mentioned have been addressed and all missing
functionality has been added.
Please note that this work has exposed a bug in the qemu ivshm
On 2017-10-18 17:50, Ladi Prosek wrote:
On Wed, Oct 18, 2017 at 7:50 AM, wrote:
On 2017-10-18 16:31, Ladi Prosek wrote:
Hi Geoff,
On Mon, Oct 16, 2017 at 8:31 PM, wrote:
Hi Yan & Ladi.
I have written an initial implementation that supports just the
shared
memory
mapping at this
On 2017-10-18 16:31, Ladi Prosek wrote:
Hi Geoff,
On Mon, Oct 16, 2017 at 8:31 PM, wrote:
Hi Yan & Ladi.
I have written an initial implementation that supports just the shared
memory
mapping at this time. I plan to add events also but before I go
further I
would
like some feedbac
uest-drivers-windows/commit/8655cf12fbdd77b991f96d97bc20f967b5907c12
Kind Regards,
Geoff
On 2017-10-15 23:29, ge...@hostfission.com wrote:
On 2017-10-15 23:24, Yan Vugenfirer wrote:
On 15 Oct 2017, at 15:21, ge...@hostfission.com wrote:
Hi Yan,
Thank you for the information. I am rather new to Win
er, how would be the best way
to go about it so as to ensure that it is in a state that it could be
signed with the RedHat vendor key?
3) What is the likelihood of having such a driver signed?
4) Is there a preferred git host for such a driver?
Kind Regards
-Geoff
When the guest OS needs to send the mouse commands it will at least in
the case
of Windows 10 set the KBD_MODE_DISABLE_MOUSE bit to prevent interrupts
from
causing stream desynchronisation.
Here is Windows 10 attempting to issue a PS/2 mouse reset without this
fix where
you can see the mouse p
35 matches
Mail list logo
