Re: [Qemu-devel] [RFC PATCH 0/7] virtio-fs: shared file system for virtual machines3

[jiangyiwen]

On 2018/12/27 3:08, Vivek Goyal wrote:
> On Sat, Dec 22, 2018 at 05:27:28PM +0800, jiangyiwen wrote:
>> On 2018/12/11 1:31, Dr. David Alan Gilbert (git) wrote:
>>> From: "Dr. David Alan Gilbert" 
>>>
>>> Hi,
>>>   This is the first RFC for the QEMU side of 'virtio-fs';
>>> a new mechanism for mounting host directories into the guest
>>> in a fast, consistent and secure manner.  Our primary use
>>> case is kata containers, but it should be usable in other scenarios
>>> as well.
>>>
>>> There are corresponding patches being posted to Linux kernel,
>>> libfuse and kata lists.
>>>
>>> For a fuller design description, and benchmark numbers, please see
>>> Vivek's posting of the kernel set here:
>>>
>>> https://marc.info/?l=linux-kernel=154446243024251=2
>>>
>>> We've got a small website with instructions on how to use it, here:
>>>
>>> https://virtio-fs.gitlab.io/
>>>
>>> and all the code is available on gitlab at:
>>>
>>> https://gitlab.com/virtio-fs
>>>
>>> QEMU's changes
>>> --
>>>
>>> The QEMU changes are pretty small; 
>>>
>>> There's a new vhost-user device, which is used to carry a stream of
>>> FUSE messages to an external daemon that actually performs
>>> all the file IO.  The FUSE daemon is an external process in order to
>>> achieve better isolation for security and resource control (e.g. number
>>> of file descriptors) and also because it's cleaner than trying to
>>> integrate libfuse into QEMU.
>>>
>>> This device has an extra BAR that contains (up to) 3 regions:
>>>
>>>  a) a DAX mapping range ('the cache') - into which QEMU mmap's
>>> files on behalf of the external daemon; those files are
>>> then directly mapped by the guest in a way similar to a DAX
>>> backed file system;  one advantage of this is that multiple
>>> guests all accessing the same files should all be sharing
>>> those pages of host cache.
>>>
>>>  b) An experimental set of mappings for use by a metadata versioning
>>> daemon;  this mapping is shared between multiple guests and
>>> the daemon, but only contains a set of version counters that
>>> allow a guest to quickly tell if its metadata is stale.
>>>
>>> TODO
>>> 
>>>
>>> This is the first RFC, we know we have a bunch of things to clear up:
>>>
>>>   a) The virtio device specificiation is still in flux and is expected
>>>  to change
>>>
>>>   b) We'd like to find ways of reducing the map/unmap latency for DAX
>>>
>>>   c) The metadata versioning scheme needs to settle out.
>>>
>>>   d) mmap'ing host files has some interesting side effects; for example
>>>  if the file gets truncated by the host and then the guest accesses
>>>  the mapping, KVM can fail the guest hard.
>>>
>>> Dr. David Alan Gilbert (6):
>>>   virtio: Add shared memory capability
>>>   virtio-fs: Add cache BAR
>>>   virtio-fs: Add vhost-user slave commands for mapping
>>>   virtio-fs: Fill in slave commands for mapping
>>>   virtio-fs: Allow mapping of meta data version table
>>>   virtio-fs: Allow mapping of journal
>>>
>>> Stefan Hajnoczi (1):
>>>   virtio: add vhost-user-fs-pci device
>>>
>>>  configure   |  10 +
>>>  contrib/libvhost-user/libvhost-user.h   |   3 +
>>>  docs/interop/vhost-user.txt |  35 ++
>>>  hw/virtio/Makefile.objs |   1 +
>>>  hw/virtio/vhost-user-fs.c   | 517 
>>>  hw/virtio/vhost-user.c  |  16 +
>>>  hw/virtio/virtio-pci.c  | 115 +
>>>  hw/virtio/virtio-pci.h  |  19 +
>>>  include/hw/pci/pci.h|   1 +
>>>  include/hw/virtio/vhost-user-fs.h   |  79 +++
>>>  include/standard-headers/linux/virtio_fs.h  |  48 ++
>>>  include/standard-headers/linux/virtio_ids.h |   1 +
>>>  include/standard-headers/linux/virtio_pci.h |   9 +
>>>  13 files changed, 854 insertions(+)
>>>  create mode 100644 hw/virtio/vhost-user-fs.c
>>>  create mode 100644 include/hw/virtio/vhost-user-fs.h
>>>  create mode 100644 include/standard-headers/linux/virtio_fs.h
>>>
>>
>> Hi Dave,
>>
>> I encounter a problem after running qemu with virtio-fs,
>>
>> I find I only can mount virtio-fs using the following command:
>> mount -t virtio_fs /dev/null /mnt/virtio_fs/ -o 
>> tag=myfs,rootmode=04,user_id=0,group_id=0
>> or mount -t virtio_fs /dev/null /mnt/virtio_fs/ -o 
>> tag=myfs,rootmode=04,user_id=0,group_id=0,dax
>>
>> Then, I want to know how to use "cache=always" or "cache=none", even 
>> "cache=auto", "cache=writeback"?
>>
>> Thanks,
>> Yiwen.
> 
> Hi Yiwen,
> 
> As of now, cache options are libfuse daemon options. So while starting
> daemon, specify "-o cache=none" or "-o cache=always" etc. One can not
> specify caching option at virtio-fs mount time.
> 
> Thanks
> Vivek
> 
> .
> 

Ok, I get it, thanks.

Yiwen.

Re: [Qemu-devel] [RFC PATCH 0/7] virtio-fs: shared file system for virtual machines3

[jiangyiwen]

On 2018/12/11 1:31, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" 
> 
> Hi,
>   This is the first RFC for the QEMU side of 'virtio-fs';
> a new mechanism for mounting host directories into the guest
> in a fast, consistent and secure manner.  Our primary use
> case is kata containers, but it should be usable in other scenarios
> as well.
> 
> There are corresponding patches being posted to Linux kernel,
> libfuse and kata lists.
> 
> For a fuller design description, and benchmark numbers, please see
> Vivek's posting of the kernel set here:
> 
> https://marc.info/?l=linux-kernel=154446243024251=2
> 
> We've got a small website with instructions on how to use it, here:
> 
> https://virtio-fs.gitlab.io/
> 
> and all the code is available on gitlab at:
> 
> https://gitlab.com/virtio-fs
> 
> QEMU's changes
> --
> 
> The QEMU changes are pretty small; 
> 
> There's a new vhost-user device, which is used to carry a stream of
> FUSE messages to an external daemon that actually performs
> all the file IO.  The FUSE daemon is an external process in order to
> achieve better isolation for security and resource control (e.g. number
> of file descriptors) and also because it's cleaner than trying to
> integrate libfuse into QEMU.
> 
> This device has an extra BAR that contains (up to) 3 regions:
> 
>  a) a DAX mapping range ('the cache') - into which QEMU mmap's
> files on behalf of the external daemon; those files are
> then directly mapped by the guest in a way similar to a DAX
> backed file system;  one advantage of this is that multiple
> guests all accessing the same files should all be sharing
> those pages of host cache.
> 
>  b) An experimental set of mappings for use by a metadata versioning
> daemon;  this mapping is shared between multiple guests and
> the daemon, but only contains a set of version counters that
> allow a guest to quickly tell if its metadata is stale.
> 
> TODO
> 
> 
> This is the first RFC, we know we have a bunch of things to clear up:
> 
>   a) The virtio device specificiation is still in flux and is expected
>  to change
> 
>   b) We'd like to find ways of reducing the map/unmap latency for DAX
> 
>   c) The metadata versioning scheme needs to settle out.
> 
>   d) mmap'ing host files has some interesting side effects; for example
>  if the file gets truncated by the host and then the guest accesses
>  the mapping, KVM can fail the guest hard.
> 
> Dr. David Alan Gilbert (6):
>   virtio: Add shared memory capability
>   virtio-fs: Add cache BAR
>   virtio-fs: Add vhost-user slave commands for mapping
>   virtio-fs: Fill in slave commands for mapping
>   virtio-fs: Allow mapping of meta data version table
>   virtio-fs: Allow mapping of journal
> 
> Stefan Hajnoczi (1):
>   virtio: add vhost-user-fs-pci device
> 
>  configure   |  10 +
>  contrib/libvhost-user/libvhost-user.h   |   3 +
>  docs/interop/vhost-user.txt |  35 ++
>  hw/virtio/Makefile.objs |   1 +
>  hw/virtio/vhost-user-fs.c   | 517 
>  hw/virtio/vhost-user.c  |  16 +
>  hw/virtio/virtio-pci.c  | 115 +
>  hw/virtio/virtio-pci.h  |  19 +
>  include/hw/pci/pci.h|   1 +
>  include/hw/virtio/vhost-user-fs.h   |  79 +++
>  include/standard-headers/linux/virtio_fs.h  |  48 ++
>  include/standard-headers/linux/virtio_ids.h |   1 +
>  include/standard-headers/linux/virtio_pci.h |   9 +
>  13 files changed, 854 insertions(+)
>  create mode 100644 hw/virtio/vhost-user-fs.c
>  create mode 100644 include/hw/virtio/vhost-user-fs.h
>  create mode 100644 include/standard-headers/linux/virtio_fs.h
> 

Hi Dave,

I encounter a problem after running qemu with virtio-fs,

I find I only can mount virtio-fs using the following command:
mount -t virtio_fs /dev/null /mnt/virtio_fs/ -o 
tag=myfs,rootmode=04,user_id=0,group_id=0
or mount -t virtio_fs /dev/null /mnt/virtio_fs/ -o 
tag=myfs,rootmode=04,user_id=0,group_id=0,dax

Then, I want to know how to use "cache=always" or "cache=none", even 
"cache=auto", "cache=writeback"?

Thanks,
Yiwen.

Re: [Qemu-devel] [PATCH] vhost-vsock: support parse mergeable feature

[jiangyiwen]

On 2018/12/13 23:34, Stefan Hajnoczi wrote:
> On Thu, Dec 13, 2018 at 11:27:24AM +0800, jiangyiwen wrote:
>> On 2018/12/12 21:19, Michael S. Tsirkin wrote:
>>> On Wed, Dec 12, 2018 at 05:54:49PM +0800, jiangyiwen wrote:
>>>> Currently vhost-vsock doesn't have any feature bits, so it
>>>> don't support parse mergeable rx buffer feature. And the
>>>> feature is support in another series of patches named
>>>> "VSOCK: support mergeable rx buffer in vhost-vsock".
>>>>
>>>> So we neet to support parse mergeable feature in vhost-vsock
>>>> if above patches are merged.
>>>>
>>>> Signed-off-by: Yiwen Jiang 
>>>
>>> OK but what does it do? this just defines the feature bit ...
>>> Also pls copy virtio-dev whenever you change the host/guest
>>> interface.
>>>
>>> Thanks!
>>>
>>
>> Hi Michael,
>>
>> In my opinion, for vhost device, device feature bits need to be
>> intersected between vhost and qemu, so I add mergeable rx buffer feature
>> into vdev->host_features, and then intersected with vhost_dev features.
>>
>> Later if someone want to add new feature, it can use virtio_add_feature()
>> in vhost_vsock_get_features().
> 
> Hi Yiwen,
> I think Michael's comment is about documenting the behavior of the new
> feature bit.
> 
> Each change to a VIRTIO device host<->guest interface needs to be
> discussed in the VIRTIO community  and
> described in a patch to the VIRTIO specification
> (https://github.com/oasis-tcs/virtio-spec/).
> 
> Stefan
> 

Hi Stefan,

Ok, I will fix it in the later version, I have not sent
a series of patches before, thank you for your help.

Thanks again,
Yiwen.

Re: [Qemu-devel] [PATCH] vhost-vsock: support parse mergeable feature

[jiangyiwen]

On 2018/12/13 22:54, Michael S. Tsirkin wrote:
> On Thu, Dec 13, 2018 at 11:27:24AM +0800, jiangyiwen wrote:
>> On 2018/12/12 21:19, Michael S. Tsirkin wrote:
>>> On Wed, Dec 12, 2018 at 05:54:49PM +0800, jiangyiwen wrote:
>>>> Currently vhost-vsock doesn't have any feature bits, so it
>>>> don't support parse mergeable rx buffer feature. And the
>>>> feature is support in another series of patches named
>>>> "VSOCK: support mergeable rx buffer in vhost-vsock".
>>>>
>>>> So we neet to support parse mergeable feature in vhost-vsock
>>>> if above patches are merged.
>>>>
>>>> Signed-off-by: Yiwen Jiang 
>>>
>>> OK but what does it do? this just defines the feature bit ...
>>> Also pls copy virtio-dev whenever you change the host/guest
>>> interface.
>>>
>>> Thanks!
>>>
>>
>> Hi Michael,
>>
>> In my opinion, for vhost device, device feature bits need to be
>> intersected between vhost and qemu, so I add mergeable rx buffer feature
>> into vdev->host_features, and then intersected with vhost_dev features.
>>
>> Later if someone want to add new feature, it can use virtio_add_feature()
>> in vhost_vsock_get_features().
>>
>> Thanks,
>> Yiwen.
> 
> I understand. Sorry.  It seems that your patchset wasn't threaded
> properly, each patch was by its own. Can you pls take a look at fixing
> that?
> 

Hi Michael,

Thanks your suggestions, I want to how to send patch when
patch involving multiple communities, like qemu
and linux kernel. In this case, how should we send them?

Thanks,
Yiwen.

>>>> ---
>>>>  hw/virtio/vhost-vsock.c   | 9 +++--
>>>>  include/standard-headers/linux/virtio_vsock.h | 3 +++
>>>>  2 files changed, 10 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/hw/virtio/vhost-vsock.c b/hw/virtio/vhost-vsock.c
>>>> index aa5af92..5023c05 100644
>>>> --- a/hw/virtio/vhost-vsock.c
>>>> +++ b/hw/virtio/vhost-vsock.c
>>>> @@ -178,8 +178,13 @@ static uint64_t vhost_vsock_get_features(VirtIODevice 
>>>> *vdev,
>>>>   uint64_t requested_features,
>>>>   Error **errp)
>>>>  {
>>>> -/* No feature bits used yet */
>>>> -return requested_features;
>>>> +VHostVSock *vsock = VHOST_VSOCK(vdev);
>>>> +uint64_t features;
>>>> +
>>>> +virtio_add_feature(_features, VIRTIO_VSOCK_F_MRG_RXBUF);
>>>> +features = requested_features & vsock->vhost_dev.features;
>>>> +
>>>> +return features;
>>>>  }
>>>>
>>>>  static void vhost_vsock_handle_output(VirtIODevice *vdev, VirtQueue *vq)
>>>> diff --git a/include/standard-headers/linux/virtio_vsock.h 
>>>> b/include/standard-headers/linux/virtio_vsock.h
>>>> index be44321..4c583ec 100644
>>>> --- a/include/standard-headers/linux/virtio_vsock.h
>>>> +++ b/include/standard-headers/linux/virtio_vsock.h
>>>> @@ -38,6 +38,9 @@
>>>>  #include "standard-headers/linux/virtio_ids.h"
>>>>  #include "standard-headers/linux/virtio_config.h"
>>>>
>>>> +/* Virtio-vsock feature */
>>>> +#define VIRTIO_VSOCK_F_MRG_RXBUF 0 /* Host can merge receive buffers. */
>>>> +
>>>>  struct virtio_vsock_config {
>>>>uint64_t guest_cid;
>>>>  } QEMU_PACKED;
>>>> -- 
>>>> 1.8.3.1
>>>>
>>>
>>> .
>>>
>>
> 
> .
> 

Re: [Qemu-devel] [PATCH] vhost-vsock: support parse mergeable feature

[jiangyiwen]

On 2018/12/12 21:19, Michael S. Tsirkin wrote:
> On Wed, Dec 12, 2018 at 05:54:49PM +0800, jiangyiwen wrote:
>> Currently vhost-vsock doesn't have any feature bits, so it
>> don't support parse mergeable rx buffer feature. And the
>> feature is support in another series of patches named
>> "VSOCK: support mergeable rx buffer in vhost-vsock".
>>
>> So we neet to support parse mergeable feature in vhost-vsock
>> if above patches are merged.
>>
>> Signed-off-by: Yiwen Jiang 
> 
> OK but what does it do? this just defines the feature bit ...
> Also pls copy virtio-dev whenever you change the host/guest
> interface.
> 
> Thanks!
> 

Hi Michael,

In my opinion, for vhost device, device feature bits need to be
intersected between vhost and qemu, so I add mergeable rx buffer feature
into vdev->host_features, and then intersected with vhost_dev features.

Later if someone want to add new feature, it can use virtio_add_feature()
in vhost_vsock_get_features().

Thanks,
Yiwen.

>> ---
>>  hw/virtio/vhost-vsock.c   | 9 +++--
>>  include/standard-headers/linux/virtio_vsock.h | 3 +++
>>  2 files changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/virtio/vhost-vsock.c b/hw/virtio/vhost-vsock.c
>> index aa5af92..5023c05 100644
>> --- a/hw/virtio/vhost-vsock.c
>> +++ b/hw/virtio/vhost-vsock.c
>> @@ -178,8 +178,13 @@ static uint64_t vhost_vsock_get_features(VirtIODevice 
>> *vdev,
>>   uint64_t requested_features,
>>   Error **errp)
>>  {
>> -/* No feature bits used yet */
>> -return requested_features;
>> +VHostVSock *vsock = VHOST_VSOCK(vdev);
>> +uint64_t features;
>> +
>> +virtio_add_feature(_features, VIRTIO_VSOCK_F_MRG_RXBUF);
>> +features = requested_features & vsock->vhost_dev.features;
>> +
>> +return features;
>>  }
>>
>>  static void vhost_vsock_handle_output(VirtIODevice *vdev, VirtQueue *vq)
>> diff --git a/include/standard-headers/linux/virtio_vsock.h 
>> b/include/standard-headers/linux/virtio_vsock.h
>> index be44321..4c583ec 100644
>> --- a/include/standard-headers/linux/virtio_vsock.h
>> +++ b/include/standard-headers/linux/virtio_vsock.h
>> @@ -38,6 +38,9 @@
>>  #include "standard-headers/linux/virtio_ids.h"
>>  #include "standard-headers/linux/virtio_config.h"
>>
>> +/* Virtio-vsock feature */
>> +#define VIRTIO_VSOCK_F_MRG_RXBUF 0 /* Host can merge receive buffers. */
>> +
>>  struct virtio_vsock_config {
>>  uint64_t guest_cid;
>>  } QEMU_PACKED;
>> -- 
>> 1.8.3.1
>>
> 
> .
> 

[Qemu-devel] [PATCH] vhost-vsock: support parse mergeable feature

[jiangyiwen]

Currently vhost-vsock doesn't have any feature bits, so it
don't support parse mergeable rx buffer feature. And the
feature is support in another series of patches named
"VSOCK: support mergeable rx buffer in vhost-vsock".

So we neet to support parse mergeable feature in vhost-vsock
if above patches are merged.

Signed-off-by: Yiwen Jiang 
---
 hw/virtio/vhost-vsock.c   | 9 +++--
 include/standard-headers/linux/virtio_vsock.h | 3 +++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/hw/virtio/vhost-vsock.c b/hw/virtio/vhost-vsock.c
index aa5af92..5023c05 100644
--- a/hw/virtio/vhost-vsock.c
+++ b/hw/virtio/vhost-vsock.c
@@ -178,8 +178,13 @@ static uint64_t vhost_vsock_get_features(VirtIODevice 
*vdev,
  uint64_t requested_features,
  Error **errp)
 {
-/* No feature bits used yet */
-return requested_features;
+VHostVSock *vsock = VHOST_VSOCK(vdev);
+uint64_t features;
+
+virtio_add_feature(_features, VIRTIO_VSOCK_F_MRG_RXBUF);
+features = requested_features & vsock->vhost_dev.features;
+
+return features;
 }

 static void vhost_vsock_handle_output(VirtIODevice *vdev, VirtQueue *vq)
diff --git a/include/standard-headers/linux/virtio_vsock.h 
b/include/standard-headers/linux/virtio_vsock.h
index be44321..4c583ec 100644
--- a/include/standard-headers/linux/virtio_vsock.h
+++ b/include/standard-headers/linux/virtio_vsock.h
@@ -38,6 +38,9 @@
 #include "standard-headers/linux/virtio_ids.h"
 #include "standard-headers/linux/virtio_config.h"

+/* Virtio-vsock feature */
+#define VIRTIO_VSOCK_F_MRG_RXBUF 0 /* Host can merge receive buffers. */
+
 struct virtio_vsock_config {
uint64_t guest_cid;
 } QEMU_PACKED;
-- 
1.8.3.1

[Qemu-devel] [RFC] About 9pfs support "O_DIRECT + aio"?

[jiangyiwen]

Hi everyone,

Currently, I found virtio-9p in VirtFS don't support "O_DIRECT + aio"
mode, both v9fs and qemu. So when user use "O_DIRECT + aio" mode and
increase iodepths, they can't get higher IOPS.

I want to know why v9fs don't implement this mode? And I will try to
implement this mode from now on.

Thanks,
Yiwen.

Re: [Qemu-devel] [V9fs-developer] [RFC] we should solve create-unlink-getattr idiom

[jiangyiwen]

On 2018/2/9 19:33, Greg Kurz wrote:
> On Fri, 9 Feb 2018 15:10:46 +0800
> jiangyiwen <jiangyi...@huawei.com> wrote:
> 
>> Hi Eric and Greg,
>>
>> I encountered the similar problem with create-unlink-getattr idiom.
>> I use the testcase that create-unlink-setattr idiom, and I see the
>> bug is reported at https://bugs.launchpad.net/qemu/+bug/1336794.
>> Then I also see you already fix the issue and push the patch to upstream.
>> https://github.com/ericvh/linux/commit/eaf70223eac094291169f5a6de580351890162a2
>> http://patchwork.ozlabs.org/patch/626194/
>>
>> Unfortunately, the two patches are not merged into master, I don't know
>> the reason, so I suggest if the patche can be merged into master, and
>> it will solve the create-unlink-getattr idiom.
>>
> 
> I had tried to go a bit further and address the general issue of f*() syscalls
> versus unlinked files:
> 
> QEMU:
> http://lists.gnu.org/archive/html/qemu-devel/2016-06/msg07586.html
> 
> Linux 9p driver:
> https://sourceforge.net/p/v9fs/mailman/message/35175775/
> 
> I remember that some issues were then reported during review of the
> linux patches, and I never got bandwidth to investigate further...
> 
> But if you'd like to resurrect these threads, please do. :)
> 
>> Thanks,
>> Yiwen
>>
> 
> Cheers,
> 
> --
> Greg
> 
> .
> 
Thanks Greg,

Ok, we will move forward, I hope we can solve these problems that you
encountered.

Thanks,
Yiwen.

[Qemu-devel] [V9fs-developer] [RFC] we should solve create-unlink-getattr idiom

[jiangyiwen]

Hi Eric and Greg,

I encountered the similar problem with create-unlink-getattr idiom.
I use the testcase that create-unlink-setattr idiom, and I see the
bug is reported at https://bugs.launchpad.net/qemu/+bug/1336794.
Then I also see you already fix the issue and push the patch to upstream.
https://github.com/ericvh/linux/commit/eaf70223eac094291169f5a6de580351890162a2
http://patchwork.ozlabs.org/patch/626194/

Unfortunately, the two patches are not merged into master, I don't know
the reason, so I suggest if the patche can be merged into master, and
it will solve the create-unlink-getattr idiom.

Thanks,
Yiwen

Re: [Qemu-devel] [PATCH] 9pfs: don't ignore O_DIRECT flag in the 9pfs server

[jiangyiwen]

On 2017/11/20 18:13, Greg Kurz wrote:
> On Mon, 20 Nov 2017 13:48:59 +0800
> jiangyiwen <jiangyi...@huawei.com> wrote:
> 
>> Now v9fs in linux has already supported O_DIRECT(v9fs_direct_IO),
>> when guest user open file with O_DIRECT flag and return success,
>> so user hopes data doesn't pass through page cache, but 9pfs in
>> qemu ignore direct disk access and use host page cache, it is not
>> match to DIRECT_IO semantic, so we should not ignore O_DIRECT in
>> 9pfs unless v9fs in linux don't support DIRECT_IO.
>>
>> And if server fs don't support O_DIRECT, user will receive -EINVAL
>> and know the filesystem don't support O_DIRECT.
>>
>> So in order to ensure semantic consistency, don't ignore direct
>> disk access in 9pfs.
>>
> 
> There are good reasons for us to ignore O_DIRECT. AFAIK, O_DIRECT requires
> the application to take care of the alignment of the buffers with either the
> logical block size of the filesystem (linux <= 2.4) or the logical block size
> of the underlying storage... I don't really see how you can achieve that since
> the linux 9p client only cares to break up requests into msize-chunks, and
> ignores alignment. ie, you're likely to not ensure semantic consistency on the
> host side anyway and linux will fallback to cached I/O.
> 
> Also, this change would silently break existing users of O_DIRECT, which isn't
> acceptable... it would require some fsdev property to enable this new 
> behavior.
> 

Thank you very much, I understand what your mean, v9fs in linux doesn't take 
care
of the alignment, only split as the msize. Then there is another problem,
should v9fs support DIRECT_IO? or delete DIRECT_IO ops in v9fs?

Thanks,
Yiwen.
>> Signed-off-by: Yiwen Jiang <jiangyi...@huawei.com>
>> ---
>>  hw/9pfs/9p.c | 4 
>>  1 file changed, 4 deletions(-)
>>
>> diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
>> index 52d4663..5ea01c4 100644
>> --- a/hw/9pfs/9p.c
>> +++ b/hw/9pfs/9p.c
>> @@ -155,10 +155,6 @@ static int get_dotl_openflags(V9fsState *s, int oflags)
>>   */
>>  flags = dotl_to_open_flags(oflags);
>>  flags &= ~(O_NOCTTY | O_ASYNC | O_CREAT);
>> -/*
>> - * Ignore direct disk access hint until the server supports it.
>> - */
>> -flags &= ~O_DIRECT;
>>  return flags;
>>  }
>>
> 
> 
> .
> 

[Qemu-devel] [PATCH] 9pfs: don't ignore O_DIRECT flag in the 9pfs server

[jiangyiwen]

Now v9fs in linux has already supported O_DIRECT(v9fs_direct_IO),
when guest user open file with O_DIRECT flag and return success,
so user hopes data doesn't pass through page cache, but 9pfs in
qemu ignore direct disk access and use host page cache, it is not
match to DIRECT_IO semantic, so we should not ignore O_DIRECT in
9pfs unless v9fs in linux don't support DIRECT_IO.

And if server fs don't support O_DIRECT, user will receive -EINVAL
and know the filesystem don't support O_DIRECT.

So in order to ensure semantic consistency, don't ignore direct
disk access in 9pfs.

Signed-off-by: Yiwen Jiang 
---
 hw/9pfs/9p.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index 52d4663..5ea01c4 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -155,10 +155,6 @@ static int get_dotl_openflags(V9fsState *s, int oflags)
  */
 flags = dotl_to_open_flags(oflags);
 flags &= ~(O_NOCTTY | O_ASYNC | O_CREAT);
-/*
- * Ignore direct disk access hint until the server supports it.
- */
-flags &= ~O_DIRECT;
 return flags;
 }

-- 

[Qemu-devel] [PATCH] Don't ignore O_DIRECT flag in the 9pfs server

[jiangyiwen]

Now v9fs in linux has already supported O_DIRECT(v9fs_direct_IO),
when guest user open file with O_DIRECT flag and return success,
so user hopes data doesn't pass through page cache, but 9pfs in
qemu ignore direct disk access and use host page cache, it is not
match to DIRECT_IO semantic, so we should not ignore O_DIRECT in
9pfs unless v9fs in linux don't support DIRECT_IO.

And if server fs don't support O_DIRECT, user will receive -EINVAL
and know the filesystem don't support O_DIRECT.

So in order to ensure semantic consistency, don't ignore direct
disk access in 9pfs.

Signed-off-by: Yiwen Jiang 
---
 hw/9pfs/9p.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index 52d4663..5ea01c4 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -155,10 +155,6 @@ static int get_dotl_openflags(V9fsState *s, int oflags)
  */
 flags = dotl_to_open_flags(oflags);
 flags &= ~(O_NOCTTY | O_ASYNC | O_CREAT);
-/*
- * Ignore direct disk access hint until the server supports it.
- */
-flags &= ~O_DIRECT;
 return flags;
 }

-- 
1.8.3.1