On Wed, Nov 21, 2018 at 09:44:02PM +0800, Jason Wang wrote:
>
> On 2018/11/21 下午8:10, Michael S. Tsirkin wrote:
> > On Wed, Nov 21, 2018 at 03:35:21PM +0800, Jason Wang wrote:
> > > On 2018/11/21 下午1:11, Michael S. Tsirkin wrote:
> > > > > A question is. Are you suggesting to have
On 2018/11/21 下午8:10, Michael S. Tsirkin wrote:
On Wed, Nov 21, 2018 at 03:35:21PM +0800, Jason Wang wrote:
On 2018/11/21 下午1:11, Michael S. Tsirkin wrote:
A question is. Are you suggesting to have VIRTIO_F_ORDER_PLATFORM for each
hardware implementation?
It's not a simple question. There
On 2018/11/21 下午1:11, Michael S. Tsirkin wrote:
A question is. Are you suggesting to have VIRTIO_F_ORDER_PLATFORM for each
hardware implementation?
It's not a simple question. There are implementations such as
VDPA which have a hardware and a software component.
For a hardware only device
On Wed, Nov 21, 2018 at 12:07:34PM +0800, Jason Wang wrote:
>
> On 2018/11/21 上午11:09, Michael S. Tsirkin wrote:
> > This is an attempt to clarify the intent behind
> > VIRTIO_F_IOMMU_PLATFORM and VIRTIO_F_IO_BARRIER which based on
> > recent discussions appear not to be well documented,
> > in
On 2018/11/21 上午11:09, Michael S. Tsirkin wrote:
This is an attempt to clarify the intent behind
VIRTIO_F_IOMMU_PLATFORM and VIRTIO_F_IO_BARRIER which based on
recent discussions appear not to be well documented,
in particular not matching what drivers do or are
likely to do.
- rename