Properly emulate the full register")
Signed-off-by: Oleksandr Tyshchenko
---
xen/arch/arm/vgic-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index f20249f731..4369c55177 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arc
: c4d6bbdc12e5 ("xen/arm: vgic-v3: Support 32-bit access for 64-bit
registers")
Signed-off-by: Oleksandr Tyshchenko
Acked-by: Julien Grall
---
V2:
- s/data about/guest data abort in the description
- add A-b
- move goto to the next line
---
---
xen/arch/arm/vgic-v3.c | 3 ++-
1 fi
On 20.05.25 18:02, Julien Grall wrote:
> Hi Oleksandr,
Hello Julien
>
> On 20/05/2025 14:47, Oleksandr Tyshchenko wrote:
>> An attempt to write access the register (i.e. GICR_PROPBASER,
>> GICR_PENDBASER)
>> which should be ignored (i.e. no virtual ITS present
On 20.05.25 17:24, Andrew Cooper wrote:
Hello Andrew
> On 20/05/2025 2:47 pm, Oleksandr Tyshchenko wrote:
>> An attempt to write access the register (i.e. GICR_PROPBASER, GICR_PENDBASER)
>> which should be ignored (i.e. no virtual ITS present) causes the data about
>
> Do
2-bit access for 64-bit
registers")
Signed-off-by: Oleksandr Tyshchenko
---
xen/arch/arm/vgic-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 2eaa48fadb..b366b046a2 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm
On 27.03.25 00:39, Julien Grall wrote:
> Hi Oleksandr,
Hello Julien
>
> On 26/03/2025 11:45, Oleksandr Tyshchenko wrote:
>> Also it is not entirely clear what we should do with acpi_disabled=true
>> during declaration (what current patch does), even if we decided to
On 27.03.25 00:33, Julien Grall wrote:
Hello Julien
> Hi,
>
> On 26/03/2025 08:57, Orzel, Michal wrote:
>>
>>
>> On 25/03/2025 17:54, Oleksandr Tyshchenko wrote:
>>>
>>>
>>> On 25.03.25 18:09, Julien Grall wrote:
>>>
>>>
On 26.03.25 10:57, Orzel, Michal wrote:
Hello Michal, Julien
>
>
> On 25/03/2025 17:54, Oleksandr Tyshchenko wrote:
>>
>>
>> On 25.03.25 18:09, Julien Grall wrote:
>>
>>
>>> Hi Oleksandr,
>>
>> Hello Julien
>>
>>&g
On 19.03.25 14:37, Jan Beulich wrote:
Hello Jan, all.
On 19.03.2025 13:05, Mykyta Poturai wrote:
On 18.03.25 16:26, Jan Beulich wrote:
On 18.03.2025 14:31, Mykyta Poturai wrote:
On 18.03.25 12:11, Jan Beulich wrote:
On 18.03.2025 10:10, Mykyta Poturai wrote:
On 15.01.24 11:35, Jan Beul
en().
Signed-off-by: Oleksandr Tyshchenko
---
The RFC since I am not sure whether the description is precise
and the fix is correct.
Below the dump, w/o and w/ the fix applied. I also added prints
for the processed memory ranges with "OT:" for the visibility:
On 25.03.25 18:09, Julien Grall wrote:
> Hi Oleksandr,
Hello Julien
>
> On 25/03/2025 16:05, Oleksandr Tyshchenko wrote:
>>>>> Furthermore, what happen if we decide to use ACPI afterwards? Wouldn't
>>>>> this mean that the static regions w
On 25.03.25 17:47, Julien Grall wrote:
Hello Julien, Michal.
> Hi Michal,
>
> On 25/03/2025 15:35, Orzel, Michal wrote:
>>
>>
>> On 25/03/2025 16:23, Julien Grall wrote:
>>>
>>>
>>> Hi Oleksandr, Michal,
>>>
>>> On 25/
an issue and match to acpi_boot_table_init().
Suggested-by: Michal Orzel
Signed-off-by: Oleksandr Tyshchenko
---
V2:
- drop post-commit remark
- use the approach suggested by Michal
- update commit subject (WAS xen/device-tree: Switch back to
dt_unreserved_regions() in boot allocator
On 25.03.25 10:46, Orzel, Michal wrote:
Hello Michal
>
>
> On 24/03/2025 22:27, Oleksandr Tyshchenko wrote:
>>
>>
>> On the device-tree-based Arm64 system, if Xen is built with
>> CONFIG_ACPI=y, CONFIG_STATIC_MEMORY=y, and the static memory range
>> i
Hello all.
Please, ignore this second email, it was sent by mistake.
--
Regards,
Oleksandr Tyshchenko
en().
Signed-off-by: Oleksandr Tyshchenko
---
The RFC since I am not sure whether the description is precise
and the fix is correct.
Below the dump, w/o and w/ the fix applied. I also added prints
for the processed memory ranges with "OT:" for the visibility:
On 20.03.25 09:30, Jan Beulich wrote:
Hello Jan, Mykyta, all
On 19.03.2025 21:42, Oleksandr Tyshchenko wrote:
On 19.03.25 14:37, Jan Beulich wrote:
On 19.03.2025 13:05, Mykyta Poturai wrote:
On 18.03.25 16:26, Jan Beulich wrote:
On 18.03.2025 14:31, Mykyta Poturai wrote:
On 18.03.25
From: Oleksandr Tyshchenko
This is actually what the caller acquire_resource() expects on any kind
of error (the comment on top of resource_max_frames() also suggests that).
Otherwise, the caller will treat -errno as a valid value and propagate incorrect
nr_frames to the VM. As a possible
On 17.02.25 23:09, Andrew Cooper wrote:
Hello.
On 17/02/2025 8:48 pm, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
The sign of the presence of a corresponding bugfix is an error
returned on querying the size of an unknown for Xen resource type.
Signed-off-by: Oleksandr
From: Oleksandr Tyshchenko
The sign of the presence of a corresponding bugfix is an error
returned on querying the size of an unknown for Xen resource type.
Signed-off-by: Oleksandr Tyshchenko
---
Refer https://patchew.org/Xen/20250217102741.4122367-1-olekst...@gmail.com/
Current patch should
On 17.02.25 15:52, Andrew Cooper wrote:
Hello
On 17/02/2025 1:11 pm, Oleksandr Tyshchenko wrote:
On 17.02.25 13:09, Andrew Cooper wrote:
Hello Andrew
On 17/02/2025 10:27 am, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This is actually what the caller acquire_resource
On 17.02.25 13:09, Andrew Cooper wrote:
Hello Andrew
On 17/02/2025 10:27 am, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This is actually what the caller acquire_resource() expects on any kind
of error (the comment on top of resource_max_frames() also suggests that
From: Oleksandr Tyshchenko
This is actually what the caller acquire_resource() expects on any kind
of error (the comment on top of resource_max_frames() also suggests that).
Otherwise, the caller will treat -errno as a valid value and propagate incorrect
nr_frames to the VM. As a possible
On 17.02.25 11:18, Jan Beulich wrote:
Hello Jan
On 16.02.2025 22:19, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
This is actually what the caller acquire_resource() expects on any kind
of error (the comment on top of resource_max_frames() also suggests that).
Otherwise, the
From: Oleksandr Tyshchenko
This is actually what the caller acquire_resource() expects on any kind
of error (the comment on top of resource_max_frames() also suggests that).
Otherwise, the caller will treat -errno as a valid value and propagate incorrect
nr_frames to the VM. As a possible
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
1 - 100 of 723 matches
Mail list logo
