Re: [PATCH v4] Add virtio-input driver.
Vojtech Pavlik writes: > On Wed, Mar 25, 2015 at 01:51:43PM +1030, Rusty Russell wrote: >> Imagine a future virtio standard which incorporates this. And a Windows >> or FreeBSD implementation of the device and or driver. How ugly would >> they be? > > A windows translation layer is fairly easy, people porting software from > Windows to Linux told me numerous times that adapting isn't hard. I also > believe that at least one of the BSD's has a compatible implementation > these days based on the fact that I was asked to allow copying the > headers in the past. Thanks Vojtech, that answers my questions. I figure we apply this and see where it leads... Cheers, Rusty. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH 0/9] qspinlock stuff -v15
On Mon, Mar 16, 2015 at 02:16:13PM +0100, Peter Zijlstra wrote: > Hi Waiman, > > As promised; here is the paravirt stuff I did during the trip to BOS last > week. > > All the !paravirt patches are more or less the same as before (the only real > change is the copyright lines in the first patch). > > The paravirt stuff is 'simple' and KVM only -- the Xen code was a little more > convoluted and I've no real way to test that but it should be stright fwd to > make work. > > I ran this using the virtme tool (thanks Andy) on my laptop with a 4x > overcommit on vcpus (16 vcpus as compared to the 4 my laptop actually has) and > it both booted and survived a hackbench run (perf bench sched messaging -g 20 > -l 5000). > > So while the paravirt code isn't the most optimal code ever conceived it does > work. > > Also, the paravirt patching includes replacing the call with "movb $0, %arg1" > for the native case, which should greatly reduce the cost of having > CONFIG_PARAVIRT_SPINLOCKS enabled on actual hardware. Ah nice. That could be spun out as a seperate patch to optimize the existing ticket locks I presume. Now with the old pv ticketlock code an vCPU would only go to sleep once and be woken up when it was its turn. With this new code it is woken up twice (and twice it goes to sleep). With an overcommit scenario this would imply that we will have at least twice as many VMEXIT as with the previous code. I presume when you did benchmarking this did not even register? Thought I wonder if it would if you ran the benchmark for a week or so. > > I feel that if someone were to do a Xen patch we can go ahead and merge this > stuff (finally!). > > These patches do not implement the paravirt spinlock debug stats currently > implemented (separately) by KVM and Xen, but that should not be too hard to do > on top and in the 'generic' code -- no reason to duplicate all that. > > Of course; once this lands people can look at improving the paravirt nonsense. > ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] Add virtio gpu driver.
On Wed, Mar 25, 2015 at 04:37:16PM +0100, Gerd Hoffmann wrote: > Hi, > > > BTW can we teach virtio-gpu to look for framebuffer using > > virtio pci caps? > > The virtio-gpu driver doesn't matter much here, it doesn't use it > anyway. > > > Or are there limitations such as only > > using IO port BARs, or compatibility with > > BIOS code etc that limit us to specific BARs anyway? > > Yes, vgabios code needs to know. Currently it has bar #2 for the vga > framebuffer bar hardcoded. It's 16bit code. I don't feel like making > the probing more complicated ... > > cheers, > Gerd OK - you are saying all VGA cards use bar #2 for this functionality, so we are just following established practice here? -- MST ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] Add virtio gpu driver.
Hi, On Wednesday, March 25, 2015, Dave Airlie wrote: > On 25 March 2015 at 08:50, Daniel Stone > wrote: > > I'm not going to lie, I was really hoping the 5th (?) GPU option for > > Qemu would support pageflipping. Daniel's comment about conversion to > > atomic is relevant, but: do you have a mechanism which allows you to > > post updates (e.g. 'start displaying this buffer now please') that > > allows you to get events back when they have actually been displayed? > > Page flip is implemented in a later patch, > > > https://www.kraxel.org/cgit/linux/commit/?h=virtio-gpu&id=1e167e8e964f8e08100d315dd354cc0a4b090841 > > Since its a long way from an actual display, finding out when > something is actually displayed is hard, > but when we've posted it to the frontbuffer should be fine. > Oh nice. 100% exact timings aren't critical; it's more just having something to gate to 60fps that we can actually drive Weston's repaint loop off, as that's (not unreasonably) driven by pageflip events. Cheers, Daniel ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH v4] Add virtio-input driver.
On Wed, Mar 25, 2015 at 01:51:43PM +1030, Rusty Russell wrote: > Gerd Hoffmann writes: > > virtio-input is basically evdev-events-over-virtio, so this driver isn't > > much more than reading configuration from config space and forwarding > > incoming events to the linux input layer. > > > > Signed-off-by: Gerd Hoffmann > > Is the input layer sane? I've never dealt with it, so I don't know. I'm rather biased having designed it, but I'd say it's reasonable. It certainly has limitations and design mistakes, but none are too bad. One testimony to that Android has based its own Input API around it. > What's it used for? For all human input devices, like keyboards, mice, touchscreens, etc. > Imagine a future virtio standard which incorporates this. And a Windows > or FreeBSD implementation of the device and or driver. How ugly would > they be? A windows translation layer is fairly easy, people porting software from Windows to Linux told me numerous times that adapting isn't hard. I also believe that at least one of the BSD's has a compatible implementation these days based on the fact that I was asked to allow copying the headers in the past. -- Vojtech Pavlik Director SUSE Labs ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] Add virtio gpu driver.
Hi,
On 24 March 2015 at 16:07, Gerd Hoffmann wrote:
> +static int virtio_gpu_crtc_page_flip(struct drm_crtc *crtc,
> +struct drm_framebuffer *fb,
> +struct drm_pending_vblank_event *event,
> +uint32_t flags)
> +{
> + return -EINVAL;
> +}
I'm not going to lie, I was really hoping the 5th (?) GPU option for
Qemu would support pageflipping. Daniel's comment about conversion to
atomic is relevant, but: do you have a mechanism which allows you to
post updates (e.g. 'start displaying this buffer now please') that
allows you to get events back when they have actually been displayed?
Cheers,
Daniel
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] Add virtio gpu driver.
Hi, > BTW can we teach virtio-gpu to look for framebuffer using > virtio pci caps? The virtio-gpu driver doesn't matter much here, it doesn't use it anyway. > Or are there limitations such as only > using IO port BARs, or compatibility with > BIOS code etc that limit us to specific BARs anyway? Yes, vgabios code needs to know. Currently it has bar #2 for the vga framebuffer bar hardcoded. It's 16bit code. I don't feel like making the probing more complicated ... cheers, Gerd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] Add virtio gpu driver.
On Wed, Mar 25, 2015 at 03:52:01PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > diff --git a/drivers/virtio/virtio_pci_common.c
> > > b/drivers/virtio/virtio_pci_common.c
> > > index e894eb2..a3167fa 100644
> > > --- a/drivers/virtio/virtio_pci_common.c
> > > +++ b/drivers/virtio/virtio_pci_common.c
> > > @@ -510,7 +510,7 @@ static int virtio_pci_probe(struct pci_dev *pci_dev,
> > > goto err_enable_device;
> > >
> > > rc = pci_request_regions(pci_dev, "virtio-pci");
> > > - if (rc)
> > > + if (rc && ((pci_dev->class >> 8) != PCI_CLASS_DISPLAY_VGA))
> > > goto err_request_regions;
> > >
> > > if (force_legacy) {
> >
> > This is probably what you described as "the only concern?
>
> Ahem, no, forgot that one,
What does the concern refer to then?
> but it is related. With vesafb using and
> registering the vga compat framebuffer bar pci_request_regions will not
> succeed.
>
> vesafb will be unregistered later on (this is what I was refering to) by
> the virtio-gpu driver.
>
> > If we only need to request specific
> > regions, I think we should do exactly that, requesting only parts of
> > regions that are covered by the virtio capabilities.
>
> That should work too.
>
> cheers,
> Gerd
BTW can we teach virtio-gpu to look for framebuffer using
virtio pci caps? Or are there limitations such as only
using IO port BARs, or compatibility with
BIOS code etc that limit us to specific BARs anyway?
--
MST
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] Add virtio gpu driver.
On Di, 2015-03-24 at 22:50 +, Daniel Stone wrote:
> Hi,
>
> On 24 March 2015 at 16:07, Gerd Hoffmann wrote:
> > +static int virtio_gpu_crtc_page_flip(struct drm_crtc *crtc,
> > +struct drm_framebuffer *fb,
> > +struct drm_pending_vblank_event *event,
> > +uint32_t flags)
> > +{
> > + return -EINVAL;
> > +}
>
> I'm not going to lie, I was really hoping the 5th (?) GPU option for
> Qemu would support pageflipping.
As Dave already pointed out there is a WIP patch for that, it'll be
there.
While being at it:
- bochsdrm (qemu -vga std driver) supports pageflip since 3.19.
- cirrus is more or less a lost case, we mimic existing hardware
from the 90ies here and it simply isn't up to todays needs for
many reasons. Just stop using it.
- qxl -- hmm, not sure, there is this "primary surface" concept in
the virtual hardware design, which doesn't mix very well with
pageflip I suspect.
> Daniel's comment about conversion to
> atomic is relevant, but: do you have a mechanism which allows you to
> post updates (e.g. 'start displaying this buffer now please') that
> allows you to get events back when they have actually been displayed?
It's possible to fence the framebuffer update requests, so you'll be
notified when the update has reached the qemu ui code. Typically the ui
code has queued the update at that point. So with a local display (sdl,
gtk) showing up on the screen should be just a pageflip (on the host)
away. With a remote display (vnc) it will take a little longer until
the user will actually see the update.
cheers,
Gerd
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] Add virtio gpu driver.
> > Signed-off-by: Dave Airlie > > Signed-off-by: Gerd Hoffmann > > Standard request from my side for new drm drivers (especially if they're > this simple): Can you please update the drivers to latest drm internal > interfaces, i.e. using universal planes and atomic? Have a docs / sample code pointer for me? thanks, Gerd ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
Re: [PATCH] Add virtio gpu driver.
Hi,
> > diff --git a/drivers/virtio/virtio_pci_common.c
> > b/drivers/virtio/virtio_pci_common.c
> > index e894eb2..a3167fa 100644
> > --- a/drivers/virtio/virtio_pci_common.c
> > +++ b/drivers/virtio/virtio_pci_common.c
> > @@ -510,7 +510,7 @@ static int virtio_pci_probe(struct pci_dev *pci_dev,
> > goto err_enable_device;
> >
> > rc = pci_request_regions(pci_dev, "virtio-pci");
> > - if (rc)
> > + if (rc && ((pci_dev->class >> 8) != PCI_CLASS_DISPLAY_VGA))
> > goto err_request_regions;
> >
> > if (force_legacy) {
>
> This is probably what you described as "the only concern?
Ahem, no, forgot that one, but it is related. With vesafb using and
registering the vga compat framebuffer bar pci_request_regions will not
succeed.
vesafb will be unregistered later on (this is what I was refering to) by
the virtio-gpu driver.
> If we only need to request specific
> regions, I think we should do exactly that, requesting only parts of
> regions that are covered by the virtio capabilities.
That should work too.
cheers,
Gerd
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
