[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150915184444.6cc6e648.cornelia.huck@de.ibm.com>
Date: Tue, 15 Sep 2015 18:44:44 +0200
From: Cornelia Huck <cornelia.huck@...ibm.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Jason Wang <jasowang@...hat.com>, gleb@...nel.org,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org, mst@...hat.com
Subject: Re: [PATCH V6 6/6] kvm: add fast mmio capabilitiy
On Tue, 15 Sep 2015 18:29:49 +0200
Paolo Bonzini <pbonzini@...hat.com> wrote:
> On 15/09/2015 18:13, Cornelia Huck wrote:
> > On Tue, 15 Sep 2015 17:07:55 +0200
> > Paolo Bonzini <pbonzini@...hat.com> wrote:
> >
> >> On 15/09/2015 08:41, Jason Wang wrote:
> >>> +With KVM_CAP_FAST_MMIO, a zero length mmio eventfd is allowed for
> >>> +kernel to ignore the length of guest write and get a possible faster
> >>> +response. Note the speedup may only work on some specific
> >>> +architectures and setups. Otherwise, it's as fast as wildcard mmio
> >>> +eventfd.
> >>
> >> I don't really like tying the capability to MMIO, especially since
> >> zero length ioeventfd is already accepted for virtio-ccw.
> >
> > Actually, zero length ioeventfd does not make sense for virtio-ccw;
>
> Can you explain why? If there is any non-zero valid length, "wildcard
> length" (represented by zero) would also make sense.
What is a wildcard match supposed to mean in this case? The datamatch
field contains the queue index for the device specified in the address
field. The hypercall interface associated with the eventfd always has
device + queue index in its parameters; there is no interface for
"notify device with all its queues".
But maybe I'm just lacking imagination :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists