From: Masami Hiramatsu <masami.hiramatsu@linaro.org>
To: Oleksandr Tyshchenko <olekstysh@gmail.com>
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
"Stefano Stabellini" <sstabellini@kernel.org>,
xen-devel <xen-devel@lists.xenproject.org>,
"Oleksandr Tyshchenko" <oleksandr_tyshchenko@epam.com>,
"Paul Durrant" <paul@xen.org>, "Jan Beulich" <jbeulich@suse.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
"Julien Grall" <julien.grall@arm.com>,
"George Dunlap" <george.dunlap@citrix.com>,
"Ian Jackson" <iwj@xenproject.org>,
"Julien Grall" <julien@xen.org>, "Tim Deegan" <tim@xen.org>,
"Daniel De Graaf" <dgdegra@tycho.nsa.gov>,
"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
"Jun Nakajima" <jun.nakajima@intel.com>,
"Kevin Tian" <kevin.tian@intel.com>,
"Anthony PERARD" <anthony.perard@citrix.com>,
"Bertrand Marquis" <bertrand.marquis@arm.com>
Subject: Re: [PATCH V2 00/23] IOREQ feature (+ virtio-mmio) on Arm
Date: Tue, 3 Nov 2020 23:30:16 +0900 [thread overview]
Message-ID: <CAA93ih3LcHPLbL7dPof-OAbM2HRJv0neQtMuYDYcYAOYDhVbKA@mail.gmail.com> (raw)
In-Reply-To: <CAPD2p-=2UimQy6VHKw1FgyVi2R94Ux_HFdPYk7=FR3KWSEqiHw@mail.gmail.com>
Hi Oleksandr,
Thanks for sharing the virtio-disk server, I also tested with a real usb disk.
In config file:
virtio = 1
vdisk = [ 'backend=Domain-0, disks=ro:/dev/sda1' ]
And it can be mounted in DomU
[ 2.892874] virtio_blk virtio0: [vda] 1875382927 512-byte logical
blocks (960 GB/894 GiB)
[ 2.892925] vda: detected capacity change from 0 to 960196058624
...
root@develbox:~# cat /proc/partitions
major minor #blocks name
254 0 937691463 vda
...
root@develbox:~# mount /dev/vda /mnt/
[ 192.260968] EXT4-fs (vda): mounted filesystem with ordered data
mode. Opts: (null)
mount: /mnt: WARNING: source write-protected, mounted read-only.
So "ro" flag also correctly works.
Great!
Thank you!
2020年11月1日(日) 6:10 Oleksandr Tyshchenko <olekstysh@gmail.com>:
>
>
>
> On Fri, Oct 30, 2020 at 1:34 PM Masami Hiramatsu <masami.hiramatsu@linaro.org> wrote:
>>
>> Hi Oleksandr,
>
>
> Hi Masami, all
>
> [sorry for the possible format issue]
>
>>
>> >> >
>> >> > Could you tell me how can I test it?
>> >> >
>> >> >
>> >> > I assume it is due to the lack of the virtio-disk backend (which I haven't shared yet as I focused on the IOREQ/DM support on Arm in the
>> >> > first place).
>> >> > Could you wait a little bit, I am going to share it soon.
>> >>
>> >> Do you have a quick-and-dirty hack you can share in the meantime? Even
>> >> just on github as a special branch? It would be very useful to be able
>> >> to have a test-driver for the new feature.
>> >
>> > Well, I will provide a branch on github with our PoC virtio-disk backend by the end of this week. It will be possible to test this series with it.
>>
>> Great! OK I'll be waiting for the PoC backend.
>>
>> Thank you!
>
>
> You can find the virtio-disk backend PoC (shared as is) at [1].
>
> Brief description...
>
> The virtio-disk backend PoC is a completely standalone entity (IOREQ server) which emulates a virtio-mmio disk device.
> It is based on code from DEMU [2] (for IOREQ server purposes) and some code from kvmtool [3] to implement virtio protocol,
> disk operations over underlying H/W and Xenbus code to be able to read configuration from the Xenstore
> (it is configured via domain config file). Last patch in this series (marked as RFC) actually adds required bits to the libxl code.
>
> Some notes...
>
> Backend could be used with current V2 IOREQ series [4] without any modifications, all what you need is to enable
> CONFIG_IOREQ_SERVER on Arm [5], since it is disabled by default within this series.
>
> Please note that in our system we run backend in DomD (driver domain). I haven't tested it in Dom0,
> since in our system the Dom0 is thin (without any H/W) and only used to launch VMs, so there is no underlying block H/W.
> But, I hope, it is possible to run it in Dom0 as well (at least there is nothing specific to a particular domain in the backend itself, nothing hardcoded).
> If you are going to run a backend in other than Dom0 domain you need to write your own policy (FLASK) for the backend (running in that domain)
> to be able to issue DM related requests, etc. Only for test purposes you could use this patch [6] that tweeks Xen dummy policy (not for upstream).
>
> As I mentioned elsewhere you don't need to modify Guest Linux (DomU), just enable VirtIO related configs.
> If I remember correctly, the following would be enough:
> CONFIG_BLK_MQ_VIRTIO=y
> CONFIG_VIRTIO_BLK=y
> CONFIG_VIRTIO=y
> CONFIG_VIRTIO_BALLOON=y
> CONFIG_VIRTIO_MMIO=y
> If I remember correctly, if your Host Linux (Dom0 or DomD) version >= 4.17 you don't need to modify it as well.
> Otherwise, you need to cherry-pick "xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE" from the upstream to be able
> to use the acquire interface for the resource mapping.
>
> We usually build a backend in the context of the Yocto build process and run it as a systemd service,
> but you can also build and run it manually (it should be launched before DomU creation).
>
> There are no command line options at all. Everything is configured via domain configuration file:
> # This option is mandatory, it shows that VirtIO is going to be used by guest
> virtio=1
> # Example of domain configuration (two disks are assigned to the guest, the latter is in readonly mode):
> vdisk = [ 'backend=DomD, disks=rw:/dev/mmcblk0p3;ro:/dev/mmcblk1p3' ]
>
> Hope that helps. Feel free to ask questions if any.
>
> [1] https://github.com/xen-troops/virtio-disk/commits/ioreq_v3
> [2] https://xenbits.xen.org/gitweb/?p=people/pauldu/demu.git;a=summary
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git/
> [4] https://github.com/otyshchenko1/xen/commits/ioreq_4.14_ml3
> [5] https://github.com/otyshchenko1/xen/commit/ee221102193f0422a240832edc41d73f6f3da923
> [6] https://github.com/otyshchenko1/xen/commit/be868a63014b7aa6c9731d5692200d7f2f57c611
>
> --
> Regards,
>
> Oleksandr Tyshchenko
--
Masami Hiramatsu
next prev parent reply other threads:[~2020-11-03 14:30 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-15 16:44 [PATCH V2 00/23] IOREQ feature (+ virtio-mmio) on Arm Oleksandr Tyshchenko
2020-10-15 16:44 ` [PATCH V2 01/23] x86/ioreq: Prepare IOREQ feature for making it common Oleksandr Tyshchenko
2020-10-20 7:13 ` Paul Durrant
2020-11-04 9:06 ` Oleksandr
2020-11-04 9:59 ` Paul Durrant
2020-11-12 10:58 ` Jan Beulich
2020-11-13 11:09 ` Oleksandr
2020-11-13 11:20 ` Jan Beulich
2020-11-13 12:45 ` Oleksandr
2020-11-13 14:31 ` Jan Beulich
2020-10-15 16:44 ` [PATCH V2 02/23] xen/ioreq: Make x86's IOREQ feature common Oleksandr Tyshchenko
2020-10-20 7:57 ` Paul Durrant
2020-11-10 16:45 ` Oleksandr
2020-11-17 14:47 ` Oleksandr
2020-11-17 15:29 ` Paul Durrant
2020-11-17 16:29 ` Oleksandr
2020-11-17 19:43 ` Paul Durrant
2020-11-12 11:11 ` Jan Beulich
2020-11-13 13:11 ` Oleksandr
2020-10-15 16:44 ` [PATCH V2 03/23] xen/ioreq: Make x86's hvm_ioreq_needs_completion() common Oleksandr Tyshchenko
2020-10-20 7:59 ` Paul Durrant
2020-10-15 16:44 ` [PATCH V2 04/23] xen/ioreq: Provide alias for the handle_mmio() Oleksandr Tyshchenko
2020-10-20 9:14 ` Paul Durrant
2020-10-20 10:05 ` Jan Beulich
2020-10-20 10:38 ` Paul Durrant
2020-11-10 19:44 ` Oleksandr
2020-11-11 7:27 ` Jan Beulich
2020-11-11 8:09 ` Oleksandr
2020-11-11 8:16 ` Jan Beulich
2020-10-15 16:44 ` [PATCH V2 05/23] xen/ioreq: Make x86's hvm_mmio_first(last)_byte() common Oleksandr Tyshchenko
2020-10-20 9:15 ` Paul Durrant
2020-10-15 16:44 ` [PATCH V2 06/23] xen/ioreq: Make x86's hvm_ioreq_(page/vcpu/server) structs common Oleksandr Tyshchenko
2020-10-15 16:44 ` [PATCH V2 07/23] xen/ioreq: Move x86's ioreq_gfn(server) to struct domain Oleksandr Tyshchenko
2020-11-12 11:21 ` Jan Beulich
2020-11-13 14:05 ` Oleksandr
2020-11-18 12:09 ` Oleksandr
2020-11-18 12:29 ` Paul Durrant
2020-10-15 16:44 ` [PATCH V2 08/23] xen/ioreq: Introduce ioreq_params to abstract accesses to arch.hvm.params Oleksandr Tyshchenko
2020-10-20 10:41 ` Paul Durrant
2020-11-10 20:00 ` Oleksandr
2020-10-15 16:44 ` [PATCH V2 09/23] xen/dm: Make x86's DM feature common Oleksandr Tyshchenko
2020-11-12 11:32 ` Jan Beulich
2020-11-13 14:28 ` Oleksandr
2020-10-15 16:44 ` [PATCH V2 10/23] xen/mm: Make x86's XENMEM_resource_ioreq_server handling common Oleksandr Tyshchenko
2020-11-12 11:40 ` Jan Beulich
2020-11-13 15:00 ` Oleksandr
2020-10-15 16:44 ` [PATCH V2 11/23] xen/ioreq: Move x86's io_completion/io_req fields to struct vcpu Oleksandr Tyshchenko
2020-10-20 10:55 ` Paul Durrant
2020-11-10 20:59 ` Oleksandr
2020-11-11 8:04 ` Jan Beulich
2020-11-11 8:14 ` Oleksandr
2020-10-15 16:44 ` [PATCH V2 12/23] xen/ioreq: Remove "hvm" prefixes from involved function names Oleksandr Tyshchenko
2020-11-12 11:45 ` Jan Beulich
2020-11-12 12:14 ` Paul Durrant
2020-11-13 15:53 ` Oleksandr
2020-11-23 14:39 ` Oleksandr
2020-11-23 14:56 ` Jan Beulich
2020-11-23 15:47 ` Oleksandr
2020-11-23 15:54 ` Paul Durrant
2020-11-23 16:36 ` Oleksandr
2020-10-15 16:44 ` [PATCH V2 13/23] xen/ioreq: Use guest_cmpxchg64() instead of cmpxchg() Oleksandr Tyshchenko
2020-10-15 16:44 ` [PATCH V2 14/23] arm/ioreq: Introduce arch specific bits for IOREQ/DM features Oleksandr Tyshchenko
2020-11-12 11:48 ` Jan Beulich
2020-11-13 15:48 ` Oleksandr
2020-10-15 16:44 ` [PATCH V2 15/23] xen/arm: Stick around in leave_hypervisor_to_guest until I/O has completed Oleksandr Tyshchenko
2020-10-15 16:44 ` [PATCH V2 16/23] xen/mm: Handle properly reference in set_foreign_p2m_entry() on Arm Oleksandr Tyshchenko
2020-11-12 12:18 ` Jan Beulich
2020-11-13 17:00 ` Oleksandr
2020-10-15 16:44 ` [PATCH V2 17/23] xen/ioreq: Introduce domain_has_ioreq_server() Oleksandr Tyshchenko
2020-10-20 10:51 ` Paul Durrant
2020-11-10 20:53 ` Oleksandr
2020-11-11 8:08 ` Jan Beulich
2020-11-11 8:41 ` Oleksandr
2020-11-11 13:27 ` Jan Beulich
2020-11-11 16:28 ` Paul Durrant
2020-11-11 17:33 ` Oleksandr
2020-11-11 17:31 ` Oleksandr
2020-10-15 16:44 ` [PATCH V2 18/23] xen/dm: Introduce xendevicemodel_set_irq_level DM op Oleksandr Tyshchenko
2020-10-15 16:44 ` [PATCH V2 19/23] xen/arm: io: Abstract sign-extension Oleksandr Tyshchenko
2020-10-15 16:44 ` [PATCH V2 20/23] xen/ioreq: Make x86's send_invalidate_req() common Oleksandr Tyshchenko
2020-11-12 11:55 ` Jan Beulich
2020-11-13 16:03 ` Oleksandr
2020-10-15 16:44 ` [PATCH V2 21/23] xen/arm: Add mapcache invalidation handling Oleksandr Tyshchenko
2020-10-16 6:29 ` Jan Beulich
2020-10-16 8:41 ` Julien Grall
2020-10-16 8:56 ` Jan Beulich
2020-11-11 0:03 ` Oleksandr
2020-11-11 19:27 ` Julien Grall
2020-11-11 19:42 ` Oleksandr
2020-10-15 16:44 ` [PATCH V2 22/23] libxl: Introduce basic virtio-mmio support on Arm Oleksandr Tyshchenko
2020-10-15 16:44 ` [PATCH V2 23/23] [RFC] libxl: Add support for virtio-disk configuration Oleksandr Tyshchenko
2020-11-09 6:45 ` Wei Chen
2020-11-11 0:53 ` Oleksandr
2020-11-11 4:28 ` Wei Chen
2020-11-13 17:38 ` Oleksandr
2020-10-29 7:41 ` [PATCH V2 00/23] IOREQ feature (+ virtio-mmio) on Arm Masami Hiramatsu
2020-10-29 18:48 ` Oleksandr Tyshchenko
2020-10-29 19:53 ` Stefano Stabellini
2020-10-29 21:13 ` Oleksandr Tyshchenko
2020-10-29 21:34 ` Stefano Stabellini
2020-10-30 11:34 ` Masami Hiramatsu
2020-10-31 21:10 ` Oleksandr Tyshchenko
2020-11-02 7:23 ` Wei Chen
2020-11-02 18:05 ` Oleksandr
2020-11-03 14:30 ` Masami Hiramatsu [this message]
2020-11-03 21:09 ` Oleksandr
2020-10-29 20:03 ` Alex Bennée
2020-10-29 20:10 ` Stefano Stabellini
2020-10-29 22:06 ` Oleksandr Tyshchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA93ih3LcHPLbL7dPof-OAbM2HRJv0neQtMuYDYcYAOYDhVbKA@mail.gmail.com \
--to=masami.hiramatsu@linaro.org \
--cc=Volodymyr_Babchuk@epam.com \
--cc=alex.bennee@linaro.org \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@citrix.com \
--cc=bertrand.marquis@arm.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=george.dunlap@citrix.com \
--cc=iwj@xenproject.org \
--cc=jbeulich@suse.com \
--cc=julien.grall@arm.com \
--cc=julien@xen.org \
--cc=jun.nakajima@intel.com \
--cc=kevin.tian@intel.com \
--cc=oleksandr_tyshchenko@epam.com \
--cc=olekstysh@gmail.com \
--cc=paul@xen.org \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=tim@xen.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).