0'
> then
> AArch64.SystemAccessTrap(EL2, 0x18);
>
> Changes in v2:
> - drop block and fall through to avoid duplication
The V2 also works, so my tag is still valid:
[with Zephyr running as Xen guest and accessing CNTPCT_EL0 from EL0]
Tested-by: Oleksandr Tyshche
[with Zephyr running as Xen guest and accessing CNTPCT_EL0 from EL0 ]
Tested-by: Oleksandr Tyshchenko
> ---
> This is now in conformance to ARM ARM CNTPCT_EL0 pseudocode:
> if PSTATE.EL == EL0 then
> ...
> elif EL2Enabled() && HCR_EL2.E2H == '0' && CNTHC
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
