+xen-devel
On 14-04-22, 14:45, Viresh Kumar wrote:
> Hello,
>
> We verified our hypervisor-agnostic Rust based vhost-user backends with Qemu
> based setup earlier, and there was growing concern if they were truly
> hypervisor-agnostic.
>
> In order to prove that, we dec
+rust-...@lists.opendev.org
On Thu, 14 Apr 2022 at 14:54, Viresh Kumar wrote:
>
> +xen-devel
>
> On 14-04-22, 14:45, Viresh Kumar wrote:
> > Hello,
> >
> > We verified our hypervisor-agnostic Rust based vhost-user backends with Qemu
> > based setup earlier, a
" are just written to the
Xenstore.
Signed-off-by: Viresh Kumar
---
tools/golang/xenlight/helpers.gen.go | 108 +++
tools/golang/xenlight/types.gen.go| 27 +++
tools/include/libxl.h | 32 +++
tools/include/libxl_utils.h |
1->V2:
- Patches 3/6 and 4/6 are new.
- Patches 5/6 and 6/6 updated based on the above two patches.
- Added link to the bindings for I2C and GPIO.
- Rebased over latest master branch.
Thanks.
--
Viresh
[1]
https://lore.kernel.org/xen-devel/20220414092358.kepxbmnrtycz7mhe@vireshk-i7/
Viresh
Create a separate routine to allocate base and irq for a device as the
same code will be required for each device type.
Suggested-by: Oleksandr Tyshchenko
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 38
1 file changed, 25 insertions
" are just written to the
Xenstore.
Signed-off-by: Viresh Kumar
---
tools/golang/xenlight/helpers.gen.go | 108 ++-
tools/golang/xenlight/types.gen.go| 27 +++
tools/include/libxl.h | 32 +++
tools/include/libxl_utils.h |
o create a simple DT node.
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 2f64b9f0ebee..6a8c4d042bd9 100644
--- a/tools/
This patch allocates Virtio MMIO params (IRQ and memory region) and pass
them to the backend, also update Guest device-tree based on Virtio I2C
DT bindings [1].
[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/i2c/i2c-virtio.yaml
Signed-off-by: Viresh Kumar
---
tools/libs
This patch allocates Virtio MMIO params (IRQ and memory region) and pass
them to the backend, also update Guest device-tree based on Virtio GPIO
DT bindings [1].
[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio-virtio.yaml
Signed-off-by: Viresh Kumar
---
tools/libs
On 08-08-22, 21:39, Oleksandr wrote:
>
> On 04.08.22 10:01, Viresh Kumar wrote:
>
> Hello Viresh
>
>
> > Create a separate routine to allocate base and irq for a device as the
> > same code will be required for each device type.
> >
> > Suggested-b
" are just written to the
Xenstore.
Signed-off-by: Viresh Kumar
---
tools/golang/xenlight/helpers.gen.go | 108 +++
tools/golang/xenlight/types.gen.go| 27 +++
tools/include/libxl.h | 32 +++
tools/include/libxl_utils.h |
" are just written to the
Xenstore.
Signed-off-by: Viresh Kumar
---
tools/golang/xenlight/helpers.gen.go | 108 ++-
tools/golang/xenlight/types.gen.go| 27 +++
tools/include/libxl.h | 32 +++
tools/include/libxl_utils.h |
Create a separate routine to allocate base and irq for a device as the
same code will be required for each device type.
Suggested-by: Oleksandr Tyshchenko
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 41 +++-
1 file changed, 26 insertions
o create a simple DT node.
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 4a750852b671..891cb6ef2674 100644
--- a/tools/
This patch allocates Virtio MMIO params (IRQ and memory region) and pass
them to the backend, also update Guest device-tree based on Virtio I2C
DT bindings [1].
[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/i2c/i2c-virtio.yaml
Signed-off-by: Viresh Kumar
---
tools/libs
This patch allocates Virtio MMIO params (IRQ and memory region) and pass
them to the backend, also update Guest device-tree based on Virtio GPIO
DT bindings [1].
[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio-virtio.yaml
Signed-off-by: Viresh Kumar
---
tools/libs
5/6 and 6/6 updated based on the above two patches.
- Added link to the bindings for I2C and GPIO.
- Rebased over latest master branch.
Thanks.
--
Viresh
[1]
https://lore.kernel.org/xen-devel/20220414092358.kepxbmnrtycz7mhe@vireshk-i7/
Viresh Kumar (6):
libxl: Add support for Virtio I2C
On 09-08-22, 09:59, Viresh Kumar wrote:
> There is only one use of virtio_enabled after this patch, i.e. do
> check for vpl011. Maybe we can drop the variable and use
> virtio_mmio_irq != GUEST_VIRTIO_MMIO_SPI_FIRST ?
Nevermind, after modifying code I decided to keep the variabl
On 09-08-22, 11:04, Viresh Kumar wrote:
> Hello,
>
> This patchset adds toolstack support for I2C and GPIO virtio devices. This is
> inspired from the work done by Oleksandr for the Disk device.
>
> This is developed as part of Linaro's Project Stratos, where we are worki
ebased over latest master branch.
Thanks.
--
Viresh
[1]
https://lore.kernel.org/xen-devel/20220414092358.kepxbmnrtycz7mhe@vireshk-i7/
Viresh Kumar (6):
libxl: Add support for Virtio I2C device
libxl: Add support for Virtio GPIO device
libxl: arm: Create alloc_virtio_mmio_params()
libxl:
-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 51
1 file changed, 51 insertions(+)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 4c1012e56893..86c1e560900f 100644
--- a/tools/libs/light/libxl_arm.c
+++ b/tools/libs/light
" are just written to the
Xenstore.
Signed-off-by: Viresh Kumar
---
tools/golang/xenlight/helpers.gen.go | 108 ++-
tools/golang/xenlight/types.gen.go| 27 +++
tools/include/libxl.h | 32 +++
tools/include/libxl_utils.h |
.
[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/i2c/i2c-virtio.yaml
Reviewed-by: Oleksandr Tyshchenko
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 57 +++-
1 file changed, 50 insertions(+), 7 deletions(-)
diff --git a/tools
Create a separate routine to allocate base and irq for a device as the
same code will be required for each device type.
Suggested-by: Oleksandr Tyshchenko
Reviewed-by: Oleksandr Tyshchenko
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 46
" are just written to the
Xenstore.
Signed-off-by: Viresh Kumar
---
tools/golang/xenlight/helpers.gen.go | 108 +++
tools/golang/xenlight/types.gen.go| 27 +++
tools/include/libxl.h | 32 +++
tools/include/libxl_utils.h |
o create a simple DT node.
Reviewed-by: Oleksandr Tyshchenko
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index 0e
On 24-03-22, 06:12, Juergen Gross wrote:
> For a rather long time we were using "normal" user pages for this purpose,
> which were just locked into memory for doing the hypercall.
>
> Unfortunately there have been very rare problems with that approach, as
> the Linux kernel can set a user page rel
Add tools/helpers/init-dom0less to gitignore.
Signed-off-by: Viresh Kumar
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 27881c976432..9f9f18c97d5f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -170,6 +170,7 @@ tools/flask/utils/flask-setenforce
Add *.patch entry to .gitignore file to stop showing git generated
patches in commands like 'git status'.
Signed-off-by: Viresh Kumar
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 9f9f18c97d5f..d9a4fd038145 100644
--- a/.gitig
On 07-09-22, 12:09, Juergen Gross wrote:
> On 07.09.22 12:05, Viresh Kumar wrote:
> > Add *.patch entry to .gitignore file to stop showing git generated
> > patches in commands like 'git status'.
> >
> > Signed-off-by: Viresh Kumar
> > ---
> > .
ementation and began by (blindly)
copying code from Keyboard device and so much of wasted code in here, which
isn't really required.
On 06-09-22, 17:15, Anthony PERARD wrote:
> On Mon, Aug 22, 2022 at 02:45:13PM +0530, Viresh Kumar wrote:
> > An example of domain configuration
On 07-09-22, 18:49, Julien Grall wrote:
> Looking at this series, you will add ~250 lines (assuming your new patch)
> for the i2c and then likely the same amount for GPIO.
>
> I am assuming that for every new virtio device (e.g. gps, sound,
> display...), we would also need to 250 lines of code. I
On 07-09-22, 19:02, Julien Grall wrote:
> It is a very descriptive compatible :). And yes I realize this is the
> compatible chosen by upstream.
:)
> So this is exposing a GPIO interrupt controller but IIUC we will also need
> to describe the devices in the device-tree. Can you outline how you wo
ame make_virtio_mmio_node_simple() as make_virtio_mmio_node().
- New patch 3/3, separated code from device specific patch.
--
Viresh
Viresh Kumar (3):
libxl: arm: Create alloc_virtio_mmio_params()
libxl: arm: Split make_virtio_mmio_node()
libxl: arm: make creation of iommu node independent of disk device
tools/l
on other device types too.
Suggested-by: Oleksandr Tyshchenko
Reviewed-by: Oleksandr Tyshchenko
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 47 +---
1 file changed, 33 insertions(+), 14 deletions(-)
diff --git a/tools/libs/light/libxl_arm.c b
o create a simple DT node.
Reviewed-by: Oleksandr Tyshchenko
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/tools/libs/light/libxl_arm.c b/tools/libs/light/libxl_arm.c
index cc30ba124918..55
The iommu node will be required for other virtio device types too, not
just disk device.
Move the call to make_xen_iommu_node(), out of the disk device specific
block and rename "iommu_created" variable to "iommu_needed", and set it
to true for virtio disk device.
Signed-
The iommu node will be required for other virtio device types too, not
just disk device.
Move the call to make_xen_iommu_node(), out of the disk device specific
block and rename "iommu_created" variable to "iommu_needed", and set it
to true for virtio disk device.
Signed-
On 09-09-22, 16:02, Anthony PERARD wrote:
> On Fri, Sep 09, 2022 at 08:13:28PM +0530, Viresh Kumar wrote:
> > The iommu node will be required for other virtio device types too, not
> > just disk device.
> >
> > Move the call to make_xen_iommu_node(), out of the disk de
at by adding a dummy callback.
>
> Looks like the release_device() callback is not mandatory to be
> implemented as IOMMU framework makes sure that callback is initialized
> before dereferencing.
>
> Reported-by: Viresh Kumar
> Signed-off-by: Oleksandr Tyshchenko
> ---
> d
Hi Oleksandr,
As you already know, I am looking at how we can integrate the Xen
grants work in our implementation of Rust based Xen vhost frontend [1].
The hypervisor independent vhost-user backends [2] talk to
xen-vhost-frontend using the standard vhost-user protocol [3]. Every
memory region tha
nal memory mapping requirements.
When this feature is negotiated, the front-end can send the
'VHOST_USER_CUSTOM_MMAP' message type to provide the additional
information to the back-end.
Signed-off-by: Viresh Kumar
---
docs/interop/vhost-user.rst | 32
On 20-02-23, 07:13, Juergen Gross wrote:
> There are no permission flags in Xen PV device protocols either. The kind of a
> mapping (RO or RW) in the backend is selected via the I/O operation: in case
> it
> is a write type operation (guest writing data to a device), the related grants
> are mappe
On 01-03-23, 12:29, Stefan Hajnoczi wrote:
> What is the advantage over defining separate messages? Separate messages
> are cleaner and more typesafe.
I thought we wanted to keep single message for one kind of functionality, which
is mmap related quirks here. And so it would be better if we can re
Hi Oleksandr,
On Mon, Jun 6, 2022 at 10:16 AM Oleksandr Tyshchenko
wrote:
> The high level idea is to create new Xen’s grant table based DMA-mapping
> layer for the guest Linux whose main
> purpose is to provide a special 64-bit DMA address which is formed by using
> the grant reference (for a
use_grants);
-void xen_set_restricted_virtio_memory_access(void)
+void __init xen_set_restricted_virtio_memory_access(void)
{
if (IS_ENABLED(CONFIG_XEN_VIRTIO_FORCE_GRANT) || xen_virtio_grants ||
(!xen_virtio_grants_set && xen_pv_domain()))
With that:
Tested-by: Viresh Kumar
--
viresh
On 28-04-22, 16:52, Oleksandr Tyshchenko wrote:
> FYI, currently we are working on one feature to restrict memory access
> using Xen grant mappings based on xen-grant DMA-mapping layer for Linux [1].
> And there is a working PoC on Arm based on an updated virtio-disk. As for
> libraries, there is a
On 22-06-22, 18:05, Oleksandr Tyshchenko wrote:
> Even leaving
> aside the fact that restricted virtio memory access in the guest means that
> not all of guest memory can be accessed, so even having pre-maped guest
> memory in advance, we are not able to calculate a host pointer as we don't
> know
On 23-06-22, 15:47, Oleksandr Tyshchenko wrote:
> Below is my understanding, which might be wrong.
>
> I am not sure about x86, there are some moments with its modes, for example
> PV guests should always use grants for virtio, but on Arm (which guest type
> is HVM):
> 1. If you run backend(s) in
On 01-03-23, 10:47, Stefan Hajnoczi wrote:
> Resend - for some reason my email didn't make it out.
How about this (will send a formal patch later).
Author: Viresh Kumar
Date: Tue Feb 21 14:36:30 2023 +0530
docs: vhost-user: Add Xen specific memory mapping support
The curre
ST_USER_SET_XEN_MMAP' message type to provide the additional
information to the back-end.
Signed-off-by: Viresh Kumar
---
V1->V2:
- Make the custom mmap feature Xen specific, instead of being generic.
- Clearly define which memory regions are impacted by this change.
- Allow VHOST_US
On 06-03-23, 10:34, Stefan Hajnoczi wrote:
> On Mon, Mar 06, 2023 at 04:40:24PM +0530, Viresh Kumar wrote:
> > +Xen mmap description
> > +
> > +
> > ++---+---+
> > +| flags | domid |
> > ++---+---+
> > +
> >
memory regions themselves.
Signed-off-by: Viresh Kumar
---
docs/interop/vhost-user.rst | 21 +
1 file changed, 21 insertions(+)
diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst
index 1720d681264d..5a070adbc1aa 100644
--- a/docs/interop/vhost-user.rst
+++
define which memory regions are impacted by this change.
- Allow VHOST_USER_SET_XEN_MMAP to be called multiple times.
- Additional Bit(2) property in flags.
Viresh Kumar (2):
docs: vhost-user: Define memory region separately
docs: vhost-user: Add Xen specific memory mapping support
docs/i
t; to "multiple
memory regions description", to avoid potential confusion around similar
names. And define single region before multiple ones.
This is just a documentation optimization, the protocol remains the same.
Signed-off-by: Viresh Kumar
---
docs/interop/vhost-user.rst | 39 +
On 07-03-23, 11:22, Stefan Hajnoczi wrote:
> VHOST_USER_IOTLB_MSG probably isn't necessary because address
> translation is not required. It will also reduce performance by adding
> extra communication.
>
> Instead, you could change the 1 memory region : 1 mmap relationship that
> existing non-Xen
On 09-03-23, 14:20, Viresh Kumar wrote:
> Hello,
>
> This patchset tries to update the vhost-user protocol to make it support
> special
> memory mapping required in case of Xen hypervisor.
>
> The first patch is mostly cleanup and second one introduces a new xen specific
&
The strings won't be an exact match, and we are only looking to match
the prefix here, i.e. "virtio,device". This is already done properly in
libxl_virtio.c file, lets do the same here too.
Signed-off-by: Viresh Kumar
---
tools/libs/light/libxl_arm.c | 12
1
ommit adds another parameter for virtio devices, with which they
can do forced grant mappings irrespective of the backend domain id.
Signed-off-by: Viresh Kumar
---
docs/man/xl.cfg.5.pod.in | 4
tools/libs/light/libxl_arm.c | 21 -
tools/libs/light/libxl_type
On 04-04-23, 21:16, Oleksandr Tyshchenko wrote:
> ok, probably makes sense
While testing both foreign and grant mappings I stumbled upon another
related problem. How do I control the creation of iommu node from
guest configuration file, irrespective of the domain backend is
running at ? This is wh
le system device.
Update documentation to support that as well.
Fixes: dd54ea500be8 ("docs: add documentation for generic virtio devices")
Signed-off-by: Viresh Kumar
---
V1->V2: New patch.
docs/man/xl.cfg.5.pod.in | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/docs
The strings won't be an exact match, as we are only looking to match the
prefix here, i.e. "virtio,device". This is already done properly in
libxl_virtio.c file, lets do the same here too.
Fixes: 43ba5202e2ee ("libxl: add support for generic virtio device")
Signed-off-by:
On 09-03-23, 14:20, Viresh Kumar wrote:
> Hello,
>
> This patchset tries to update the vhost-user protocol to make it support
> special
> memory mapping required in case of Xen hypervisor.
>
> The first patch is mostly cleanup and second one introduces a new xen specif
imal format for
N.
Author: Viresh Kumar
Date: Wed Apr 5 05:36:19 2023 +0530
docs: Allow generic virtio device types to contain device-id
For generic virtio devices, where we don't need to add compatible or
other special DT properties, the type field is set to "virtio,device&q
On 05-04-23, 11:15, Jan Beulich wrote:
> On 05.04.2023 10:51, Viresh Kumar wrote:
> > --- a/docs/man/xl.cfg.5.pod.in
> > +++ b/docs/man/xl.cfg.5.pod.in
> > @@ -1608,8 +1608,10 @@ example, "type=virtio,device22" for the I2C device,
> > whose device-t
The strings won't be an exact match, as we are only looking to match the
prefix here, i.e. "virtio,device". This is already done properly in
libxl_virtio.c file, lets do the same here too.
Fixes: 43ba5202e2ee ("libxl: add support for generic virtio device")
Signed-off-b
device.
The complete list of virtio device ids is mentioned here:
https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v1.2-cs01.html#x1-2160005
Update documentation to support that as well.
Fixes: dd54ea500be8 ("docs: add documentation for generic virtio devices")
Signe
On 24-11-22, 20:19, Julien Grall wrote:
> Unfortunately, we had some delay for releasing 4.17. So I have pushed this
> series in a branch for-next/4.18.
Thanks.
> This will be applied to staging once the
> tree has re-opened.
I don't see the branch here though. Is it not public yet ? Or should I
On 08-11-22, 16:53, Viresh Kumar wrote:
> Hello,
>
> This patchset adds toolstack support for I2C and GPIO virtio devices. This is
> inspired from the work done by Oleksandr for the Disk device.
>
> This is developed as part of Linaro's Project Stratos, where we are worki
Hi Oleksandr,
On 02-12-22, 16:52, Oleksandr Tyshchenko wrote:
> > This patch adds basic support for configuring and assisting generic
> > Virtio backend which could run in any domain.
> >
> > An example of domain configuration for mmio based Virtio I2C device is:
> > virtio = ["type=virtio,device
On 02-12-22, 19:16, Oleksandr Tyshchenko wrote:
> Interesting, I see you allow user to configure virtio-mmio params (irq and
> base), as far as I remember for virtio-disk these are internal only
> (allocated by tools/libs/light/libxl_arm.c).
It is a mistake. Will drop it.
--
viresh
On 04-12-22, 20:52, Oleksandr Tyshchenko wrote:
> So as I understand current series adds support for two virtio devices
> (i2c/gpio) that require specific device-tree sub node with specific
> compatible in it [1]. Those backends are standalone userspace applications
> (daemons) that do not require
On 05-12-22, 11:45, Viresh Kumar wrote:
> > > +rc = libxl__backendpath_parse_domid(gc, be_path,
> > > &virtio->backend_domid);
> > > +if (rc) goto out;
> > > +
> > > +rc = libxl__parse_backend_path(gc, be_path, &dev);
> &g
to
remove everything else.
Fixes: 4ea75e9a9058 ("Rework COPYING installed in /usr/include/xen/, due to
several licences")
Signed-off-by: Viresh Kumar
---
I got into trouble as my build script does a "make clean" before building
everything again and so build fails without the COPY
On 06-12-22, 08:45, Juergen Gross wrote:
> Maybe in the tree you are using commit 25b55688e1f20ebb is missing?
Yes, that's the missing part I think.
--
viresh
+list
On 06-12-22, 13:40, Oleksandr Tyshchenko wrote:
> On Tue, Dec 6, 2022 at 1:15 PM Viresh Kumar wrote:
> > Hi Oleksandr,
> Hello Viresh
> >
> > I found that my rust counterpart [1] of virtio-disk repository broke
> > with this commit:
> >
> > co
On 07-12-22, 05:51, Viresh Kumar wrote:
> I am not sure how to get this working, as there is no finalizing event
> for the directory. Maybe our design is broken from the start and we
> need to do it properly in some recommended way ?
For now this is what I have done to make it work:
dif
On 06-12-22, 17:53, Oleksandr Tyshchenko wrote:
> On 05.12.22 11:11, Viresh Kumar wrote:
> > Maybe we can add these fields and a config param, once someone wants
> > to reuse this stuff for QEMU ?
>
>
> I don't know what to suggest here, sorry.
>
> On the on
ic virtio devices is also added, which just
need a MMIO node but not any special DT properties, for such devices the
user needs to pass "virtio,devices" in the "type" string.
The parsing of generic virtio device configurations will be done in a
separate commit.
Signed-off
This patch updates xl.cfg man page with details of generic Virtio device
related information.
Signed-off-by: Viresh Kumar
---
docs/man/xl.cfg.5.pod.in | 28
1 file changed, 28 insertions(+)
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index
This patch adds basic support for parsing generic Virtio backend.
An example of domain configuration for mmio based Virtio I2C device is:
virtio = ["type=virtio,device22,transport=mmio"]
Signed-off-by: Viresh Kumar
---
tools/ocaml/libs/xl/genwrap.py | 1 +
tools/oca
h
[1]
https://lore.kernel.org/xen-devel/20220414092358.kepxbmnrtycz7mhe@vireshk-i7/
[2]
https://xenbits.xen.org/gitweb/?p=people/julieng/xen-unstable.git;a=shortlog;h=refs/heads/for-next/4.18
Viresh Kumar (3):
libxl: Add support for generic virtio device
xl: Add support to parse generic virt
On 08-12-22, 18:06, Anthony PERARD wrote:
> Nit: Something like:
> const char check[] = "virtio,device";
> const size_t checkl = sizeof(check) - 1;
> ... strncmp(tmp, check, checkl)...
> (or just strncmp(tmp, check, sizeof(check)-1))
> would avoid issue with both string "virtio,devi
ic virtio devices is also added, which just
need a MMIO node but not any special DT properties, for such devices the
user needs to pass "virtio,device" in the "type" string.
The parsing of generic virtio device configurations will be done in a
separate commit.
Signed-off
sed over latest master branch.
Thanks.
--
Viresh
[1]
https://lore.kernel.org/xen-devel/20220414092358.kepxbmnrtycz7mhe@vireshk-i7/
Viresh Kumar (3):
libxl: Add support for generic virtio device
xl: Add support to parse generic virtio device
docs: Add documentation for generic virtio device
This patch updates xl.cfg man page with details of generic Virtio device
related information.
Signed-off-by: Viresh Kumar
---
docs/man/xl.cfg.5.pod.in | 33 +
1 file changed, 33 insertions(+)
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index
This patch adds basic support for parsing generic Virtio backend.
An example of domain configuration for mmio based Virtio I2C device is:
virtio = ["type=virtio,device22,transport=mmio"]
Signed-off-by: Viresh Kumar
---
tools/ocaml/libs/xl/genwrap.py | 1 +
tools/xl/xl_parse.c
6 are new.
- Patches 5/6 and 6/6 updated based on the above two patches.
- Added link to the bindings for I2C and GPIO.
- Rebased over latest master branch.
Thanks.
--
Viresh
[1]
https://lore.kernel.org/xen-devel/20220414092358.kepxbmnrtycz7mhe@vireshk-i7/
Viresh Kumar (3):
libxl: Add sup
: Anthony PERARD
Reviewed-by: Oleksandr Tyshchenko
Signed-off-by: Viresh Kumar
---
tools/libs/light/Makefile | 1 +
tools/libs/light/libxl_arm.c | 100 +++
tools/libs/light/libxl_create.c | 4 +
tools/libs/light/libxl_internal.h |
This patch updates xl.cfg man page with details of generic Virtio device
related information.
Reviewed-by: Anthony PERARD
Signed-off-by: Viresh Kumar
---
docs/man/xl.cfg.5.pod.in | 33 +
1 file changed, 33 insertions(+)
diff --git a/docs/man/xl.cfg.5.pod.in b
This patch adds basic support for parsing generic Virtio backend.
An example of domain configuration for mmio based Virtio I2C device is:
virtio = ["type=virtio,device22,transport=mmio"]
Signed-off-by: Viresh Kumar
---
tools/xl/xl_parse.c | 81 ++
On 13-12-22, 12:14, Jan Beulich wrote:
> Please can you arrange tags in time order, which would mean R-b past any
> S-o-b? I'll try to remember to swap them while committing, but in the
> future please save committers from needing to do so.
I was confused if Reviewed-by's should be after of before
On 13-12-22, 13:45, Oleksandr Tyshchenko wrote:
> On 13.12.22 12:08, Viresh Kumar wrote:
> > +/* Virtio device types */
> > +#define VIRTIO_DEVICE_TYPE_GENERIC "virtio,device"
> > +#define VIRTIO_DEVICE_TYPE_GPIO "virtio,device22"
> > +#defin
This patch adds basic support for parsing generic Virtio backend.
An example of domain configuration for mmio based Virtio I2C device is:
virtio = ["type=virtio,device22,transport=mmio"]
Signed-off-by: Viresh Kumar
Reviewed-by: Anthony PERARD
---
tools/xl/xl_pa
made changes according to changes in Oleksandr's
patches from sometime back.
- Minor cleanups.
V1->V2:
- Patches 3/6 and 4/6 are new.
- Patches 5/6 and 6/6 updated based on the above two patches.
- Added link to the bindings for I2C and GPIO.
- Rebased over latest master branch.
Thanks.
This patch updates xl.cfg man page with details of generic Virtio device
related information.
Signed-off-by: Viresh Kumar
Reviewed-by: Anthony PERARD
Reviewed-by: Oleksandr Tyshchenko
---
docs/man/xl.cfg.5.pod.in | 33 +
1 file changed, 33 insertions(+)
diff
ic virtio devices is also added, which just
need a MMIO node but not any special DT properties, for such devices the
user needs to pass "virtio,device" in the "type" string.
The parsing of generic virtio device configurations will be done in a
separate commit.
Signed-off-by: V
On 14-12-22, 09:21, Jan Beulich wrote:
> On 14.12.2022 06:19, Viresh Kumar wrote:
> > This patchset adds toolstack support for I2C, GPIO and generic virtio
> > devices.
> > This is inspired from the work done by Oleksandr for the Disk device.
> >
> > This is deve
On 14-12-22, 17:01, Oleksandr Tyshchenko wrote:
> Today I had a chance to check virtio-disk on my H/W using new Xen branch
> which does include Juergen's series with commit 3a96013a3e17
> ("tools/xenstore: reduce number of watch events").
>
> Very interesting, but I didn't manage to reproduce an i
pends upon since base passed
is 0.
Fixes: 43ba5202e2ee ("libxl: add support for generic virtio device")
Signed-off-by: Viresh Kumar
---
Couldn't test on 32-bit platforms yet, but works fine for 64 bit one.
tools/libs/light/libxl_virtio.c | 4 ++--
1 file changed, 2 insertions(+), 2 del
1 - 100 of 179 matches
Mail list logo
