On 2019/2/12 下午1:08, Michael S. Tsirkin wrote:
On Mon, Feb 11, 2019 at 02:58:30PM +, David Riddoch wrote:
This can result in a very high rate of doorbells with some
drivers, which can become a severe bottleneck (because x86 CPUs can't emit
MMIOs at very high rates).
Interesting. Is there
On Mon, Feb 11, 2019 at 02:58:30PM +, David Riddoch wrote:
> > > > > This can result in a very high rate of doorbells with some
> > > > > drivers, which can become a severe bottleneck (because x86 CPUs can't
> > > > > emit
> > > > > MMIOs at very high rates).
> > > > Interesting. Is there any
On Mon, Feb 11, 2019 at 07:14:53AM -0800, Frank Yang wrote:
>
>
> On Mon, Feb 11, 2019 at 6:49 AM Michael S. Tsirkin wrote:
>
> On Mon, Feb 04, 2019 at 11:42:25PM -0800, Roman Kiryanov wrote:
> > Hi Gerd,
> >
> > > virtio-gpu specifically needs that to support vulkan and opengl
BTW, I have a few concerns about the upcoming shared-mem virtio type. This
is mostly directed at David and kraxel.
We've found that for many applications, simply telling the guest to create
a new host pointer of Vulkan or OpenGL has quite some overhead in just
telling the hypervisor to map it,
On Mon, Feb 11, 2019 at 6:49 AM Michael S. Tsirkin wrote:
> On Mon, Feb 04, 2019 at 11:42:25PM -0800, Roman Kiryanov wrote:
> > Hi Gerd,
> >
> > > virtio-gpu specifically needs that to support vulkan and opengl
> > > extensions for coherent buffers, which must be allocated by the host
> gpu
> >
This can result in a very high rate of doorbells with some
drivers, which can become a severe bottleneck (because x86 CPUs can't emit
MMIOs at very high rates).
Interesting. Is there any data you could share to help guide the design?
E.g. what's the highest rate of MMIO writes supported etc?
On
On Mon, Feb 04, 2019 at 11:42:25PM -0800, Roman Kiryanov wrote:
> Hi Gerd,
>
> > virtio-gpu specifically needs that to support vulkan and opengl
> > extensions for coherent buffers, which must be allocated by the host gpu
> > driver. It's WIP still.
>
> the proposed spec says:
>
> +Shared
On Mon, Feb 11, 2019 at 08:52:01AM +, David Riddoch wrote:
> On 11/02/2019 07:33, Michael S. Tsirkin wrote:
> > On Fri, Feb 01, 2019 at 02:23:55PM +, David Riddoch wrote:
> > > All,
> > >
> > > I'd like to propose a small extension to the packed virtqueue mode. My
> > > proposal is to
(Apologies if you got this a second time: The first copy went to the
wrong list).
I think your proposal of write to p_int_en_doorbell will work for us.
The write
event to this new address in BAR itself implicitly tell the device that
interrupt is enabled and also it conveys the last used
On 11/02/2019 07:33, Michael S. Tsirkin wrote:
On Fri, Feb 01, 2019 at 02:23:55PM +, David Riddoch wrote:
All,
I'd like to propose a small extension to the packed virtqueue mode. My
proposal is to add an offset/wrap field, written by the driver, indicating
how many available descriptors
10 matches
Mail list logo
