On 07.04.24 05:43, Peng Fan wrote:
Hi Oleksandr,
Hello Peng
Subject: [PATCH 2/2] xen/arm: Add i.MX UART driver
From: Oleksandr Tyshchenko
The i.MX UART Documentation:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
nxp.com%2Fwebapp%2FDownload%3FcolCode
On 04.04.24 09:54, Michal Orzel wrote:
Hi Oleksandr,
Hello Michal
sorry for the late response
On 02/04/2024 14:05, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The i.MX UART Documentation:
https://www.nxp.com/webapp/Download?colCode=IMX8MMRM
Chapter 16.2 Universal
On 03.04.24 13:11, Michal Orzel wrote:
Hi Oleksandr,
Hello Michal
sorry for the late response
On 02/04/2024 14:05, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Tested on i.MX 8M Mini only, but I guess, it should be
suitable for other i.MX8M* SoCs (those UART device tree
From: Oleksandr Tyshchenko
This is needed to have a possibility of assigning a specified number
of shared peripheral interrupts (SPIs) to domain.
Signed-off-by: Oleksandr Tyshchenko
Signed-off-by: Stefano Stabellini
---
README.md| 5 +
scripts/uboot-script-gen | 4
2
From: Oleksandr Tyshchenko
uImage is the Image that has a U-Boot wrapper, it doesn't contain
"executable" string which subsequent "file" command is looking for
when inspecting it.
Below the proof:
otyshchenko@EPUAKYIW03DD:~/work/xen_tests/input$ file -L binaries/uImage.gz
b
From: Oleksandr Tyshchenko
Use DOMU_GRANT_VER to set "max_grant_version" dt property.
Use DOMU_GRANT_FRAMES to set "max_grant_frames" dt property.
Use DOMU_MAPTRACK_FRAMES to set "max_maptrack_frames" dt property.
Signed-off-by: Oleksandr Tyshchenko
---
From: Oleksandr Tyshchenko
Introduce new option DOMU_VPL011[nr] that can be set to 0
or 1 (default).
Also align "console=ttyAMA0" Linux cmd arg setting with "vpl011" presense.
Suggested-by: Michal Orzel
Signed-off-by: Oleksandr Tyshchenko
---
README.md
From: Oleksandr Tyshchenko
Hello all,
this is a collection of patches (#2-5) for improving the dom0less support
and a patch (#1) for dealing with uImage.
Oleksandr Tyshchenko (5):
uboot-script-gen: Update to deal with uImage which is not executable
uboot-script-gen: Extend DOMU_ENHANCED
From: Oleksandr Tyshchenko
We need some Xen services to be available within single dom0less DomU.
Just using "enabled" will lead to Xen panic because of no Dom0.
(XEN)
(XEN) Panic on CPU 0:
(XEN) At the moment, Xenstore support req
On 08.04.24 20:38, Hildebrand, Stewart via groups.io wrote:
> On 4/8/24 09:19, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko
>>
>> Please refer to chapter "Device Passthrough":
>> https://urldefense.com/v3/__https://groups.io/g/amd-xen-s
From: Oleksandr Tyshchenko
Please refer to chapter "Device Passthrough":
https://groups.io/g/amd-xen-safety/message/1300
Create corresponding directory and README file.
Signed-off-by: Oleksandr Tyshchenko
---
V2:
- add R-b
- update README
- lower case for platform, s/
From: Oleksandr Tyshchenko
The i.MX UART Documentation:
https://www.nxp.com/webapp/Download?colCode=IMX8MMRM
Chapter 16.2 Universal Asynchronous Receiver/Transmitter (UART)
Tested on i.MX 8M Mini only, but I guess, it should be
suitable for other i.MX8M* SoCs (those UART device tree nodes
From: Oleksandr Tyshchenko
Hello all.
This small series contains early printk and full UART support
for i.MX 8M Mini EVKB [1].
Tested on i.MX 8M Mini only to which I had an access, but from my
understanding, this UART support should be suitable for other i.MX8M* SoCs
(those UART device tree
From: Oleksandr Tyshchenko
Tested on i.MX 8M Mini only, but I guess, it should be
suitable for other i.MX8M* SoCs (those UART device tree nodes
contain "fsl,imx6q-uart" compatible string).
Signed-off-by: Oleksandr Tyshchenko
---
I selected the following configs for enabling ea
increment only if the
> caller has specified IRQF_SHARED in the irqflags parameter.
>
> Fixes: 9e90e58c11b7 ("xen: evtchn: Allow shared registration of IRQ handers")
> Signed-off-by: Juergen Gross
Reviewed-by: Oleksandr Tyshchenko
> ---
> drivers/xen/events/events_ba
quot;unbinding" flag to struct user_event which
> will short circuit the handler.
>
> Fixes: 9e90e58c11b7 ("xen: evtchn: Allow shared registration of IRQ handers")
> Reported-by: Demi Marie Obenour
> Tested-by: Demi Marie Obenour
> Signed-off-by: Juergen Gross
Revie
On 26.02.24 05:09, Peng Fan wrote:
> Hi Oleksandr,
Hello Peng
[snip]
>>
>> ... Peng, we have vhost-vsock (and vhost-net) Xen PoC. Although it is
>> non-
>> upstreamable in its current shape (based on old Linux version, requires some
>> rework and proper integration, most likely requires
On 23.02.24 23:42, Stefano Stabellini wrote:
> Hi Peng,
Hello Peng, Stefano
>
> We haven't tried to setup virtio-vsock yet.
>
> In general, I am very supportive of using QEMU for virtio backends. We
> use QEMU to provide virtio-net, virtio-block, virtio-console and more.
>
> However,
From: Oleksandr Tyshchenko
Allow administrators to control whether Xen grant mappings for
the virtio disk devices should be used. By default (when new
parameter is not specified), the existing behavior is retained
(we enable grants if backend-domid != 0).
Signed-off-by: Oleksandr Tyshchenko
On 13.02.24 14:14, Anthony PERARD wrote:
Hello Anthony
> On Tue, Feb 06, 2024 at 02:38:14PM +0200, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko
>>
>> Allow administrators to control whether Xen grant mappings for
>> the virtio disk devices should be
From: Oleksandr Tyshchenko
Allow administrators to control whether Xen grant mappings for
the virtio disk devices should be used. By default (when new
parameter is not specified), the existing behavior is retained
(we enable grants if backend-domid != 0).
Signed-off-by: Oleksandr Tyshchenko
On 06.02.24 12:27, Anthony PERARD wrote:
Hello Anthony
[snip]
diff --git a/docs/man/xl-disk-configuration.5.pod.in
b/docs/man/xl-disk-configuration.5.pod.in
index bc945cc517..3c035456d5 100644
--- a/docs/man/xl-disk-configuration.5.pod.in
+++
On 05.02.24 17:10, Anthony PERARD wrote:
Hello Anthony
> On Fri, Feb 02, 2024 at 12:49:03PM +0200, Oleksandr Tyshchenko wrote:
>> diff --git a/tools/libs/util/libxlu_disk_l.l
>> b/tools/libs/util/libxlu_disk_l.l
>> index 6d53c093a3..f37dd443bd 100644
>> --- a/tool
On 02.02.24 13:03, Viresh Kumar wrote:
Hello Viresh
> On 02-02-24, 12:49, Oleksandr Tyshchenko wrote:
>> diff --git a/docs/man/xl-disk-configuration.5.pod.in
>> b/docs/man/xl-disk-configuration.5.pod.in
>> index bc945cc517..3c035456d5 100644
>> --- a/docs/man/xl-
From: Oleksandr Tyshchenko
Allow administrators to control whether Xen grant mappings for
the virtio disk devices should be used. By default (when new
parameter is not specified), the existing behavior is retained
(we enable grants if backend-domid != 0).
Signed-off-by: Oleksandr Tyshchenko
gt; Fixes: a5ed59e62c6f ("arm/mmu: Move init_ttbr to a new section .data.idmap")
> Fixes: 9a5114074b04 ("arm/smpboot: Move smp_up_cpu to a new section
> .data.idmap)
>
> Reported-by: Oleksandr Tyshchenko
> Signed-off-by: Julien Grall
[on Renesas R-Car Gen3 SoC with 8 cor
From: Oleksandr Tyshchenko
DO NOT access the underlying struct page of an sg table exported
by DMA-buf in dmabuf_imp_to_refs(), this is not allowed.
Please see drivers/dma-buf/dma-buf.c:mangle_sg_table() for details.
Fortunately, here (for special Xen device) we can avoid using
pages
On 08.01.24 14:05, Daniel Vetter wrote:
Hello Daniel
> On Sun, 7 Jan 2024 at 11:35, Oleksandr Tyshchenko wrote:
>>
>> From: Oleksandr Tyshchenko
>>
>> DO NOT access the underlying struct page of an sg table exported
>> by DMA-buf in dmabuf_imp_to_refs(), t
From: Oleksandr Tyshchenko
DO NOT access the underlying struct page of an sg table exported
by DMA-buf in dmabuf_imp_to_refs(), this is not allowed.
Please see drivers/dma-buf/dma-buf.c:mangle_sg_table() for details.
Fortunately, here (for special Xen device) we can avoid using
pages
From: Oleksandr Tyshchenko
DO NOT access the underlying struct page of an sg table exported
by DMA-buf in dmabuf_imp_to_refs(), this is not allowed.
Please see drivers/dma-buf/dma-buf.c:mangle_sg_table() for details.
Fortunately, here (for special Xen device) we can avoid using
pages
On 17.11.23 05:31, Stewart Hildebrand wrote:
Hello Stewart
[answering only for virtio-pci bits as for vPCI I am only familiar with
code responsible for trapping config space accesses]
[snip]
>>
>>
>> Let me start by saying that if we can get away with it, I think that a
>> single PCI Root
On 15.11.23 20:33, Julien Grall wrote:
> Hi Oleksandr,
Hello Julien
>
> On 15/11/2023 18:14, Oleksandr Tyshchenko wrote:
>> On 15.11.23 19:31, Julien Grall wrote:
>>> On 15/11/2023 16:51, Oleksandr Tyshchenko wrote:
>>>> On 15.11.23 14:33, Julien Grall wr
On 15.11.23 19:31, Julien Grall wrote:
> Hi Oleksandr,
Hello Julien
>
> On 15/11/2023 16:51, Oleksandr Tyshchenko wrote:
>>
>>
>> On 15.11.23 14:33, Julien Grall wrote:
>>> Hi,
>>
>>
>> Hello Julien
>>
>> Let me please
On 15.11.23 14:33, Julien Grall wrote:
> Hi,
Hello Julien
Let me please try to explain some bits.
>
> Thanks for adding support for virtio-pci in Xen. I have some questions.
>
> On 15/11/2023 11:26, Sergiy Kibrik wrote:
>> From: Oleksandr Tyshchenko
>>
>
On 14.11.23 10:35, Juergen Gross wrote:
Hello Juergen
> On 14.11.23 09:20, Oleksandr Tyshchenko wrote:
>>
>>
>> On 16.10.23 09:28, Juergen Gross wrote:
>>
>>
>> Hello Juergen
>>
>>> Instead of having a common function for allocating a si
d, so
Reviewed-by: Oleksandr Tyshchenko
Just one NIT below ...
[snip]
>
> -static void pirq_query_unmask(int irq)
> +static void pirq_query_unmask(struct irq_info *info)
> {
> struct physdev_irq_status_query irq_status;
> - struct irq_info *info = info_for_irq(irq
_send_IPI_one()" went in).
I was going to ask why "pirq_query_unmask()/pirq_from_irq()" wasn't
converted to take a struct irq_info parameter as well, but looking at
the rest I noticed this was already done in subsequent commit.
With proper rebasing:
Reviewed-by: Oleksandr Tyshchenko
[snip]
On 16.10.23 09:28, Juergen Gross wrote:
Hello Juergen
> Instead of having a common function for allocating a single IRQ or a
> consecutive number of IRQs, split up the functionality into the callers
> of xen_allocate_irqs_dynamic().
>
> This allows to handle any allocation error in
);
> + WARN_ON(info->type != IRQT_EVTCHN);
> + irq = info->irq;
> }
This hunk doesn't apply clearly to the latest state, because of
"9e90e58c11b7 xen: evtchn: Allow shared registration of IRQ handers"
went in. Please rebase.
With
-by: Juergen Gross
Reviewed-by: Oleksandr Tyshchenko
Two NITs *NOT* directly related to current patch below.
> ---
> drivers/xen/events/events_2l.c | 8
> drivers/xen/events/events_base.c | 13 +
> drivers/xen/events/events_internal.h | 1 -
>
On 16.10.23 09:28, Juergen Gross wrote:
Hello Juergen
> There are no users of xen_irq_from_pirq() and xen_set_irq_pending().
>
> Remove those functions.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Oleksandr Tyshchenko
> ---
> drivers/xen/even
Signed-off-by: Juergen Gross
Reviewed-by: Oleksandr Tyshchenko
---
drivers/xen/events/events_base.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 1b2136fe0fa5..0e458b1c0c8c 100644
--- a/d
On 04.10.23 15:59, Roger Pau Monné wrote:
Hello Roger
> On Wed, Oct 04, 2023 at 11:42:32AM +0000, Oleksandr Tyshchenko wrote:
>>
>>
>> On 04.10.23 13:55, Julien Grall wrote:
>>
>> Hello all.
>>
>>> Hi Roger,
>>>
>>> On 04/10/
On 04.10.23 13:55, Julien Grall wrote:
Hello all.
> Hi Roger,
>
> On 04/10/2023 09:13, Roger Pau Monné wrote:
>> On Tue, Oct 03, 2023 at 12:18:35PM -0700, Elliott Mitchell wrote:
>>> On Tue, Oct 03, 2023 at 10:26:28AM +0200, Roger Pau Monné wrote:
On Thu, Sep 28, 2023 at 07:49:18PM
Urae9KNyQk_JBW1QVL$
> [lore[.]kernel[.]org]
> Signed-off-by: Juergen Gross
Reviewed-by: Oleksandr Tyshchenko
> ---
> drivers/xen/xenbus/xenbus_probe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/xen/xenbus/xenbus_probe.c
> b/d
On 27.07.23 17:33, Jan Beulich wrote:
Hello Jan
> On 26.07.2023 17:13, Oleksandr Tyshchenko wrote:
>> On 26.07.23 17:50, Jan Beulich wrote:
>>> On 26.07.2023 16:14, Oleksandr Tyshchenko wrote:
>>>> From: Oleksandr Tyshchenko
>>>>
>>>> Wit
On 27.07.23 16:45, Anthony PERARD wrote:
Hello Anthony
> On Thu, Jul 27, 2023 at 10:38:03AM +0000, Oleksandr Tyshchenko wrote:
>>
>>
>> On 27.07.23 12:50, Anthony PERARD wrote:
>>
>> Hello Anthony
>>
>>> On Wed, Jul 26, 2023 at 05:14:5
On 27.07.23 12:50, Anthony PERARD wrote:
Hello Anthony
> On Wed, Jul 26, 2023 at 05:14:59PM +0300, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko
>>
>> Without it being present it won't be possible to use some
>> libxl__device_type's callbacks for virtio
On 26.07.23 17:50, Jan Beulich wrote:
Hello Jan
> On 26.07.2023 16:14, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko
>>
>> Without it being present it won't be possible to use some
>> libxl__device_type's callbacks for virtio devices as the com
From: Oleksandr Tyshchenko
Without it being present it won't be possible to use some
libxl__device_type's callbacks for virtio devices as the common code
can only invoke these callbacks (by dereferencing a pointer) for valid
libxl__device_type's elements when iterating over device_type_tbl
On 20.07.23 12:30, Viresh Kumar wrote:
Hello Viresh
> Update the definitions in dm_op.h from Xen public header.
I think, it would be good to mention exact Xen version (commit) we are
based on.
In general patch looks good to me, just a note.
I compared with Xen's public/hvm/dm_op.h and
> Signed-off-by: Stefano Stabellini
> Tested-by: Petr Mladek
Reviewed-by: Oleksandr Tyshchenko
I guess this wants to gain the Fixes tag:
Fixes: 5b3353949e89 ("xen: add support for initializing xenstore later
as HVM domain")
>
> diff --git a/drivers/xen/xenbus/xenbus_pro
On 20.07.23 12:41, Viresh Kumar wrote:
Hello Viresh
> On 13-07-23, 14:40, Oleksandr Tyshchenko wrote:
>> Viresh, great work!
>
> Thanks Oleksandr.
>
>> Do you perhaps have corresponding users-space (virtio backend) example
>> adopted for that featur
d change in change-log since v2:
* Make sure that evtchn hasn't been added yet before binding it in
evtchn_ioctl():case IOCTL_EVTCHN_BIND_STATIC
Reviewed-by: Oleksandr Tyshchenko
> v2:
> * Use bool in place u8 to define is_static variable.
> * Avoid closing the static evtchns in error path.
> ---
[snip]
On 13.07.23 10:44, Juergen Gross wrote:
Hello all.
> On 12.07.23 10:48, Viresh Kumar wrote:
>> Xen provides support for injecting interrupts to the guests via the
>> HYPERVISOR_dm_op() hypercall. The same is used by the Virtio based
>> device backend implementations, in an inefficient manner
On 21.06.23 15:06, Jan Beulich wrote:
Hello all
On 13.06.2023 12:32, Volodymyr Babchuk wrote:
@@ -121,6 +124,62 @@ int vpci_add_handlers(struct pci_dev *pdev)
}
#ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
+static int add_virtual_device(struct pci_dev *pdev)
+{
+struct domain *d =
On 07.07.23 11:11, Juergen Gross wrote:
Hello Juergen
> On 07.07.23 10:00, Oleksandr Tyshchenko wrote:
>>
>>
>> On 07.07.23 10:04, Juergen Gross wrote:
>>
>> Hello Juergen
>>
>>
>>> Re-reading the whole thread again ...
>>>
>&
On 07.07.23 10:04, Juergen Gross wrote:
Hello Juergen
> Re-reading the whole thread again ...
>
> On 29.06.23 03:00, Stefano Stabellini wrote:
>> On Wed, 21 Jun 2023, Oleksandr Tyshchenko wrote:
>>> On 21.06.23 16:12, Petr Pavlu wrote:
>>>
>>>
&
From: Oleksandr Tyshchenko
With enabling both CONFIG_UBSAN and CONFIG_IPMMU_VMSA I have got the following
splat when an IOMMU driver tried to setup page tables:
(XEN) ipmmu: /soc/iommu@e67b: d1: Set IPMMU context 1 (pgd 0x77fe9)
(XEN
FIG_XEN_VIRTIO_FORCE_GRANT was not enough to fix it).
> > With that context in place, the actual response below.
> >
> > On Tue, Jul 04, 2023 at 12:39:40PM +0200, Juergen Gross wrote:
> > > On 04.07.23 09:48, Roger Pau Monné wrote:
> > > > On Thu, Jun 29, 2023 at 03:44:04
On 29.06.23 04:00, Stefano Stabellini wrote:
Hello Stefano
> On Wed, 21 Jun 2023, Oleksandr Tyshchenko wrote:
>> On 21.06.23 16:12, Petr Pavlu wrote:
>>
>>
>> Hello Petr
>>
>>
>>> When attempting to run Xen on a QEMU/KVM virtual machine
On 29.06.23 18:46, Rahul Singh wrote:
Hello Rahul
> Xen 4.17 supports the creation of static evtchns. To allow user space
> application to bind static evtchns introduce new ioctl
> "IOCTL_EVTCHN_BIND_STATIC". Existing IOCTL doing more than binding
> that’s why we need to introduce the new
On 21.06.23 16:12, Petr Pavlu wrote:
Hello Petr
> When attempting to run Xen on a QEMU/KVM virtual machine with virtio
> devices (all x86_64), dom0 tries to establish a grant for itself which
> eventually results in a hang during the boot.
>
> The backtrace looks as follows, the while loop
;bridge->parent in xen_dt_get_node() for
> NULL first >
> Fixes: ef8ae384b4c9 ("xen/virtio: Handle PCI devices which Host controller is
> described in DT")
Oops, sorry. I have to admit I checked with DT only.
> Signed-off-by: Petr Pavlu
Reviewed-by: Oleksandr Tysh
Hello Viresh
[sorry for the possible format issues]
On Fri, May 5, 2023 at 9:19 AM Viresh Kumar wrote:
> On 05-04-23, 05:12, Viresh Kumar wrote:
> > On 04-04-23, 21:16, Oleksandr Tyshchenko wrote:
> > > ok, probably makes sense
> >
> > While testing both foreign
xl: add support for generic virtio device")
Signed-off-by: Viresh Kumar
---
V1->V2: Add the missing fixes tag.
Reviewed-by: Oleksandr Tyshchenko
tools/libs/light/libxl_arm.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/tools/libs/light/libxl_a
uot;, or I really missed something?
With updating description if NIT is correct (I don't know, maybe this
could be done on commit):
Reviewed-by: Oleksandr Tyshchenko
Update documentation to support that as well.
Fixes: dd54ea500be8 ("docs: add documentation for generic virtio devic
On 30.03.23 11:43, Viresh Kumar wrote:
Hello Viresh
Currently, we add grant mapping related device tree properties if the
backend domain is not Dom0. While Dom0 is privileged and can do foreign
mapping for the entire guest memory, it is still okay for Dom0 to access
guest's memory via grant
On 30.03.23 10:35, Viresh Kumar wrote:
Hello Viresh
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
It feels to me
AWwxJ_cv_tWGY42f5NPgn6JHtZsiGP$
> [lore[.]kernel[.]org]
> Signed-off-by: Juergen Gross
> ---
> V2:
> - remove stale spin_unlock() (Oleksandr Tyshchenko)
Reviewed-by: Oleksandr Tyshchenko
> ---
> drivers/xen/pvcalls-front.c | 46 +
On 29.03.23 09:20, Juergen Gross wrote:
Hello Juergen
> On 28.03.23 17:47, Oleksandr Tyshchenko wrote:
>>
>>
>> On 28.03.23 11:46, Juergen Gross wrote:
>>
>> Hello Juergen
>>
>>> scsiback_free_translation_entry() shouldn't be called under spin
On 28.03.23 11:46, Juergen Gross wrote:
Hello Juergen
> scsiback_free_translation_entry() shouldn't be called under spinlock,
> as it can sleep.
>
> This requires to split removing a translation entry from the v2p list
> from actually calling kref_put() for the entry.
>
> Reported-by: Dan
cieZUZnc6cPwh7Ta8hiLRKwS1Gs-1tmQP-NuEYoz9LhYWI8aFazIwIa8Lh$
> [lore[.]kernel[.]org]
> Signed-off-by: Juergen Gross
Reviewed-by: Oleksandr Tyshchenko
> ---
> drivers/xen/xen-pciback/pci_stub.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/d
On 28.03.23 12:39, Juergen Gross wrote:
Hello Juergen
bind_evtchn_to_irqhandler() shouldn't be called under spinlock, as it
can sleep.
This requires to move the calls of create_active() out of the locked
regions. This is no problem, as the worst which could happen would be
a spurious call
From: Oleksandr Tyshchenko
The "vdev->dev.parent" should be used instead of "vdev->dev" as a device
for which to perform the DMA operation in both
virtio_gpu_cmd_transfer_to_host_2d(3d).
Because the virtio-gpu device "vdev->dev" doesn't really have DMA OPS
represents and how it should be mapped)
one (crazy?) idea could be to try to map everything as RW and fallback to
RO if the mapping attempt fails. Or, perhaps, as an alternative,
to map as RW only those pages which are going to be modified, anything else
map as RO. Although I am not quite sure whether it would be a good idea.
--
Regards,
Oleksandr Tyshchenko
From: Oleksandr Tyshchenko
Update stub IOMMU driver (which main purpose is to reuse generic
IOMMU device-tree bindings by Xen grant DMA-mapping layer on Arm)
according to the recent changes done in the following
commit 57365a04c921 ("iommu: Move bus setup to IOMMU device registr
On 08.01.23 18:06, Julien Grall wrote:
Hello Julien, Ayan, all
Hi Ayan,
On 21/12/2022 18:53, Ayan Kumar Halder wrote:
Currently, kernel_uimage_probe() does not read the load/entry point
address
set in the uImge header. Thus, info->zimage.start is 0 (default
value). This
causes,
On 15.12.22 06:22, Viresh Kumar wrote:
Hello Viresh
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 e
On 07.12.22 05:59, Viresh Kumar wrote:
Hello Viresh
First of all, sorry for the late response.
The second, thank you for the investigation.
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
ations will be done in a
separate commit.
Reviewed-by: 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_creat
On 13.12.22 12:08, Viresh Kumar wrote:
Hello Viresh
This patch updates xl.cfg man page with details of generic Virtio device
related information.
Reviewed-by: Anthony PERARD
Signed-off-by: Viresh Kumar
Now it looks perfect, thanks
Reviewed-by: Oleksandr Tyshchenko
---
docs/man
e
> 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: Viresh Kumar
>
Reviewed-by: Oleksandr Tyshchenko
with one NIT addressed ...
> ---
On 05.12.22 13:29, Viresh Kumar wrote:
Hello Viresh
On 05-12-22, 11:45, Viresh Kumar wrote:
+rc = libxl__backendpath_parse_domid(gc, be_path, >backend_domid);
+if (rc) goto out;
+
+rc = libxl__parse_backend_path(gc, be_path, );
+if (rc) goto out;
The same question for dev
On 05.12.22 11:11, Viresh Kumar wrote:
Hello 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
On 05.12.22 08:20, Viresh Kumar wrote:
Hello Viresh
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
On 05.12.22 08:15, Viresh Kumar wrote:
Hi Oleksandr,
Hello Viresh
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
On 08.11.22 13:24, Viresh Kumar wrote:
Hello Viresh
[sorry for the possible format issues if any]
This patch updates xl.cfg man page with details of generic Virtio device
related information.
So as I understand current series adds support for two virtio devices
(i2c/gpio) that require
On 08.11.22 13:23, Viresh Kumar wrote:
Hello Viresh
[sorry for the possible format issues if any]
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"]
On 08.11.22 13:23, Viresh Kumar wrote:
Hello Viresh
[sorry for the possible format issues if any]
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:
i:" at least.
Reviewed-by: Oleksandr Tyshchenko
Thanks.
> ---
> drivers/xen/platform-pci.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
> index 18f0ed8b1f93..6ebd819338ec 100644
> --
dd Xue - console over USB 3 Debug Capability.
>
I would probably also add the following:
- Add Renesas R-Car Gen4 IPMMU-VMSA support (Arm)
- grant-table support on Arm was improved and hardened by implementing
“simplified M2P-like
approach for the xenheap pages”
>
> ### Removed / support downgraded
> - dropped support for the (x86-only) "vesa-mtrr" and "vesa-remap"
> command line options
> --
> 2.25.1
>
>
>
--
Regards,
Oleksandr Tyshchenko
adding mc->default_machine_opts = "accel=xen";
to hw/arm/xen_arm.c:xen_arm_machine_class_init() or by some other method).
These actions are already done in accel/xen/xen-all.c:xen_init(). Please
note, that I am not too familiar with that code, so there might be nuances.
Besides that, Xen accelerator will be needed for the xen-mapcache to be in
use (this is needed for mapping guest memory), there are a few
xen_enabled() checks spreading around that code to perform Xen specific
actions.
--
Regards,
Oleksandr Tyshchenko
ST_VPCI_PREFETCH_MEM_ADDR (GUEST_VPCI_PREFETCH_MEM_SIZE)
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libs/light/libxl_arm.c;h=2a5e93c28403738779863aded31d2df3ba72f8c0;hb=HEAD#l833
Here in Qemu when creating a PCI Host bridge we would need to use exactly
the same reserved regions which toolstack writes in the corresponding
device-tree node. So how to tell Qemu about them?
1. Introduce new cmd line arguments?
2. Using Xenstore?
3. Anything else?
I am afraid this would be related to every device that we want to emulate
in Qemu and for which the toolstack needs to generate device-tree node by
using something defined with GUEST_*, unless I really missed something.
>
> Cheers,
>
> --
> Julien Grall
>
>
--
Regards,
Oleksandr Tyshchenko
On Thu, Oct 27, 2022 at 7:49 PM Rahul Singh wrote:
> Hi Oleksandr,
>
Hello Rahul
[sorry for the possible format issues]
>
> > On 26 Oct 2022, at 7:23 pm, Oleksandr Tyshchenko
> wrote:
> >
> >
> >
> > On Wed, Oct 26, 2022 at 8:18 PM Michal Orzel
&g
interrupt-parent = <0x01>;
> >>> #iommu-cells = <0x01>;
> >>> interrupt-names = "combined";
> >>> reg = <0x00 0x4f00 0x00 0x4>;
> >>> phandle = <0xfdeb>;
> >>> name = "iommu";
> >>> };
> >>
> >> So I guess this node will be written by Xen. How will you the case
> where there are extra property to added (e.g. dma-coherent)?
> >
> > In this example this is physical IOMMU node. vIOMMU node wil be created
> by xl during guest creation.
> >>
> >>> test@1000 {
> >>> compatible = "viommu-test”;
> >>> iommus = <0xfdeb 0x10>;
> >>
> >> I am a bit confused. Here you use 0xfdeb for the phandle but below...
> >
> > Here 0xfdeb is the physical IOMMU node phandle...
> >>
> >>> interrupts = <0x00 0xff 0x04>;
> >>> reg = <0x00 0x1000 0x00 0x1000>;
> >>> name = "viommu-test";
> >>> };
> >>> The partial Device tree node will be like this:
> >>> / {
> >>> /* #*cells are here to keep DTC happy */
> >>> #address-cells = <2>;
> >>> #size-cells = <2>;
> >>> passthrough {
> >>> compatible = "simple-bus";
> >>> ranges;
> >>> #address-cells = <2>;
> >>> #size-cells = <2>;
> >>> test@1000 {
> >>> compatible = "viommu-test";
> >>> reg = <0 0x1000 0 0x1000>;
> >>> interrupts = <0 80 4 0 81 4 0 82 4>;
> >>> iommus = <0xfdea 0x01>;
> >>
> >> ... you use 0xfdea. Does this mean 'xl' will rewrite the phandle?
> >
> > but here user has to set the “iommus” property with magic phanle as
> explained earlier. 0xfdea is magic phandle.
> >
> > Regards,
> > Rahul
>
> ~Michal
>
>
>
--
Regards,
Oleksandr Tyshchenko
On 25.10.22 20:27, Xenia Ragiadakou wrote:
Hello Xenia
> On 10/25/22 19:20, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko
>>
>> This is needed to avoid having to parse the same device-tree
>> several times for a given device.
>>
>&
On 22.10.22 09:44, Oleksandr wrote:
Hello Stefano.
>
> On 21.10.22 23:08, Stefano Stabellini wrote:
>
> Hello Stefano
>
>> On Fri, 21 Oct 2022, Oleksandr Tyshchenko wrote:
>>> From: Oleksandr Tyshchenko
>>>
>>> Use the same "xen-grant-dma&
From: Oleksandr Tyshchenko
This is needed to avoid having to parse the same device-tree
several times for a given device.
For this to work we need to install the xen_virtio_restricted_mem_acc
callback in Arm's xen_guest_init() which is same callback as x86's
PV and HVM modes already use
From: Oleksandr Tyshchenko
Use the same "xen-grant-dma" device concept for the PCI devices
behind device-tree based PCI Host controller, but with one modification.
Unlike for platform devices, we cannot use generic IOMMU bindings
(iommus property), as we need to support mor
1 - 100 of 686 matches
Mail list logo
