From: Oleksandr Tyshchenko
Add common requirements for a physical device assignment to Arm64
and AMD64 PVH domains.
Signed-off-by: Oleksandr Tyshchenko
---
Previous discussion (V1) here:
https://lists.xenproject.org/archives/html/xen-devel/2024-10/msg00534.html
V2:
A lot of changes
On 09.10.24 10:26, Julien Grall wrote:
Hi,
Hello Julien
On 07/10/2024 19:55, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Add common requirements for a physical device assignment to Arm64
and AMD64 PVH domains.
Signed-off-by: Oleksandr Tyshchenko
---
Based on:
[PATCH
On 09.10.24 09:36, Bertrand Marquis wrote:
Hi Oleksandr,
Hello Bertrand
On 8 Oct 2024, at 20:53, Oleksandr Tyshchenko wrote:
On 08.10.24 09:17, Bertrand Marquis wrote:
Hi,
Hello Bertrand
On 7 Oct 2024, at 20:55, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Add
On 09.10.24 01:46, Stefano Stabellini wrote:
Hello Stefano
On Tue, 8 Oct 2024, Oleksandr Tyshchenko wrote:
On 7 Oct 2024, at 20:55, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Add common requirements for a physical device assignment to Arm64
and AMD64 PVH domains.
Signed
On 08.10.24 09:17, Bertrand Marquis wrote:
Hi,
Hello Bertrand
On 7 Oct 2024, at 20:55, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Add common requirements for a physical device assignment to Arm64
and AMD64 PVH domains.
Signed-off-by: Oleksandr Tyshchenko
---
Based on
From: Oleksandr Tyshchenko
Add common requirements for a physical device assignment to Arm64
and AMD64 PVH domains.
Signed-off-by: Oleksandr Tyshchenko
---
Based on:
[PATCH] docs: fusa: Replace VM with domain
https://patchew.org/Xen/20241007182603.826807-1-ayan.kumar.hal...@amd.com
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
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 requires
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
ncrement 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/even
t;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, typica
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
+++ b/docs/man/xl-disk-confi
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 and
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 and
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 and
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 Co
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 try
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
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
xen_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 xen_irq_in
IRQT_EVTCHN);
> + 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.
: 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
ich
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
--
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 -0700,
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
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
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
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 noti
> 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 feature (I woul
hange 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 c
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 = pdev
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
_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 wit
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 IOCT
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 i
idge->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
bxl: 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/li
device1a", 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 gener
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
eZwknAWwxJ_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
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 Car
s2jnqcieZUZnc6cPwh7Ta8hiLRKwS1Gs-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 --gi
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 DM
that memory region actually 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 registration&quo
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, kernel_zim
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 wa
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 is
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
er 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, &virtio->backend_domid);
+if (rc) goto out;
+
+rc = libxl__parse_backend_path(gc, be_path, &dev);
+if (rc) goto out;
The same quest
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"]
Sig
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:
virt
quot; 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
> --
> + - Add 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
using reserved regions from Guest OS interface (arch-arm.h):
- GUEST_VPCI_MEM_ADDR (GUEST_VPCI_MEM_SIZE)
- GUEST_VPCI_ECAM_BASE (GUEST_VPCI_ECAM_SIZE)
- GUEST_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
1 - 100 of 698 matches
Mail list logo
