[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D1910E3505@SHSMSX101.ccr.corp.intel.com>
Date: Wed, 11 Apr 2018 01:38:29 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: "Liang, Cunming" <cunming.liang@...el.com>,
"Michael S. Tsirkin" <mst@...hat.com>
CC: "Duyck, Alexander H" <alexander.h.duyck@...el.com>,
"virtio-dev@...ts.oasis-open.org" <virtio-dev@...ts.oasis-open.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"virtualization@...ts.linux-foundation.org"
<virtualization@...ts.linux-foundation.org>,
"Wang, Xiao W" <xiao.w.wang@...el.com>,
"ddutile@...hat.com" <ddutile@...hat.com>,
"Tan, Jianfeng" <jianfeng.tan@...el.com>,
"Wang, Zhihong" <zhihong.wang@...el.com>,
Paolo Bonzini <pbonzini@...hat.com>
Subject: RE: [virtio-dev] Re: [RFC] vhost: introduce mdev based hardware
vhost backend
> From: Liang, Cunming
> Sent: Tuesday, April 10, 2018 10:24 PM
>
[...]
> >
> > As others said, we do not need to go overeboard. A couple of small
> vendor-
> > specific quirks in qemu isn't a big deal.
>
> It's quite challenge to identify it's small or not, there's no uniform metric.
>
> It's only dependent on QEMU itself, that's the obvious benefit. Tradeoff is
> to build the entire device driver. We don't object to do that in QEMU, but
> wanna make sure to understand the boundary size clearly.
>
It might be helpful if you can post some sample code using proposed
framework - then people have a clear feeling about what size is talked
about here and whether it falls into the concept of 'small quirks'.
Thanks
Kevin
Powered by blists - more mailing lists