* (no subject)
@ 2022-11-18 2:00 Jiamei Xie
2022-11-18 2:18 ` [PATCH] xen/arm: vpl011: Make access to DMACR write-ignore Jiamei Xie
2022-11-18 7:47 ` Michal Orzel
0 siblings, 2 replies; 8+ messages in thread
From: Jiamei Xie @ 2022-11-18 2:00 UTC (permalink / raw)
To: xen-devel
Cc: Jiamei Xie, Stefano Stabellini, Julien Grall, Bertrand Marquis,
Volodymyr Babchuk, Wei Chen
Date: Thu, 17 Nov 2022 11:07:12 +0800
Subject: [PATCH] xen/arm: vpl011: Make access to DMACR write-ignore
When the guest kernel enables DMA engine with "CONFIG_DMA_ENGINE=y",
Linux SBSA PL011 driver will access PL011 DMACR register in some
functions. As chapter "B Generic UART" in "ARM Server Base System
Architecture"[1] documentation describes, SBSA UART doesn't support
DMA. In current code, when the kernel tries to access DMACR register,
Xen will inject a data abort:
Unhandled fault at 0xffffffc00944d048
Mem abort info:
ESR = 0x96000000
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x00: ttbr address size fault
Data abort info:
ISV = 0, ISS = 0x00000000
CM = 0, WnR = 0
swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000020e2e000
[ffffffc00944d048] pgd=100000003ffff803, p4d=100000003ffff803, pud=100000003ffff803, pmd=100000003fffa803, pte=006800009c090f13
Internal error: ttbr address size fault: 96000000 [#1] PREEMPT SMP
...
Call trace:
pl011_stop_rx+0x70/0x80
tty_port_shutdown+0x7c/0xb4
tty_port_close+0x60/0xcc
uart_close+0x34/0x8c
tty_release+0x144/0x4c0
__fput+0x78/0x220
____fput+0x1c/0x30
task_work_run+0x88/0xc0
do_notify_resume+0x8d0/0x123c
el0_svc+0xa8/0xc0
el0t_64_sync_handler+0xa4/0x130
el0t_64_sync+0x1a0/0x1a4
Code: b9000083 b901f001 794038a0 8b000042 (b9000041)
---[ end trace 83dd93df15c3216f ]---
note: bootlogd[132] exited with preempt_count 1
/etc/rcS.d/S07bootlogd: line 47: 132 Segmentation fault start-stop-daemon
As discussed in [2], this commit makes the access to DMACR register
write-ignore as an improvement.
[1] https://developer.arm.com/documentation/den0094/c/?lang=en
[2] https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2211161552420.4020@ubuntu-linux-20-04-desktop/
Signed-off-by: Jiamei Xie <jiamei.xie@arm.com>
---
xen/arch/arm/vpl011.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 43522d48fd..80d00b3052 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -463,6 +463,7 @@ static int vpl011_mmio_write(struct vcpu *v,
case FR:
case RIS:
case MIS:
+ case DMACR:
goto write_ignore;
case IMSC:
--
2.25.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* RE: [PATCH] xen/arm: vpl011: Make access to DMACR write-ignore
2022-11-18 2:00 Jiamei Xie
@ 2022-11-18 2:18 ` Jiamei Xie
2022-11-18 7:41 ` Michal Orzel
2022-11-18 7:47 ` Michal Orzel
1 sibling, 1 reply; 8+ messages in thread
From: Jiamei Xie @ 2022-11-18 2:18 UTC (permalink / raw)
To: Jiamei Xie, xen-devel
Cc: Stefano Stabellini, Julien Grall, Bertrand Marquis,
Volodymyr Babchuk, Wei Chen
Hi
Sorry there is no subject in the last email. So add in this one.
Best wishes
Jiamei Xie
> -----Original Message-----
> From: Jiamei Xie <jiamei.xie@arm.com>
> Sent: Friday, November 18, 2022 10:00 AM
> To: xen-devel@lists.xenproject.org
> Cc: Jiamei Xie <Jiamei.Xie@arm.com>; Stefano Stabellini
> <sstabellini@kernel.org>; Julien Grall <julien@xen.org>; Bertrand Marquis
> <Bertrand.Marquis@arm.com>; Volodymyr Babchuk
> <Volodymyr_Babchuk@epam.com>; Wei Chen <Wei.Chen@arm.com>
> Subject:
>
> Date: Thu, 17 Nov 2022 11:07:12 +0800
> Subject: [PATCH] xen/arm: vpl011: Make access to DMACR write-ignore
>
> When the guest kernel enables DMA engine with
> "CONFIG_DMA_ENGINE=y",
> Linux SBSA PL011 driver will access PL011 DMACR register in some
> functions. As chapter "B Generic UART" in "ARM Server Base System
> Architecture"[1] documentation describes, SBSA UART doesn't support
> DMA. In current code, when the kernel tries to access DMACR register,
> Xen will inject a data abort:
> Unhandled fault at 0xffffffc00944d048
> Mem abort info:
> ESR = 0x96000000
> EC = 0x25: DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> FSC = 0x00: ttbr address size fault
> Data abort info:
> ISV = 0, ISS = 0x00000000
> CM = 0, WnR = 0
> swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000020e2e000
> [ffffffc00944d048] pgd=100000003ffff803, p4d=100000003ffff803,
> pud=100000003ffff803, pmd=100000003fffa803, pte=006800009c090f13
> Internal error: ttbr address size fault: 96000000 [#1] PREEMPT SMP
> ...
> Call trace:
> pl011_stop_rx+0x70/0x80
> tty_port_shutdown+0x7c/0xb4
> tty_port_close+0x60/0xcc
> uart_close+0x34/0x8c
> tty_release+0x144/0x4c0
> __fput+0x78/0x220
> ____fput+0x1c/0x30
> task_work_run+0x88/0xc0
> do_notify_resume+0x8d0/0x123c
> el0_svc+0xa8/0xc0
> el0t_64_sync_handler+0xa4/0x130
> el0t_64_sync+0x1a0/0x1a4
> Code: b9000083 b901f001 794038a0 8b000042 (b9000041)
> ---[ end trace 83dd93df15c3216f ]---
> note: bootlogd[132] exited with preempt_count 1
> /etc/rcS.d/S07bootlogd: line 47: 132 Segmentation fault start-stop-daemon
>
> As discussed in [2], this commit makes the access to DMACR register
> write-ignore as an improvement.
>
> [1] https://developer.arm.com/documentation/den0094/c/?lang=en
> [2] https://lore.kernel.org/xen-
> devel/alpine.DEB.2.22.394.2211161552420.4020@ubuntu-linux-20-04-
> desktop/
>
> Signed-off-by: Jiamei Xie <jiamei.xie@arm.com>
> ---
> xen/arch/arm/vpl011.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> index 43522d48fd..80d00b3052 100644
> --- a/xen/arch/arm/vpl011.c
> +++ b/xen/arch/arm/vpl011.c
> @@ -463,6 +463,7 @@ static int vpl011_mmio_write(struct vcpu *v,
> case FR:
> case RIS:
> case MIS:
> + case DMACR:
> goto write_ignore;
>
> case IMSC:
> --
> 2.25.1
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] xen/arm: vpl011: Make access to DMACR write-ignore
2022-11-18 2:18 ` [PATCH] xen/arm: vpl011: Make access to DMACR write-ignore Jiamei Xie
@ 2022-11-18 7:41 ` Michal Orzel
2022-11-18 8:34 ` Jiamei Xie
0 siblings, 1 reply; 8+ messages in thread
From: Michal Orzel @ 2022-11-18 7:41 UTC (permalink / raw)
To: Jiamei Xie, xen-devel
Cc: Stefano Stabellini, Julien Grall, Bertrand Marquis,
Volodymyr Babchuk, Wei Chen
Hi Jiamei,
On 18/11/2022 03:18, Jiamei Xie wrote:
>
>
> Hi
>
> Sorry there is no subject in the last email. So add in this one.
I would consider re-pushing this patch(although please wait for some comments).
The reason being, a patch without a subject is not picked by patchwork/b4 or other
tools used to grab a patch.
~Michal
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [PATCH] xen/arm: vpl011: Make access to DMACR write-ignore
2022-11-18 7:41 ` Michal Orzel
@ 2022-11-18 8:34 ` Jiamei Xie
0 siblings, 0 replies; 8+ messages in thread
From: Jiamei Xie @ 2022-11-18 8:34 UTC (permalink / raw)
To: Michal Orzel, xen-devel
Cc: Stefano Stabellini, Julien Grall, Bertrand Marquis,
Volodymyr Babchuk, Wei Chen
Hi Michal,
> -----Original Message-----
> From: Michal Orzel <michal.orzel@amd.com>
> Sent: Friday, November 18, 2022 3:42 PM
> To: Jiamei Xie <Jiamei.Xie@arm.com>; xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini <sstabellini@kernel.org>; Julien Grall <julien@xen.org>;
> Bertrand Marquis <Bertrand.Marquis@arm.com>; Volodymyr Babchuk
> <Volodymyr_Babchuk@epam.com>; Wei Chen <Wei.Chen@arm.com>
> Subject: Re: [PATCH] xen/arm: vpl011: Make access to DMACR write-ignore
>
> Hi Jiamei,
>
> On 18/11/2022 03:18, Jiamei Xie wrote:
> >
> >
> > Hi
> >
> > Sorry there is no subject in the last email. So add in this one.
> I would consider re-pushing this patch(although please wait for some
> comments).
> The reason being, a patch without a subject is not picked by patchwork/b4 or
> other
> tools used to grab a patch.
Got it, thanks!
Best wishes
Jiamei Xie
>
> ~Michal
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re:
2022-11-18 2:00 Jiamei Xie
2022-11-18 2:18 ` [PATCH] xen/arm: vpl011: Make access to DMACR write-ignore Jiamei Xie
@ 2022-11-18 7:47 ` Michal Orzel
2022-11-18 9:02 ` Re: Julien Grall
1 sibling, 1 reply; 8+ messages in thread
From: Michal Orzel @ 2022-11-18 7:47 UTC (permalink / raw)
To: Jiamei Xie, xen-devel
Cc: Stefano Stabellini, Julien Grall, Bertrand Marquis,
Volodymyr Babchuk, Wei Chen
Hi Jimaei,
On 18/11/2022 03:00, Jiamei Xie wrote:
>
>
> Date: Thu, 17 Nov 2022 11:07:12 +0800
> Subject: [PATCH] xen/arm: vpl011: Make access to DMACR write-ignore
>
> When the guest kernel enables DMA engine with "CONFIG_DMA_ENGINE=y",
> Linux SBSA PL011 driver will access PL011 DMACR register in some
> functions. As chapter "B Generic UART" in "ARM Server Base System
> Architecture"[1] documentation describes, SBSA UART doesn't support
> DMA. In current code, when the kernel tries to access DMACR register,
> Xen will inject a data abort:
> Unhandled fault at 0xffffffc00944d048
> Mem abort info:
> ESR = 0x96000000
> EC = 0x25: DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> FSC = 0x00: ttbr address size fault
> Data abort info:
> ISV = 0, ISS = 0x00000000
> CM = 0, WnR = 0
> swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000020e2e000
> [ffffffc00944d048] pgd=100000003ffff803, p4d=100000003ffff803, pud=100000003ffff803, pmd=100000003fffa803, pte=006800009c090f13
> Internal error: ttbr address size fault: 96000000 [#1] PREEMPT SMP
> ...
> Call trace:
> pl011_stop_rx+0x70/0x80
> tty_port_shutdown+0x7c/0xb4
> tty_port_close+0x60/0xcc
> uart_close+0x34/0x8c
> tty_release+0x144/0x4c0
> __fput+0x78/0x220
> ____fput+0x1c/0x30
> task_work_run+0x88/0xc0
> do_notify_resume+0x8d0/0x123c
> el0_svc+0xa8/0xc0
> el0t_64_sync_handler+0xa4/0x130
> el0t_64_sync+0x1a0/0x1a4
> Code: b9000083 b901f001 794038a0 8b000042 (b9000041)
> ---[ end trace 83dd93df15c3216f ]---
> note: bootlogd[132] exited with preempt_count 1
> /etc/rcS.d/S07bootlogd: line 47: 132 Segmentation fault start-stop-daemon
>
> As discussed in [2], this commit makes the access to DMACR register
> write-ignore as an improvement.
As discussed earlier, if we decide to improve vpl011 (for now only Stefano shared his opinion),
then we need to mark *all* the PL011 registers that are not part of SBSA ar RAZ/WI. So handling
DMACR and only for writes is not beneficial (it is only fixing current Linux issue, but what we
really want is to improve the code in general).
>
> [1] https://developer.arm.com/documentation/den0094/c/?lang=en
> [2] https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2211161552420.4020@ubuntu-linux-20-04-desktop/
>
> Signed-off-by: Jiamei Xie <jiamei.xie@arm.com>
> ---
> xen/arch/arm/vpl011.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> index 43522d48fd..80d00b3052 100644
> --- a/xen/arch/arm/vpl011.c
> +++ b/xen/arch/arm/vpl011.c
> @@ -463,6 +463,7 @@ static int vpl011_mmio_write(struct vcpu *v,
> case FR:
> case RIS:
> case MIS:
> + case DMACR:
> goto write_ignore;
>
> case IMSC:
> --
> 2.25.1
>
>
~Michal
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re:
2022-11-18 7:47 ` Michal Orzel
@ 2022-11-18 9:02 ` Julien Grall
0 siblings, 0 replies; 8+ messages in thread
From: Julien Grall @ 2022-11-18 9:02 UTC (permalink / raw)
To: Michal Orzel, Jiamei Xie, xen-devel
Cc: Stefano Stabellini, Bertrand Marquis, Volodymyr Babchuk, Wei Chen
On 18/11/2022 07:47, Michal Orzel wrote:
> On 18/11/2022 03:00, Jiamei Xie wrote:
>>
>>
>> Date: Thu, 17 Nov 2022 11:07:12 +0800
>> Subject: [PATCH] xen/arm: vpl011: Make access to DMACR write-ignore
>>
>> When the guest kernel enables DMA engine with "CONFIG_DMA_ENGINE=y",
>> Linux SBSA PL011 driver will access PL011 DMACR register in some
>> functions. As chapter "B Generic UART" in "ARM Server Base System
>> Architecture"[1] documentation describes, SBSA UART doesn't support
>> DMA. In current code, when the kernel tries to access DMACR register,
>> Xen will inject a data abort:
>> Unhandled fault at 0xffffffc00944d048
>> Mem abort info:
>> ESR = 0x96000000
>> EC = 0x25: DABT (current EL), IL = 32 bits
>> SET = 0, FnV = 0
>> EA = 0, S1PTW = 0
>> FSC = 0x00: ttbr address size fault
>> Data abort info:
>> ISV = 0, ISS = 0x00000000
>> CM = 0, WnR = 0
>> swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000020e2e000
>> [ffffffc00944d048] pgd=100000003ffff803, p4d=100000003ffff803, pud=100000003ffff803, pmd=100000003fffa803, pte=006800009c090f13
>> Internal error: ttbr address size fault: 96000000 [#1] PREEMPT SMP
>> ...
>> Call trace:
>> pl011_stop_rx+0x70/0x80
>> tty_port_shutdown+0x7c/0xb4
>> tty_port_close+0x60/0xcc
>> uart_close+0x34/0x8c
>> tty_release+0x144/0x4c0
>> __fput+0x78/0x220
>> ____fput+0x1c/0x30
>> task_work_run+0x88/0xc0
>> do_notify_resume+0x8d0/0x123c
>> el0_svc+0xa8/0xc0
>> el0t_64_sync_handler+0xa4/0x130
>> el0t_64_sync+0x1a0/0x1a4
>> Code: b9000083 b901f001 794038a0 8b000042 (b9000041)
>> ---[ end trace 83dd93df15c3216f ]---
>> note: bootlogd[132] exited with preempt_count 1
>> /etc/rcS.d/S07bootlogd: line 47: 132 Segmentation fault start-stop-daemon
>>
>> As discussed in [2], this commit makes the access to DMACR register
>> write-ignore as an improvement.
> As discussed earlier, if we decide to improve vpl011 (for now only Stefano shared his opinion),
> then we need to mark *all* the PL011 registers that are not part of SBSA ar RAZ/WI.
I would be fine to that. But I would like us to print a message using
XENLOG_G_DEBUG to catch any OS that would touch those registers.
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 8+ messages in thread
* (no subject)
@ 2020-11-30 10:31 Oleksandr Tyshchenko
2020-11-30 16:21 ` Alex Bennée
0 siblings, 1 reply; 8+ messages in thread
From: Oleksandr Tyshchenko @ 2020-11-30 10:31 UTC (permalink / raw)
To: xen-devel
Cc: Oleksandr Tyshchenko, Paul Durrant, Jan Beulich, Andrew Cooper,
Roger Pau Monné,
Wei Liu, Julien Grall, George Dunlap, Ian Jackson, Julien Grall,
Stefano Stabellini, Tim Deegan, Daniel De Graaf,
Volodymyr Babchuk, Jun Nakajima, Kevin Tian, Anthony PERARD,
Bertrand Marquis, Wei Chen, Kaly Xin, Artem Mygaiev,
Alex Bennée
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Date: Sat, 28 Nov 2020 22:33:51 +0200
Subject: [PATCH V3 00/23] IOREQ feature (+ virtio-mmio) on Arm
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Hello all.
The purpose of this patch series is to add IOREQ/DM support to Xen on Arm.
You can find an initial discussion at [1] and RFC/V1/V2 series at [2]/[3]/[4].
Xen on Arm requires some implementation to forward guest MMIO access to a device
model in order to implement virtio-mmio backend or even mediator outside of hypervisor.
As Xen on x86 already contains required support this series tries to make it common
and introduce Arm specific bits plus some new functionality. Patch series is based on
Julien's PoC "xen/arm: Add support for Guest IO forwarding to a device emulator".
Besides splitting existing IOREQ/DM support and introducing Arm side, the series
also includes virtio-mmio related changes (last 2 patches for toolstack)
for the reviewers to be able to see how the whole picture could look like.
According to the initial discussion there are a few open questions/concerns
regarding security, performance in VirtIO solution:
1. virtio-mmio vs virtio-pci, SPI vs MSI, different use-cases require different
transport...
2. virtio backend is able to access all guest memory, some kind of protection
is needed: 'virtio-iommu in Xen' vs 'pre-shared-memory & memcpys in guest'
3. interface between toolstack and 'out-of-qemu' virtio backend, avoid using
Xenstore in virtio backend if possible.
4. a lot of 'foreing mapping' could lead to the memory exhaustion, Julien
has some idea regarding that.
Looks like all of them are valid and worth considering, but the first thing
which we need on Arm is a mechanism to forward guest IO to a device emulator,
so let's focus on it in the first place.
***
There are a lot of changes since RFC series, almost all TODOs were resolved on Arm,
Arm code was improved and hardened, common IOREQ/DM code became really arch-agnostic
(without HVM-ism), the "legacy" mechanism of mapping magic pages for the IOREQ servers
was left x86 specific, etc. But one TODO still remains which is "PIO handling" on Arm.
The "PIO handling" TODO is expected to left unaddressed for the current series.
It is not an big issue for now while Xen doesn't have support for vPCI on Arm.
On Arm64 they are only used for PCI IO Bar and we would probably want to expose
them to emulator as PIO access to make a DM completely arch-agnostic. So "PIO handling"
should be implemented when we add support for vPCI.
I left interface untouched in the following patch
"xen/dm: Introduce xendevicemodel_set_irq_level DM op"
since there is still an open discussion what interface to use/what
information to pass to the hypervisor.
There is a patch on review this series depends on:
https://patchwork.kernel.org/patch/11816689
Please note, that IOREQ feature is disabled by default on Arm within current series.
***
Patch series [5] was rebased on recent "staging branch"
(181f2c2 evtchn: double per-channel locking can't hit identical channels) and tested on
Renesas Salvator-X board + H3 ES3.0 SoC (Arm64) with virtio-mmio disk backend [6]
running in driver domain and unmodified Linux Guest running on existing
virtio-blk driver (frontend). No issues were observed. Guest domain 'reboot/destroy'
use-cases work properly. Patch series was only build-tested on x86.
Please note, build-test passed for the following modes:
1. x86: CONFIG_HVM=y / CONFIG_IOREQ_SERVER=y (default)
2. x86: #CONFIG_HVM is not set / #CONFIG_IOREQ_SERVER is not set
3. Arm64: CONFIG_HVM=y / CONFIG_IOREQ_SERVER=y
4. Arm64: CONFIG_HVM=y / #CONFIG_IOREQ_SERVER is not set (default)
5. Arm32: CONFIG_HVM=y / CONFIG_IOREQ_SERVER=y
6. Arm32: CONFIG_HVM=y / #CONFIG_IOREQ_SERVER is not set (default)
***
Any feedback/help would be highly appreciated.
[1] https://lists.xenproject.org/archives/html/xen-devel/2020-07/msg00825.html
[2] https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg00071.html
[3] https://lists.xenproject.org/archives/html/xen-devel/2020-09/msg00732.html
[4] https://lists.xenproject.org/archives/html/xen-devel/2020-10/msg01077.html
[5] https://github.com/otyshchenko1/xen/commits/ioreq_4.14_ml4
[6] https://github.com/xen-troops/virtio-disk/commits/ioreq_ml1
Julien Grall (5):
xen/dm: Make x86's DM feature common
xen/mm: Make x86's XENMEM_resource_ioreq_server handling common
arm/ioreq: Introduce arch specific bits for IOREQ/DM features
xen/dm: Introduce xendevicemodel_set_irq_level DM op
libxl: Introduce basic virtio-mmio support on Arm
Oleksandr Tyshchenko (18):
x86/ioreq: Prepare IOREQ feature for making it common
x86/ioreq: Add IOREQ_STATUS_* #define-s and update code for moving
x86/ioreq: Provide out-of-line wrapper for the handle_mmio()
xen/ioreq: Make x86's IOREQ feature common
xen/ioreq: Make x86's hvm_ioreq_needs_completion() common
xen/ioreq: Make x86's hvm_mmio_first(last)_byte() common
xen/ioreq: Make x86's hvm_ioreq_(page/vcpu/server) structs common
xen/ioreq: Move x86's ioreq_server to struct domain
xen/ioreq: Move x86's io_completion/io_req fields to struct vcpu
xen/ioreq: Remove "hvm" prefixes from involved function names
xen/ioreq: Use guest_cmpxchg64() instead of cmpxchg()
xen/arm: Stick around in leave_hypervisor_to_guest until I/O has
completed
xen/mm: Handle properly reference in set_foreign_p2m_entry() on Arm
xen/ioreq: Introduce domain_has_ioreq_server()
xen/arm: io: Abstract sign-extension
xen/ioreq: Make x86's send_invalidate_req() common
xen/arm: Add mapcache invalidation handling
[RFC] libxl: Add support for virtio-disk configuration
MAINTAINERS | 8 +-
tools/include/xendevicemodel.h | 4 +
tools/libs/devicemodel/core.c | 18 +
tools/libs/devicemodel/libxendevicemodel.map | 1 +
tools/libs/light/Makefile | 1 +
tools/libs/light/libxl_arm.c | 94 +-
tools/libs/light/libxl_create.c | 1 +
tools/libs/light/libxl_internal.h | 1 +
tools/libs/light/libxl_types.idl | 16 +
tools/libs/light/libxl_types_internal.idl | 1 +
tools/libs/light/libxl_virtio_disk.c | 109 +++
tools/xl/Makefile | 2 +-
tools/xl/xl.h | 3 +
tools/xl/xl_cmdtable.c | 15 +
tools/xl/xl_parse.c | 116 +++
tools/xl/xl_virtio_disk.c | 46 +
xen/arch/arm/Makefile | 2 +
xen/arch/arm/dm.c | 89 ++
xen/arch/arm/domain.c | 9 +
xen/arch/arm/hvm.c | 4 +
xen/arch/arm/io.c | 29 +-
xen/arch/arm/ioreq.c | 126 +++
xen/arch/arm/p2m.c | 48 +-
xen/arch/arm/traps.c | 58 +-
xen/arch/x86/Kconfig | 1 +
xen/arch/x86/hvm/dm.c | 295 +-----
xen/arch/x86/hvm/emulate.c | 80 +-
xen/arch/x86/hvm/hvm.c | 12 +-
xen/arch/x86/hvm/hypercall.c | 9 +-
xen/arch/x86/hvm/intercept.c | 5 +-
xen/arch/x86/hvm/io.c | 26 +-
xen/arch/x86/hvm/ioreq.c | 1357 ++------------------------
xen/arch/x86/hvm/stdvga.c | 10 +-
xen/arch/x86/hvm/svm/nestedsvm.c | 2 +-
xen/arch/x86/hvm/vmx/realmode.c | 6 +-
xen/arch/x86/hvm/vmx/vvmx.c | 2 +-
xen/arch/x86/mm.c | 46 +-
xen/arch/x86/mm/p2m.c | 13 +-
xen/arch/x86/mm/shadow/common.c | 2 +-
xen/common/Kconfig | 3 +
xen/common/Makefile | 2 +
xen/common/dm.c | 292 ++++++
xen/common/ioreq.c | 1307 +++++++++++++++++++++++++
xen/common/memory.c | 73 +-
xen/include/asm-arm/domain.h | 3 +
xen/include/asm-arm/hvm/ioreq.h | 139 +++
xen/include/asm-arm/mm.h | 8 -
xen/include/asm-arm/mmio.h | 1 +
xen/include/asm-arm/p2m.h | 19 +-
xen/include/asm-arm/traps.h | 24 +
xen/include/asm-x86/hvm/domain.h | 43 -
xen/include/asm-x86/hvm/emulate.h | 2 +-
xen/include/asm-x86/hvm/io.h | 17 -
xen/include/asm-x86/hvm/ioreq.h | 58 +-
xen/include/asm-x86/hvm/vcpu.h | 18 -
xen/include/asm-x86/mm.h | 4 -
xen/include/asm-x86/p2m.h | 24 +-
xen/include/public/arch-arm.h | 5 +
xen/include/public/hvm/dm_op.h | 16 +
xen/include/xen/dm.h | 44 +
xen/include/xen/ioreq.h | 146 +++
xen/include/xen/p2m-common.h | 4 +
xen/include/xen/sched.h | 32 +
xen/include/xsm/dummy.h | 4 +-
xen/include/xsm/xsm.h | 6 +-
xen/xsm/dummy.c | 2 +-
xen/xsm/flask/hooks.c | 5 +-
67 files changed, 3084 insertions(+), 1884 deletions(-)
create mode 100644 tools/libs/light/libxl_virtio_disk.c
create mode 100644 tools/xl/xl_virtio_disk.c
create mode 100644 xen/arch/arm/dm.c
create mode 100644 xen/arch/arm/ioreq.c
create mode 100644 xen/common/dm.c
create mode 100644 xen/common/ioreq.c
create mode 100644 xen/include/asm-arm/hvm/ioreq.h
create mode 100644 xen/include/xen/dm.h
create mode 100644 xen/include/xen/ioreq.h
--
2.7.4
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re:
2020-11-30 10:31 Oleksandr Tyshchenko
@ 2020-11-30 16:21 ` Alex Bennée
2020-12-29 15:32 ` Re: Roger Pau Monné
0 siblings, 1 reply; 8+ messages in thread
From: Alex Bennée @ 2020-11-30 16:21 UTC (permalink / raw)
To: Oleksandr Tyshchenko
Cc: xen-devel, Oleksandr Tyshchenko, Paul Durrant, Jan Beulich,
Andrew Cooper, Roger Pau Monné,
Wei Liu, Julien Grall, George Dunlap, Ian Jackson, Julien Grall,
Stefano Stabellini, Tim Deegan, Daniel De Graaf,
Volodymyr Babchuk, Jun Nakajima, Kevin Tian, Anthony PERARD,
Bertrand Marquis, Wei Chen, Kaly Xin, Artem Mygaiev
Oleksandr Tyshchenko <olekstysh@gmail.com> writes:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
>
> Date: Sat, 28 Nov 2020 22:33:51 +0200
> Subject: [PATCH V3 00/23] IOREQ feature (+ virtio-mmio) on Arm
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Hello all.
>
> The purpose of this patch series is to add IOREQ/DM support to Xen on Arm.
> You can find an initial discussion at [1] and RFC/V1/V2 series at [2]/[3]/[4].
> Xen on Arm requires some implementation to forward guest MMIO access to a device
> model in order to implement virtio-mmio backend or even mediator outside of hypervisor.
> As Xen on x86 already contains required support this series tries to make it common
> and introduce Arm specific bits plus some new functionality. Patch series is based on
> Julien's PoC "xen/arm: Add support for Guest IO forwarding to a device emulator".
> Besides splitting existing IOREQ/DM support and introducing Arm side, the series
> also includes virtio-mmio related changes (last 2 patches for toolstack)
> for the reviewers to be able to see how the whole picture could look
> like.
Thanks for posting the latest version.
>
> According to the initial discussion there are a few open questions/concerns
> regarding security, performance in VirtIO solution:
> 1. virtio-mmio vs virtio-pci, SPI vs MSI, different use-cases require different
> transport...
I think I'm repeating things here I've said in various ephemeral video
chats over the last few weeks but I should probably put things down on
the record.
I think the original intention of the virtio framers is advanced
features would build on virtio-pci because you get a bunch of things
"for free" - notably enumeration and MSI support. There is assumption
that by the time you add these features to virtio-mmio you end up
re-creating your own less well tested version of virtio-pci. I've not
been terribly convinced by the argument that the guest implementation of
PCI presents a sufficiently large blob of code to make the simpler MMIO
desirable. My attempts to build two virtio kernels (PCI/MMIO) with
otherwise the same devices wasn't terribly conclusive either way.
That said virtio-mmio still has life in it because the cloudy slimmed
down guests moved to using it because the enumeration of PCI is a road
block to their fast boot up requirements. I'm sure they would also
appreciate a MSI implementation to reduce the overhead that handling
notifications currently has on trap-and-emulate.
AIUI for Xen the other downside to PCI is you would have to emulate it
in the hypervisor which would be additional code at the most privileged
level.
> 2. virtio backend is able to access all guest memory, some kind of protection
> is needed: 'virtio-iommu in Xen' vs 'pre-shared-memory & memcpys in
> guest'
This is also an area of interest for Project Stratos and something we
would like to be solved generally for all hypervisors. There is a good
write up of some approaches that Jean Phillipe did on the stratos
mailing list:
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
Subject: Limited memory sharing investigation
Message-ID: <20201002134336.GA2196245@myrica>
I suspect there is a good argument for the simplicity of a combined
virt queue but it is unlikely to be very performance orientated.
> 3. interface between toolstack and 'out-of-qemu' virtio backend, avoid using
> Xenstore in virtio backend if possible.
I wonder how much work it would be for a rust expert to make:
https://github.com/slp/vhost-user-blk
handle an IOREQ signalling pathway instead of the vhost-user/eventfd
pathway? That would give a good indication on how "hypervisor blind"
these daemons could be made.
<snip>
>
> Please note, build-test passed for the following modes:
> 1. x86: CONFIG_HVM=y / CONFIG_IOREQ_SERVER=y (default)
> 2. x86: #CONFIG_HVM is not set / #CONFIG_IOREQ_SERVER is not set
> 3. Arm64: CONFIG_HVM=y / CONFIG_IOREQ_SERVER=y
Forgive my relative newness to Xen, how do I convince the hypervisor to
build with this on? I've tried variants of:
make -j9 CROSS_COMPILE=aarch64-linux-gnu- XEN_TARGET_ARCH=arm64 menuconfig XEN_EXPERT=y [CONFIG_|XEN_|_]IOREQ_SERVER=y
with no joy...
> 4. Arm64: CONFIG_HVM=y / #CONFIG_IOREQ_SERVER is not set (default)
> 5. Arm32: CONFIG_HVM=y / CONFIG_IOREQ_SERVER=y
> 6. Arm32: CONFIG_HVM=y / #CONFIG_IOREQ_SERVER is not set (default)
>
> ***
>
> Any feedback/help would be highly appreciated.
<snip>
--
Alex Bennée
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re:
2020-11-30 16:21 ` Alex Bennée
@ 2020-12-29 15:32 ` Roger Pau Monné
0 siblings, 0 replies; 8+ messages in thread
From: Roger Pau Monné @ 2020-12-29 15:32 UTC (permalink / raw)
To: Alex Bennée
Cc: Oleksandr Tyshchenko, xen-devel, Oleksandr Tyshchenko,
Paul Durrant, Jan Beulich, Andrew Cooper, Wei Liu, Julien Grall,
George Dunlap, Ian Jackson, Julien Grall, Stefano Stabellini,
Tim Deegan, Daniel De Graaf, Volodymyr Babchuk, Jun Nakajima,
Kevin Tian, Anthony PERARD, Bertrand Marquis, Wei Chen, Kaly Xin,
Artem Mygaiev
On Mon, Nov 30, 2020 at 04:21:59PM +0000, Alex Bennée wrote:
>
> Oleksandr Tyshchenko <olekstysh@gmail.com> writes:
>
> > From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> >
> >
> > Date: Sat, 28 Nov 2020 22:33:51 +0200
> > Subject: [PATCH V3 00/23] IOREQ feature (+ virtio-mmio) on Arm
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > Hello all.
> >
> > The purpose of this patch series is to add IOREQ/DM support to Xen on Arm.
> > You can find an initial discussion at [1] and RFC/V1/V2 series at [2]/[3]/[4].
> > Xen on Arm requires some implementation to forward guest MMIO access to a device
> > model in order to implement virtio-mmio backend or even mediator outside of hypervisor.
> > As Xen on x86 already contains required support this series tries to make it common
> > and introduce Arm specific bits plus some new functionality. Patch series is based on
> > Julien's PoC "xen/arm: Add support for Guest IO forwarding to a device emulator".
> > Besides splitting existing IOREQ/DM support and introducing Arm side, the series
> > also includes virtio-mmio related changes (last 2 patches for toolstack)
> > for the reviewers to be able to see how the whole picture could look
> > like.
>
> Thanks for posting the latest version.
>
> >
> > According to the initial discussion there are a few open questions/concerns
> > regarding security, performance in VirtIO solution:
> > 1. virtio-mmio vs virtio-pci, SPI vs MSI, different use-cases require different
> > transport...
>
> I think I'm repeating things here I've said in various ephemeral video
> chats over the last few weeks but I should probably put things down on
> the record.
>
> I think the original intention of the virtio framers is advanced
> features would build on virtio-pci because you get a bunch of things
> "for free" - notably enumeration and MSI support. There is assumption
> that by the time you add these features to virtio-mmio you end up
> re-creating your own less well tested version of virtio-pci. I've not
> been terribly convinced by the argument that the guest implementation of
> PCI presents a sufficiently large blob of code to make the simpler MMIO
> desirable. My attempts to build two virtio kernels (PCI/MMIO) with
> otherwise the same devices wasn't terribly conclusive either way.
>
> That said virtio-mmio still has life in it because the cloudy slimmed
> down guests moved to using it because the enumeration of PCI is a road
> block to their fast boot up requirements. I'm sure they would also
> appreciate a MSI implementation to reduce the overhead that handling
> notifications currently has on trap-and-emulate.
>
> AIUI for Xen the other downside to PCI is you would have to emulate it
> in the hypervisor which would be additional code at the most privileged
> level.
Xen already emulates (or maybe it would be better to say decodes) PCI
accesses on the hypervisor and forwards them to the appropriate device
model using the IOREQ interface, so that's not something new. It's
not really emulating the PCI config space, but just detecting accesses
and forwarding them to the device model that should handle them.
You can register different emulators in user space that handle
accesses to different PCI devices from a guest.
Thanks, Roger.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-11-18 9:03 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-18 2:00 Jiamei Xie
2022-11-18 2:18 ` [PATCH] xen/arm: vpl011: Make access to DMACR write-ignore Jiamei Xie
2022-11-18 7:41 ` Michal Orzel
2022-11-18 8:34 ` Jiamei Xie
2022-11-18 7:47 ` Michal Orzel
2022-11-18 9:02 ` Re: Julien Grall
-- strict thread matches above, loose matches on Subject: below --
2020-11-30 10:31 Oleksandr Tyshchenko
2020-11-30 16:21 ` Alex Bennée
2020-12-29 15:32 ` Re: Roger Pau Monné
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).