Re: [PATCH 0/2] Xen FF-A mediator
Hi Stefano, On Tue, Jun 7, 2022 at 11:55 PM Stefano Stabellini wrote: > > On Tue, 7 Jun 2022, Jens Wiklander wrote: > > Hi, > > > > This patch sets add a FF-A [1] mediator modeled after the TEE mediator > > already present in Xen. The FF-A mediator implements the subset of the FF-A > > 1.1 specification needed to communicate with OP-TEE using FF-A as transport > > mechanism instead of SMC/HVC as with the TEE mediator. It allows a similar > > design in OP-TEE as with the TEE mediator where OP-TEE presents one virtual > > partition of itself to each guest in Xen. > > > > The FF-A mediator is generic in the sense it has nothing OP-TEE specific > > except that only the subset needed for OP-TEE is implemented so far. The > > hooks needed to inform OP-TEE that a guest is created or destroyed is part > > of the FF-A specification. > > > > It should be possible to extend the FF-A mediator to implement a larger > > portion of the FF-A 1.1 specification without breaking with the way OP-TEE > > is communicated with here. So it should be possible to support any TEE or > > Secure Partition using FF-A as transport with this mediator. > > > > [1] https://developer.arm.com/documentation/den0077/latest > > > > Thanks, > > Jens > > Hi Jens, > > Many thanks for the patches! I tried to apply them to the master branch > but unfortunately they don't apply any longer. Could you please rebase > them on master (or even better rebase them on staging) and resend? No problem, I'll rebase and send out a v2. Thanks, Jens > > Thank you! > > > > > Jens Wiklander (2): > > xen/arm: smccc: add support for SMCCCv1.2 extended input/output > > registers > > xen/arm: add FF-A mediator > > > > xen/arch/arm/Kconfig | 11 + > > xen/arch/arm/Makefile|1 + > > xen/arch/arm/arm64/smc.S | 43 + > > xen/arch/arm/domain.c| 10 + > > xen/arch/arm/ffa.c | 1624 ++ > > xen/arch/arm/vsmc.c | 19 +- > > xen/include/asm-arm/domain.h |4 + > > xen/include/asm-arm/ffa.h| 71 ++ > > xen/include/asm-arm/smccc.h | 42 + > > 9 files changed, 1821 insertions(+), 4 deletions(-) > > create mode 100644 xen/arch/arm/ffa.c > > create mode 100644 xen/include/asm-arm/ffa.h >
Re: [PATCH] xen: unexport __init-annotated xen_xlate_map_ballooned_pages()
On 06.06.22 06:59, Masahiro Yamada wrote:
EXPORT_SYMBOL and __init is a bad combination because the .init.text
section is freed up after the initialization. Hence, modules cannot
use symbols annotated __init. The access to a freed symbol may end up
with kernel panic.
modpost used to detect it, but it has been broken for a decade.
Recently, I fixed modpost so it started to warn it again, then this
showed up in linux-next builds.
There are two ways to fix it:
- Remove __init
- Remove EXPORT_SYMBOL
I chose the latter for this case because none of the in-tree call-sites
(arch/arm/xen/enlighten.c, arch/x86/xen/grant-table.c) is compiled as
modular.
Fixes: 243848fc018c ("xen/grant-table: Move xlated_setup_gnttab_pages to common
place")
Reported-by: Stephen Rothwell
Signed-off-by: Masahiro Yamada
Pushed to xen/tip.git for-linus-5.19a
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH V4 0/8] virtio: Solution to restrict memory access under Xen using xen-grant DMA-mapping layer
On 02.06.22 21:23, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko Hello all. The purpose of this patch series is to add support for restricting memory access under Xen using specific grant table [1] based DMA-mapping layer. Patch series is based on Juergen Gross’ initial work [2] which implies using grant references instead of raw guest physical addresses (GPA) for the virtio communications (some kind of the software IOMMU). You can find RFC-V3 patch series (and previous discussions) at [3]. !!! Please note, the only diff between V3 and V4 is in commit #5, also I have collected the acks (commits ##4-7). The high level idea is to create new Xen’s grant table based DMA-mapping layer for the guest Linux whose main purpose is to provide a special 64-bit DMA address which is formed by using the grant reference (for a page to be shared with the backend) with offset and setting the highest address bit (this is for the backend to be able to distinguish grant ref based DMA address from normal GPA). For this to work we need the ability to allocate contiguous (consecutive) grant references for multi-page allocations. And the backend then needs to offer VIRTIO_F_ACCESS_PLATFORM and VIRTIO_F_VERSION_1 feature bits (it must support virtio-mmio modern transport for 64-bit addresses in the virtqueue). Xen's grant mapping mechanism is the secure and safe solution to share pages between domains which proven to work and works for years (in the context of traditional Xen PV drivers for example). So far, the foreign mapping is used for the virtio backend to map and access guest memory. With the foreign mapping, the backend is able to map arbitrary pages from the guest memory (or even from Dom0 memory). And as the result, the malicious backend which runs in a non-trusted domain can take advantage of this. Instead, with the grant mapping the backend is only allowed to map pages which were explicitly granted by the guest before and nothing else. According to the discussions in various mainline threads this solution would likely be welcome because it perfectly fits in the security model Xen provides. What is more, the grant table based solution requires zero changes to the Xen hypervisor itself at least with virtio-mmio and DT (in comparison, for example, with "foreign mapping + virtio-iommu" solution which would require the whole new complex emulator in hypervisor in addition to new functionality/hypercall to pass IOVA from the virtio backend running elsewhere to the hypervisor and translate it to the GPA before mapping into P2M or denying the foreign mapping request if no corresponding IOVA-GPA mapping present in the IOMMU page table for that particular device). We only need to update toolstack to insert "xen,grant-dma" IOMMU node (to be referred by the virtio-mmio device using "iommus" property) when creating a guest device-tree (this is an indicator for the guest to use Xen grant mappings scheme for that device with the endpoint ID being used as ID of Xen domain where the corresponding backend is running, the backend domid is used as an argument to the grant mapping APIs). It worth mentioning that toolstack patch is based on non upstreamed yet “Virtio support for toolstack on Arm” series which is on review now [4]. Please note the following: - Patch series only covers Arm and virtio-mmio (device-tree) for now. To enable the restricted memory access feature on Arm the following option should be set: CONFIG_XEN_VIRTIO=y - Patch series is based on "kernel: add new infrastructure for platform_has() support" patch series which is on review now [5] - Xen should be built with the following options: CONFIG_IOREQ_SERVER=y CONFIG_EXPERT=y Patch series is rebased on "for-linus-5.19" branch [1] with "platform_has()" series applied and tested on Renesas Salvator-X board + H3 ES3.0 SoC (Arm64) with standalone userspace (non-Qemu) virtio-mmio based virtio-disk backend running in Driver domain and Linux guest running on existing virtio-blk driver (frontend). No issues were observed. Guest domain 'reboot/destroy' use-cases work properly. I have also tested other use-cases such as assigning several virtio block devices or a mix of virtio and Xen PV block devices to the guest. Patch series was build-tested on Arm32 and x86. 1. Xen changes located at (last patch): https://github.com/otyshchenko1/xen/commits/libxl_virtio_next2_1 2. Linux changes located at (last 8 patches): https://github.com/otyshchenko1/linux/commits/virtio_grant9 3. virtio-disk changes located at: https://github.com/otyshchenko1/virtio-disk/commits/virtio_grant Any feedback/help would be highly appreciated. [1] https://xenbits.xenproject.org/docs/4.16-testing/misc/grant-tables.txt [2] https://www.youtube.com/watch?v=IrlEdaIUDPk [3] https://lore.kernel.org/xen-devel/1649963973-22879-1-git-send-email-olekst...@gmail.com/
[xen-unstable-smoke test] 170879: tolerable all pass - PUSHED
flight 170879 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/170879/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen 8c1cc69748f4719e6ba8a275c2ecd60747c52c21 baseline version: xen cea9ae06229577cd5b77019ce122f9cdd1568106 Last test of basis 170850 2022-06-06 18:00:31 Z1 days Testing same since 170879 2022-06-08 01:00:32 Z0 days1 attempts People who touched revisions under test: Bertrand Marquis Julien Grall Stefano Stabellini jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git cea9ae0622..8c1cc69748 8c1cc69748f4719e6ba8a275c2ecd60747c52c21 -> smoke
[xen-4.15-testing test] 170870: tolerable FAIL - PUSHED
flight 170870 xen-4.15-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/170870/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 169237 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 169237 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 169237 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 169237 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 169237 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 169237 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 169237 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 169237 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 169237 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 169237 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 169237 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 169237 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 169237 test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass
[PATCH Resend] xen/netback: do some code cleanup
Remove some unused macros and functions, make local functions static.
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
drivers/net/xen-netback/common.h| 12
drivers/net/xen-netback/interface.c | 16 +---
drivers/net/xen-netback/netback.c | 4 +++-
drivers/net/xen-netback/rx.c| 2 +-
4 files changed, 5 insertions(+), 29 deletions(-)
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index d9dea4829c86..8174d7b2966c 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -48,7 +48,6 @@
#include
typedef unsigned int pending_ring_idx_t;
-#define INVALID_PENDING_RING_IDX (~0U)
struct pending_tx_info {
struct xen_netif_tx_request req; /* tx request */
@@ -82,8 +81,6 @@ struct xenvif_rx_meta {
/* Discriminate from any valid pending_idx value. */
#define INVALID_PENDING_IDX 0x
-#define MAX_BUFFER_OFFSET XEN_PAGE_SIZE
-
#define MAX_PENDING_REQS XEN_NETIF_TX_RING_SIZE
/* The maximum number of frags is derived from the size of a grant (same
@@ -367,11 +364,6 @@ void xenvif_free(struct xenvif *vif);
int xenvif_xenbus_init(void);
void xenvif_xenbus_fini(void);
-int xenvif_schedulable(struct xenvif *vif);
-
-int xenvif_queue_stopped(struct xenvif_queue *queue);
-void xenvif_wake_queue(struct xenvif_queue *queue);
-
/* (Un)Map communication rings. */
void xenvif_unmap_frontend_data_rings(struct xenvif_queue *queue);
int xenvif_map_frontend_data_rings(struct xenvif_queue *queue,
@@ -394,7 +386,6 @@ int xenvif_dealloc_kthread(void *data);
irqreturn_t xenvif_ctrl_irq_fn(int irq, void *data);
bool xenvif_have_rx_work(struct xenvif_queue *queue, bool test_kthread);
-void xenvif_rx_action(struct xenvif_queue *queue);
void xenvif_rx_queue_tail(struct xenvif_queue *queue, struct sk_buff *skb);
void xenvif_carrier_on(struct xenvif *vif);
@@ -403,9 +394,6 @@ void xenvif_carrier_on(struct xenvif *vif);
void xenvif_zerocopy_callback(struct sk_buff *skb, struct ubuf_info *ubuf,
bool zerocopy_success);
-/* Unmap a pending page and release it back to the guest */
-void xenvif_idx_unmap(struct xenvif_queue *queue, u16 pending_idx);
-
static inline pending_ring_idx_t nr_pending_reqs(struct xenvif_queue *queue)
{
return MAX_PENDING_REQS -
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index 8e035374a370..fb32ae82d9b0 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -69,7 +69,7 @@ void xenvif_skb_zerocopy_complete(struct xenvif_queue *queue)
wake_up(>dealloc_wq);
}
-int xenvif_schedulable(struct xenvif *vif)
+static int xenvif_schedulable(struct xenvif *vif)
{
return netif_running(vif->dev) &&
test_bit(VIF_STATUS_CONNECTED, >status) &&
@@ -177,20 +177,6 @@ irqreturn_t xenvif_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
}
-int xenvif_queue_stopped(struct xenvif_queue *queue)
-{
- struct net_device *dev = queue->vif->dev;
- unsigned int id = queue->id;
- return netif_tx_queue_stopped(netdev_get_tx_queue(dev, id));
-}
-
-void xenvif_wake_queue(struct xenvif_queue *queue)
-{
- struct net_device *dev = queue->vif->dev;
- unsigned int id = queue->id;
- netif_tx_wake_queue(netdev_get_tx_queue(dev, id));
-}
-
static u16 xenvif_select_queue(struct net_device *dev, struct sk_buff *skb,
struct net_device *sb_dev)
{
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index d93814c14a23..fc61a4418737 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -112,6 +112,8 @@ static void make_tx_response(struct xenvif_queue *queue,
s8 st);
static void push_tx_responses(struct xenvif_queue *queue);
+static void xenvif_idx_unmap(struct xenvif_queue *queue, u16 pending_idx);
+
static inline int tx_work_todo(struct xenvif_queue *queue);
static inline unsigned long idx_to_pfn(struct xenvif_queue *queue,
@@ -1418,7 +1420,7 @@ static void push_tx_responses(struct xenvif_queue *queue)
notify_remote_via_irq(queue->tx_irq);
}
-void xenvif_idx_unmap(struct xenvif_queue *queue, u16 pending_idx)
+static void xenvif_idx_unmap(struct xenvif_queue *queue, u16 pending_idx)
{
int ret;
struct gnttab_unmap_grant_ref tx_unmap_op;
diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
index dbac4c03d21a..8df2c736fd23 100644
--- a/drivers/net/xen-netback/rx.c
+++ b/drivers/net/xen-netback/rx.c
@@ -486,7 +486,7 @@ static void xenvif_rx_skb(struct xenvif_queue *queue)
#define RX_BATCH_SIZE 64
-void xenvif_rx_action(struct xenvif_queue *queue)
+static void xenvif_rx_action(struct xenvif_queue *queue)
{
struct sk_buff_head completed_skbs;
unsigned int work_done = 0;
--
2.35.3
RE: [PATCH v2 3/3] x86/vmx: implement Notify VM Exit
> From: Roger Pau Monné
> Sent: Tuesday, June 7, 2022 6:06 PM
>
> On Tue, Jun 07, 2022 at 09:43:25AM +0200, Jan Beulich wrote:
> > On 03.06.2022 16:46, Roger Pau Monné wrote:
> > > On Fri, Jun 03, 2022 at 02:49:54PM +0200, Jan Beulich wrote:
> > >> On 26.05.2022 13:11, Roger Pau Monne wrote:
> > >>> --- a/xen/arch/x86/hvm/vmx/vmx.c
> > >>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > >>> @@ -1419,10 +1419,19 @@ static void cf_check
> vmx_update_host_cr3(struct vcpu *v)
> > >>>
> > >>> void vmx_update_debug_state(struct vcpu *v)
> > >>> {
> > >>> +unsigned int mask = 1u << TRAP_int3;
> > >>> +
> > >>> +if ( !cpu_has_monitor_trap_flag &&
> cpu_has_vmx_notify_vm_exiting )
> > >>
> > >> I'm puzzled by the lack of symmetry between this and ...
> > >>
> > >>> +/*
> > >>> + * Only allow toggling TRAP_debug if notify VM exit is
> > >>> enabled, as
> > >>> + * unconditionally setting TRAP_debug is part of the XSA-156
> > >>> fix.
> > >>> + */
> > >>> +mask |= 1u << TRAP_debug;
> > >>> +
> > >>> if ( v->arch.hvm.debug_state_latch )
> > >>> -v->arch.hvm.vmx.exception_bitmap |= 1U << TRAP_int3;
> > >>> +v->arch.hvm.vmx.exception_bitmap |= mask;
> > >>> else
> > >>> -v->arch.hvm.vmx.exception_bitmap &= ~(1U << TRAP_int3);
> > >>> +v->arch.hvm.vmx.exception_bitmap &= ~mask;
> > >>>
> > >>> vmx_vmcs_enter(v);
> > >>> vmx_update_exception_bitmap(v);
> > >>> @@ -4155,6 +4164,9 @@ void vmx_vmexit_handler(struct
> cpu_user_regs *regs)
> > >>> switch ( vector )
> > >>> {
> > >>> case TRAP_debug:
> > >>> +if ( cpu_has_monitor_trap_flag &&
> cpu_has_vmx_notify_vm_exiting )
> > >>> +goto exit_and_crash;
> > >>
> > >> ... this condition. Shouldn't one be the inverse of the other (and
> > >> then it's the one down here which wants adjusting)?
> > >
> > > The condition in vmx_update_debug_state() sets the mask so that
> > > TRAP_debug will only be added or removed from the bitmap if
> > > !cpu_has_monitor_trap_flag && cpu_has_vmx_notify_vm_exiting (note
> that
> > > otherwise TRAP_debug is unconditionally set if
> > > !cpu_has_vmx_notify_vm_exiting).
> > >
> > > Hence it's impossible to get a VMExit TRAP_debug with
> > > cpu_has_monitor_trap_flag && cpu_has_vmx_notify_vm_exiting because
> > > TRAP_debug will never be set by vmx_update_debug_state() in that
> > > case.
> >
> > Hmm, yes, I've been misguided by you not altering the existing setting
> > of v->arch.hvm.vmx.exception_bitmap in construct_vmcs(). Instead you
> > add an entirely new block of code near the bottom of the function. Is
> > there any chance you could move up that adjustment, perhaps along the
> > lines of
> >
> > v->arch.hvm.vmx.exception_bitmap = HVM_TRAP_MASK
> > | (paging_mode_hap(d) ? 0 : (1U << TRAP_page_fault))
> > | (v->arch.fully_eager_fpu ? 0 : (1U << TRAP_no_device));
> > if ( cpu_has_vmx_notify_vm_exiting )
> > {
> > __vmwrite(NOTIFY_WINDOW, vm_notify_window);
> > /*
> > * Disable #AC and #DB interception: by using VM Notify Xen is
> > * guaranteed to get a VM exit even if the guest manages to lock the
> > * CPU.
> > */
> > v->arch.hvm.vmx.exception_bitmap &= ~((1U << TRAP_debug) |
> > (1U << TRAP_alignment_check));
> > }
> > vmx_update_exception_bitmap(v);
>
> Sure, will move up when posting a new version then. I will wait for
> feedback from Jun or Kevin regarding the default window size before
> doing so.
>
let me check internally.
Re: [PATCH 16/16] xen/arm: mm: Re-implement setup_frame_table_mappings() with map_pages_to_xen()
On Fri, 20 May 2022, Julien Grall wrote:
> From: Julien Grall
>
> Now that map_pages_to_xen() has been extended to support 2MB mappings,
> we can replace the create_mappings() call by map_pages_to_xen() call.
>
> This has the advantage to remove the differences between 32-bit and
> 64-bit code.
>
> Lastly remove create_mappings() as there is no more callers.
>
> Signed-off-by: Julien Grall
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> Changes in v4:
> - Add missing _PAGE_BLOCK
>
> Changes in v3:
> - Fix typo in the commit message
> - Remove the TODO regarding contiguous bit
>
> Changes in v2:
> - New patch
> ---
> xen/arch/arm/mm.c | 64 +--
> 1 file changed, 6 insertions(+), 58 deletions(-)
>
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 65af44f42232..be37176a4725 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -369,40 +369,6 @@ void clear_fixmap(unsigned map)
> BUG_ON(res != 0);
> }
>
> -/* Create Xen's mappings of memory.
> - * Mapping_size must be either 2MB or 32MB.
> - * Base and virt must be mapping_size aligned.
> - * Size must be a multiple of mapping_size.
> - * second must be a contiguous set of second level page tables
> - * covering the region starting at virt_offset. */
> -static void __init create_mappings(lpae_t *second,
> - unsigned long virt_offset,
> - unsigned long base_mfn,
> - unsigned long nr_mfns,
> - unsigned int mapping_size)
> -{
> -unsigned long i, count;
> -const unsigned long granularity = mapping_size >> PAGE_SHIFT;
> -lpae_t pte, *p;
> -
> -ASSERT((mapping_size == MB(2)) || (mapping_size == MB(32)));
> -ASSERT(!((virt_offset >> PAGE_SHIFT) % granularity));
> -ASSERT(!(base_mfn % granularity));
> -ASSERT(!(nr_mfns % granularity));
> -
> -count = nr_mfns / XEN_PT_LPAE_ENTRIES;
> -p = second + second_linear_offset(virt_offset);
> -pte = mfn_to_xen_entry(_mfn(base_mfn), MT_NORMAL);
> -if ( granularity == 16 * XEN_PT_LPAE_ENTRIES )
> -pte.pt.contig = 1; /* These maps are in 16-entry contiguous chunks.
> */
> -for ( i = 0; i < count; i++ )
> -{
> -write_pte(p + i, pte);
> -pte.pt.base += 1 << XEN_PT_LPAE_SHIFT;
> -}
> -flush_xen_tlb_local();
> -}
> -
> #ifdef CONFIG_DOMAIN_PAGE
> void *map_domain_page_global(mfn_t mfn)
> {
> @@ -862,36 +828,18 @@ void __init setup_frametable_mappings(paddr_t ps,
> paddr_t pe)
> unsigned long frametable_size = nr_pdxs * sizeof(struct page_info);
> mfn_t base_mfn;
> const unsigned long mapping_size = frametable_size < MB(32) ? MB(2) :
> MB(32);
> -#ifdef CONFIG_ARM_64
> -lpae_t *second, pte;
> -unsigned long nr_second;
> -mfn_t second_base;
> -int i;
> -#endif
> +int rc;
>
> frametable_base_pdx = mfn_to_pdx(maddr_to_mfn(ps));
> /* Round up to 2M or 32M boundary, as appropriate. */
> frametable_size = ROUNDUP(frametable_size, mapping_size);
> base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 32<<(20-12));
>
> -#ifdef CONFIG_ARM_64
> -/* Compute the number of second level pages. */
> -nr_second = ROUNDUP(frametable_size, FIRST_SIZE) >> FIRST_SHIFT;
> -second_base = alloc_boot_pages(nr_second, 1);
> -second = mfn_to_virt(second_base);
> -for ( i = 0; i < nr_second; i++ )
> -{
> -clear_page(mfn_to_virt(mfn_add(second_base, i)));
> -pte = mfn_to_xen_entry(mfn_add(second_base, i), MT_NORMAL);
> -pte.pt.table = 1;
> -write_pte(_first[first_table_offset(FRAMETABLE_VIRT_START)+i],
> pte);
> -}
> -create_mappings(second, 0, mfn_x(base_mfn), frametable_size >>
> PAGE_SHIFT,
> -mapping_size);
> -#else
> -create_mappings(xen_second, FRAMETABLE_VIRT_START, mfn_x(base_mfn),
> -frametable_size >> PAGE_SHIFT, mapping_size);
> -#endif
> +rc = map_pages_to_xen(FRAMETABLE_VIRT_START, base_mfn,
> + frametable_size >> PAGE_SHIFT,
> + PAGE_HYPERVISOR_RW | _PAGE_BLOCK);
> +if ( rc )
> +panic("Unable to setup the frametable mappings.\n");
>
> memset(_table[0], 0, nr_pdxs * sizeof(struct page_info));
> memset(_table[nr_pdxs], -1,
> --
> 2.32.0
>
Re: [PATCH 09/16] xen/arm: Move fixmap definitions in a separate header
On Fri, 20 May 2022, Julien Grall wrote:
> From: Julien Grall
>
> To use properly the fixmap definitions, their user would need
> also new to include . This is not very great when
> the user itself is not meant to directly use ACPI definitions.
>
> Including in is not option because
> the latter header is included by everyone. So move out the fixmap
> entries definition in a new header.
>
> Take the opportunity to also move {set, clear}_fixmap() prototypes
> in the new header.
>
> Note that most of the definitions in now need to be
> surrounded with #ifndef __ASSEMBLY__ because will
> be used in assembly (see EARLY_UART_VIRTUAL_ADDRESS).
>
> The split will become more helpful in a follow-up patch where new
> fixmap entries will be defined.
>
> Signed-off-by: Julien Grall
> Acked-by: Jan Beulich
>
> ---
> There was some disagreement with Stefano on whether fixmap.h
> should include acpi.h or this should be the other way around.
>
> I chose the former because each components should decide how
> much entries in the fixmap they need and also because this is
> the current behavior on x86. We should stay consitent
> between arch to avoid any headers mess.
>
> Jan acked this patch, so I am assuming he is happy with this
> approach. I would be OK to rework it if others agree with
> Stefano's view.
noone is speaking so:
Acked-by: Stefano Stabellini
> Changes in v4:
> - Add Jan's acked-by
> - Record Stefano's disagreement on the approach
>
> Changes in v3:
> - Patch added
> ---
> xen/arch/arm/acpi/lib.c | 2 ++
> xen/arch/arm/include/asm/config.h | 6 --
> xen/arch/arm/include/asm/early_printk.h | 1 +
> xen/arch/arm/include/asm/fixmap.h | 24
> xen/arch/arm/include/asm/mm.h | 4
> xen/arch/arm/kernel.c | 1 +
> xen/arch/arm/mm.c | 1 +
> xen/include/xen/acpi.h | 18 +++---
> 8 files changed, 40 insertions(+), 17 deletions(-)
> create mode 100644 xen/arch/arm/include/asm/fixmap.h
>
> diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
> index a59cc4074cfb..41d521f720ac 100644
> --- a/xen/arch/arm/acpi/lib.c
> +++ b/xen/arch/arm/acpi/lib.c
> @@ -25,6 +25,8 @@
> #include
> #include
>
> +#include
> +
> static bool fixmap_inuse;
>
> char *__acpi_map_table(paddr_t phys, unsigned long size)
> diff --git a/xen/arch/arm/include/asm/config.h
> b/xen/arch/arm/include/asm/config.h
> index b25c9d39bb32..3e2a55a91058 100644
> --- a/xen/arch/arm/include/asm/config.h
> +++ b/xen/arch/arm/include/asm/config.h
> @@ -169,12 +169,6 @@
>
> #endif
>
> -/* Fixmap slots */
> -#define FIXMAP_CONSOLE 0 /* The primary UART */
> -#define FIXMAP_MISC 1 /* Ephemeral mappings of hardware */
> -#define FIXMAP_ACPI_BEGIN 2 /* Start mappings of ACPI tables */
> -#define FIXMAP_ACPI_END(FIXMAP_ACPI_BEGIN + NUM_FIXMAP_ACPI_PAGES - 1)
> /* End mappings of ACPI tables */
> -
> #define NR_hypercalls 64
>
> #define STACK_ORDER 3
> diff --git a/xen/arch/arm/include/asm/early_printk.h
> b/xen/arch/arm/include/asm/early_printk.h
> index 8dc911cf48a3..c5149b2976da 100644
> --- a/xen/arch/arm/include/asm/early_printk.h
> +++ b/xen/arch/arm/include/asm/early_printk.h
> @@ -11,6 +11,7 @@
> #define __ARM_EARLY_PRINTK_H__
>
> #include
> +#include
>
> #ifdef CONFIG_EARLY_PRINTK
>
> diff --git a/xen/arch/arm/include/asm/fixmap.h
> b/xen/arch/arm/include/asm/fixmap.h
> new file mode 100644
> index ..1cee51e52ab9
> --- /dev/null
> +++ b/xen/arch/arm/include/asm/fixmap.h
> @@ -0,0 +1,24 @@
> +/*
> + * fixmap.h: compile-time virtual memory allocation
> + */
> +#ifndef __ASM_FIXMAP_H
> +#define __ASM_FIXMAP_H
> +
> +#include
> +
> +/* Fixmap slots */
> +#define FIXMAP_CONSOLE 0 /* The primary UART */
> +#define FIXMAP_MISC 1 /* Ephemeral mappings of hardware */
> +#define FIXMAP_ACPI_BEGIN 2 /* Start mappings of ACPI tables */
> +#define FIXMAP_ACPI_END(FIXMAP_ACPI_BEGIN + NUM_FIXMAP_ACPI_PAGES - 1)
> /* End mappings of ACPI tables */
> +
> +#ifndef __ASSEMBLY__
> +
> +/* Map a page in a fixmap entry */
> +extern void set_fixmap(unsigned map, mfn_t mfn, unsigned attributes);
> +/* Remove a mapping from a fixmap entry */
> +extern void clear_fixmap(unsigned map);
> +
> +#endif /* __ASSEMBLY__ */
> +
> +#endif /* __ASM_FIXMAP_H */
> diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
> index 424aaf28230b..045a8ba4bb63 100644
> --- a/xen/arch/arm/include/asm/mm.h
> +++ b/xen/arch/arm/include/asm/mm.h
> @@ -191,10 +191,6 @@ extern void mmu_init_secondary_cpu(void);
> extern void setup_xenheap_mappings(unsigned long base_mfn, unsigned long
> nr_mfns);
> /* Map a frame table to cover physical addresses ps through pe */
> extern void setup_frametable_mappings(paddr_t ps, paddr_t pe);
> -/* Map a 4k page in a fixmap entry */
>
Re: [PATCH 10/16] xen/arm: add Persistent Map (PMAP) infrastructure
On Fri, 20 May 2022, Julien Grall wrote:
> From: Wei Liu
>
> The basic idea is like Persistent Kernel Map (PKMAP) in Linux. We
> pre-populate all the relevant page tables before the system is fully
> set up.
>
> We will need it on Arm in order to rework the arm64 version of
> xenheap_setup_mappings() as we may need to use pages allocated from
> the boot allocator before they are effectively mapped.
>
> This infrastructure is not lock-protected therefore can only be used
> before smpboot. After smpboot, map_domain_page() has to be used.
>
> This is based on the x86 version [1] that was originally implemented
> by Wei Liu.
>
> The PMAP infrastructure is implemented in common code with some
> arch helpers to set/clear the page-table entries and convertion
> between a fixmap slot to a virtual address...
>
> As mfn_to_xen_entry() now needs to be exported, take the opportunity
> to swich the parameter attr from unsigned to unsigned int.
>
> [1]
>
>
> Signed-off-by: Wei Liu
> Signed-off-by: Hongyan Xia
> [julien: Adapted for Arm]
> Signed-off-by: Julien Grall
>
> ---
> Changes in v4:
> - Move xen_fixmap in fixmap.h and add a comment about its usage.
> - Update comments
> - Use DECLARE_BITMAP()
> - Replace local_irq_{enable, disable} with an ASSERT() as there
> should be no user of pmap() in interrupt context.
>
> Changes in v3:
> - s/BITS_PER_LONG/BITS_PER_BYTE/
> - Move pmap to common code
>
> Changes in v2:
> - New patch
>
> Cc: Jan Beulich
> Cc: Wei Liu
> Cc: Andrew Cooper
> Cc: Roger Pau Monné
> ---
> xen/arch/arm/Kconfig | 1 +
> xen/arch/arm/include/asm/fixmap.h | 24 +++
> xen/arch/arm/include/asm/lpae.h | 8
> xen/arch/arm/include/asm/pmap.h | 32 ++
> xen/arch/arm/mm.c | 7 +--
> xen/common/Kconfig| 3 ++
> xen/common/Makefile | 1 +
> xen/common/pmap.c | 72 +++
> xen/include/xen/pmap.h| 16 +++
> 9 files changed, 158 insertions(+), 6 deletions(-)
> create mode 100644 xen/arch/arm/include/asm/pmap.h
> create mode 100644 xen/common/pmap.c
> create mode 100644 xen/include/xen/pmap.h
>
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index ecfa6822e4d3..a89a67802aa9 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -14,6 +14,7 @@ config ARM
> select HAS_DEVICE_TREE
> select HAS_PASSTHROUGH
> select HAS_PDX
> + select HAS_PMAP
> select IOMMU_FORCE_PT_SHARE
>
> config ARCH_DEFCONFIG
> diff --git a/xen/arch/arm/include/asm/fixmap.h
> b/xen/arch/arm/include/asm/fixmap.h
> index 1cee51e52ab9..365a2385a087 100644
> --- a/xen/arch/arm/include/asm/fixmap.h
> +++ b/xen/arch/arm/include/asm/fixmap.h
> @@ -5,20 +5,44 @@
> #define __ASM_FIXMAP_H
>
> #include
> +#include
>
> /* Fixmap slots */
> #define FIXMAP_CONSOLE 0 /* The primary UART */
> #define FIXMAP_MISC 1 /* Ephemeral mappings of hardware */
> #define FIXMAP_ACPI_BEGIN 2 /* Start mappings of ACPI tables */
> #define FIXMAP_ACPI_END(FIXMAP_ACPI_BEGIN + NUM_FIXMAP_ACPI_PAGES - 1)
> /* End mappings of ACPI tables */
> +#define FIXMAP_PMAP_BEGIN (FIXMAP_ACPI_END + 1) /* Start of PMAP */
> +#define FIXMAP_PMAP_END (FIXMAP_PMAP_BEGIN + NUM_FIX_PMAP - 1) /* End of
> PMAP */
> +
> +#define FIXMAP_LAST FIXMAP_PMAP_END
> +
> +#define FIXADDR_START FIXMAP_ADDR(0)
> +#define FIXADDR_TOP FIXMAP_ADDR(FIXMAP_LAST)
>
> #ifndef __ASSEMBLY__
>
> +/*
> + * Direct access to xen_fixmap[] should only happen when {set,
> + * clear}_fixmap() is unusable (e.g. where we would end up to
> + * recursively call the helpers).
> + */
> +extern lpae_t xen_fixmap[XEN_PT_LPAE_ENTRIES];
> +
> /* Map a page in a fixmap entry */
> extern void set_fixmap(unsigned map, mfn_t mfn, unsigned attributes);
> /* Remove a mapping from a fixmap entry */
> extern void clear_fixmap(unsigned map);
>
> +#define fix_to_virt(slot) ((void *)FIXMAP_ADDR(slot))
> +
> +static inline unsigned int virt_to_fix(vaddr_t vaddr)
> +{
> +BUG_ON(vaddr >= FIXADDR_TOP || vaddr < FIXADDR_START);
> +
> +return ((vaddr - FIXADDR_START) >> PAGE_SHIFT);
> +}
> +
> #endif /* __ASSEMBLY__ */
>
> #endif /* __ASM_FIXMAP_H */
> diff --git a/xen/arch/arm/include/asm/lpae.h b/xen/arch/arm/include/asm/lpae.h
> index aecb320dec45..fc19cbd84772 100644
> --- a/xen/arch/arm/include/asm/lpae.h
> +++ b/xen/arch/arm/include/asm/lpae.h
> @@ -4,6 +4,7 @@
> #ifndef __ASSEMBLY__
>
> #include
> +#include
>
> /*
> * WARNING! Unlike the x86 pagetable code, where l1 is the lowest level and
> @@ -168,6 +169,13 @@ static inline bool lpae_is_superpage(lpae_t pte,
> unsigned int level)
> third_table_offset(addr)\
> }
>
> +/*
> + * Standard entry type that we'll use to build Xen's own pagetables.
> + * We put the same permissions at every level,
[linux-linus test] 170868: regressions - FAIL
flight 170868 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/170868/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-xl-pvhv2-intel 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-qemuu-nested-intel 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-pair 12 xen-boot/src_host fail REGR. vs. 170714 test-amd64-amd64-libvirt-pair 13 xen-boot/dst_host fail REGR. vs. 170714 test-amd64-amd64-freebsd12-amd64 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl-seattle 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-qcow2 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-raw 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-examine 8 reboot fail REGR. vs. 170714 test-arm64-arm64-xl-credit1 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl-vhd 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-libvirt-raw 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-examine-bios 8 reboot fail REGR. vs. 170714 test-amd64-amd64-examine-uefi 8 reboot fail REGR. vs. 170714 test-amd64-amd64-examine 8 reboot fail REGR. vs. 170714 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail REGR. vs. 170714 test-arm64-arm64-libvirt-xsm 8 xen-boot fail REGR. vs. 170714 test-armhf-armhf-libvirt 8 xen-boot fail REGR. vs. 170714 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 170714 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 170714 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 170714 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 170714 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170714 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 170714 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 170714 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass version targeted for testing: linuxe71e60cd74df9386c3f684c54888f2367050b831 baseline version: linuxd6ecaa0024485effd065124fe774de2e22095f2d Last test of basis 170714 2022-05-24 03:27:44 Z 14 days Failing since170716 2022-05-24 11:12:06 Z 14 days 40 attempts Testing same since 170868 2022-06-07 12:09:40 Z0 days1 attempts 2274 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm
Re: [PATCH Resend] xen/netback: do some code cleanup
On Tue, 7 Jun 2022 07:28:38 +0200 Juergen Gross wrote:
> Remove some unused macros and functions, make local functions static.
> --- a/drivers/net/xen-netback/rx.c
> +++ b/drivers/net/xen-netback/rx.c
> @@ -486,7 +486,7 @@ static void xenvif_rx_skb(struct xenvif_queue *queue)
>#define RX_BATCH_SIZE 64
> -void xenvif_rx_action(struct xenvif_queue *queue)
> +static void xenvif_rx_action(struct xenvif_queue *queue)
Strange, I haven't seen this kind of corruption before, but the patch
certainly looks corrupted. It doesn't apply.
Could you "git send-email" it?
> {
Re: [PATCH 0/2] Xen FF-A mediator
On Tue, 7 Jun 2022, Stefano Stabellini wrote: > On Tue, 7 Jun 2022, Jens Wiklander wrote: > > Hi, > > > > This patch sets add a FF-A [1] mediator modeled after the TEE mediator > > already present in Xen. The FF-A mediator implements the subset of the FF-A > > 1.1 specification needed to communicate with OP-TEE using FF-A as transport > > mechanism instead of SMC/HVC as with the TEE mediator. It allows a similar > > design in OP-TEE as with the TEE mediator where OP-TEE presents one virtual > > partition of itself to each guest in Xen. > > > > The FF-A mediator is generic in the sense it has nothing OP-TEE specific > > except that only the subset needed for OP-TEE is implemented so far. The > > hooks needed to inform OP-TEE that a guest is created or destroyed is part > > of the FF-A specification. > > > > It should be possible to extend the FF-A mediator to implement a larger > > portion of the FF-A 1.1 specification without breaking with the way OP-TEE > > is communicated with here. So it should be possible to support any TEE or > > Secure Partition using FF-A as transport with this mediator. > > > > [1] https://developer.arm.com/documentation/den0077/latest > > > > Thanks, > > Jens > > Hi Jens, > > Many thanks for the patches! I tried to apply them to the master branch > but unfortunately they don't apply any longer. Could you please rebase > them on master (or even better rebase them on staging) and resend? > > Thank you! One question without having looked at the patches in details. These patches are necessary to mediate OS (e.g. Linux) interactions with OPTEE. The difference between xen/arch/arm/ffa.c and xen/arch/arm/tee/optee.c is the transport mechanism: shared mem vs. SMC. Is that right? If only the transport is different, would it make sense to place ffa.c under xen/arch/arm/tee? Without having looked at the details of the transport or the FF-A protocol let me ask you a question. Do you think it would be possible to share part of the implementation with xen/arch/arm/tee/optee.c? I am asking because intuitively, if only the transport is differenti I would have thought that some things could be common. But it doesn't look like the current patches are reusing anything from xen/arch/arm/tee/optee.c. Are the two protocols too different?
[xen-unstable test] 170865: regressions - FAIL
flight 170865 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/170865/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 7 xen-install fail REGR. vs. 170840 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-install fail pass in 170852 Tests which did not succeed, but are not blocking: test-amd64-i386-pair11 xen-install/dst_host fail in 170852 like 170840 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 170840 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 170840 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 170840 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 170840 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 170840 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 170840 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 170840 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 170840 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 170840 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 170840 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 170840 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170840 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass
Re: [PATCH 0/2] Xen FF-A mediator
On Tue, 7 Jun 2022, Jens Wiklander wrote: > Hi, > > This patch sets add a FF-A [1] mediator modeled after the TEE mediator > already present in Xen. The FF-A mediator implements the subset of the FF-A > 1.1 specification needed to communicate with OP-TEE using FF-A as transport > mechanism instead of SMC/HVC as with the TEE mediator. It allows a similar > design in OP-TEE as with the TEE mediator where OP-TEE presents one virtual > partition of itself to each guest in Xen. > > The FF-A mediator is generic in the sense it has nothing OP-TEE specific > except that only the subset needed for OP-TEE is implemented so far. The > hooks needed to inform OP-TEE that a guest is created or destroyed is part > of the FF-A specification. > > It should be possible to extend the FF-A mediator to implement a larger > portion of the FF-A 1.1 specification without breaking with the way OP-TEE > is communicated with here. So it should be possible to support any TEE or > Secure Partition using FF-A as transport with this mediator. > > [1] https://developer.arm.com/documentation/den0077/latest > > Thanks, > Jens Hi Jens, Many thanks for the patches! I tried to apply them to the master branch but unfortunately they don't apply any longer. Could you please rebase them on master (or even better rebase them on staging) and resend? Thank you! > Jens Wiklander (2): > xen/arm: smccc: add support for SMCCCv1.2 extended input/output > registers > xen/arm: add FF-A mediator > > xen/arch/arm/Kconfig | 11 + > xen/arch/arm/Makefile|1 + > xen/arch/arm/arm64/smc.S | 43 + > xen/arch/arm/domain.c| 10 + > xen/arch/arm/ffa.c | 1624 ++ > xen/arch/arm/vsmc.c | 19 +- > xen/include/asm-arm/domain.h |4 + > xen/include/asm-arm/ffa.h| 71 ++ > xen/include/asm-arm/smccc.h | 42 + > 9 files changed, 1821 insertions(+), 4 deletions(-) > create mode 100644 xen/arch/arm/ffa.c > create mode 100644 xen/include/asm-arm/ffa.h
[linux-5.4 test] 170860: regressions - FAIL
flight 170860 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/170860/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit1 14 guest-start fail REGR. vs. 170736 Tests which are failing intermittently (not blocking): test-amd64-i386-examine-uefi 6 xen-install fail in 170846 pass in 170860 test-armhf-armhf-xl-multivcpu 14 guest-start fail in 170846 pass in 170860 test-armhf-armhf-xl-arndale 18 guest-start/debian.repeat fail in 170846 pass in 170860 test-arm64-arm64-libvirt-raw 17 guest-start/debian.repeat fail in 170846 pass in 170860 test-armhf-armhf-xl-credit2 14 guest-startfail pass in 170846 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 18 guest-localmigrate/x10 fail pass in 170846 test-armhf-armhf-libvirt-qcow2 13 guest-start fail pass in 170846 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-credit2 18 guest-start/debian.repeat fail in 170846 like 170736 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail in 170846 like 170736 test-armhf-armhf-xl-credit2 15 migrate-support-check fail in 170846 never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail in 170846 never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail in 170846 never pass test-armhf-armhf-xl-multivcpu 18 guest-start/debian.repeatfail like 170724 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 170724 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170736 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 170736 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 170736 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 170736 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 170736 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 170736 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 170736 test-armhf-armhf-xl-rtds 18 guest-start/debian.repeatfail like 170736 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 170736 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 170736 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 170736 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16
Re: memory overcomittment with sr-iov device assighment
--- Original Message --- On Tuesday, June 7th, 2022 at 3:04 AM, Andrew Cooper wrote: > But IOMMU violations are not restartable. We can't just take an IOMMU > fault, and shuffle the guests memory, because the PCIe protocol has > timeouts. These aren't generally long enough to even send an interrupt > to request software help, let alone page one part out and another part in. > > For an IOMMU mapping to exists, it must point at real RAM, because any > DMA targetting it cannot be paused and delayed for later. > Thanks for the information! Speaking about IOMMU. Can Xen emulate virtual IOMMU? Just thinking out loud. If Xen exposes a virtual IOMMU to a guest VM, wouldn't it be possible for the hypervisor to pin VM's pages that are mapped (dynamically) by the guest virtual IOMMU? But I guess it will eliminate the performance benefits of direct device assignment.
[qemu-mainline test] 170858: trouble: broken/fail/pass
flight 170858 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/170858/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadowbroken test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 5 host-install(5) broken REGR. vs. 170849 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170849 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 170849 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 170849 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 170849 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 170849 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 170849 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 170849 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 170849 test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass version targeted for testing: qemuu9b1f58854959c5a9bdb347e3e04c252ab7fc9ef5 baseline version: qemuu57c9363c452af64fe058aa946cc923eae7f7ad33 Last test of basis 170849 2022-06-06
Re: [PATCH v1 00/10] Add Xue - console over USB 3 Debug Capability
On Tue, Jun 7, 2022 at 10:31 AM Marek Marczykowski-Górecki wrote: > > This is integration of https://github.com/connojd/xue into mainline Xen. > This patch series includes several patches that I made in the process, some > are > very loosely related. > > The driver developed by Connor supports output-only console via USB3 debug > capability. The capability is designed to operate mostly independently of > normal XHCI driver, so this patch series allows dom0 to drive standard USB3 > controller part, while Xen uses DbC for console output. > > Changes since RFC: > - move the driver to xue.c, remove non-Xen parts, remove now unneeded > abstraction > - adjust for Xen code style > - build for x86 only > - drop patch hidding the device from dom0 Tested-by: Tamas K Lengyel
[libvirt test] 170857: regressions - FAIL
flight 170857 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/170857/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a version targeted for testing: libvirt 95bd13721647fda869f4256c18e8b33a52f7afb6 baseline version: libvirt 2c846fa6bcc11929c9fb857a22430fb9945654ad Last test of basis 151777 2020-07-10 04:19:19 Z 697 days Failing since151818 2020-07-11 04:18:52 Z 696 days 678 attempts Testing same since 170857 2022-06-07 04:25:17 Z0 days1 attempts People who touched revisions under test: Adolfo Jayme Barrientos Aleksandr Alekseev Aleksei Zakharov Amneesh Singh Andika Triwidada Andrea Bolognani Andrew Melnychenko Ani Sinha Balázs Meskó Barrett Schonefeld Bastian Germann Bastien Orivel BiaoXiang Ye Bihong Yu Binfeng Wu Bjoern Walk Boris Fiuczynski Brad Laue Brian Turek Bruno Haible Chris Mayo Christian Borntraeger Christian Ehrhardt Christian Kirbach Christian Schoenebeck Christophe Fergeau Claudio Fontana Cole Robinson Collin Walling Cornelia Huck Cédric Bosdonnat Côme Borsoi Daniel Henrique Barboza Daniel Letai Daniel P. Berrange Daniel P. Berrangé Didik Supriadi dinglimin Divya Garg Dmitrii Shcherbakov Dmytro Linkin Eiichi Tsukata Emilio Herrera Eric Farman Erik Skultety Fabian Affolter Fabian Freyer Fabiano Fidêncio Fangge Jin Farhan Ali Fedora Weblate Translation Franck Ridel Gavi Teitz gongwei Guoyi Tu Göran Uddeborg Halil Pasic Han Han Hao Wang Haonan Wang Hela Basa Helmut Grohne Hiroki Narukawa Hyman Huang(黄勇) Ian Wienand Ioanna Alifieraki Ivan Teterevkov Jakob Meng Jamie Strandboge Jamie Strandboge Jan Kuparinen jason lee Jean-Baptiste Holcroft Jia Zhou Jianan Gao Jim Fehlig Jin Yan Jing Qi Jinsheng Zhang Jiri Denemark Joachim Falk John Ferlan John Levon John Levon Jonathan Watt Jonathon Jongsma Julio Faracco Justin Gatzen Ján Tomko Kashyap Chamarthy Kevin Locke Kim InSoo Koichi Murase Kristina Hanicova Laine Stump Laszlo Ersek Lee Yarwood Lei Yang Lena Voytek Liang Yan Liang Yan Liao Pingfang Lin Ma Lin Ma Lin Ma Liu Yiding Lubomir Rintel Luke Yue Luyao Zhong luzhipeng Marc Hartmayer Marc-André Lureau Marek Marczykowski-Górecki Markus Schade Martin Kletzander Martin Pitt Masayoshi Mizuma Matej Cepl Matt Coleman Matt Coleman Mauro Matteo Cascella Max Goodhart Maxim Nestratov Meina Li Michal Privoznik Michał Smyk Milo Casagrande Moshe Levi Moteen Shah Moteen Shah Muha Aliss Nathan Neal Gompa Nick Chevsky Nick Shyrokovskiy Nickys Music Group Nico Pache Nicolas Lécureuil Nicolas Lécureuil Nikolay Shirokovskiy Nikolay Shirokovskiy Nikolay Shirokovskiy Niteesh Dubey Olaf Hering Olesya Gerasimenko Or Ozeri Orion Poplawski Pany Paolo Bonzini Patrick Magauran Paulo de Rezende Pinatti Pavel Hrdina Peng Liang Peter Krempa Pino
[PATCH v1 10/10] xue: allow driving the rest of XHCI by a domain while Xen uses DbC
That's possible, because the capability was designed specifically to
allow separate driver handle it, in parallel to unmodified xhci driver
(separate set of registers, pretending the port is "disconnected" for
the main xhci driver etc). It works with Linux dom0, although requires
an awful hack - re-enabling bus mastering behind dom0's backs.
Linux driver does similar thing - see
drivers/usb/early/xhci-dbc.c:xdbc_handle_events().
To avoid Linux messing with the DbC, mark this MMIO area as read-only.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/char/xue.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/xen/drivers/char/xue.c b/xen/drivers/char/xue.c
index 6fd26c3d38a8..85aed0bccbbf 100644
--- a/xen/drivers/char/xue.c
+++ b/xen/drivers/char/xue.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -846,6 +847,7 @@ static void xue_flush(struct xue *xue, struct xue_trb_ring
*trb,
{
struct xue_dbc_reg *reg = xue->dbc_reg;
uint32_t db = (reg->db & 0x00FF) | (trb->db << 8);
+uint32_t cmd;
if ( xue->open && !(reg->ctrl & (1UL << XUE_CTRL_DCE)) )
{
@@ -856,6 +858,16 @@ static void xue_flush(struct xue *xue, struct xue_trb_ring
*trb,
xue_enable_dbc(xue);
}
+/* Re-enable bus mastering, if dom0 (or other) disabled it in the
meantime. */
+cmd = pci_conf_read16(xue->sbdf, PCI_COMMAND);
+#define XUE_XHCI_CMD_REQUIRED (PCI_COMMAND_MEMORY|PCI_COMMAND_MASTER)
+if ( (cmd & XUE_XHCI_CMD_REQUIRED) != XUE_XHCI_CMD_REQUIRED )
+{
+cmd |= XUE_XHCI_CMD_REQUIRED;
+pci_conf_write16(xue->sbdf, PCI_COMMAND, cmd);
+}
+#undef XUE_XHCI_CMD_REQUIRED
+
xue_pop_events(xue);
if ( !(reg->ctrl & (1UL << XUE_CTRL_DCR)) )
@@ -955,6 +967,13 @@ static void __init cf_check xue_uart_init_postirq(struct
serial_port *port)
serial_async_transmit(port);
init_timer(>timer, xue_uart_poll, port, 0);
set_timer(>timer, NOW() + MILLISECS(1));
+
+#ifdef CONFIG_X86
+if ( rangeset_add_range(mmio_ro_ranges,
+PFN_DOWN(uart->xue.xhc_mmio_phys + uart->xue.xhc_dbc_offset),
+PFN_UP(uart->xue.xhc_mmio_phys + uart->xue.xhc_dbc_offset +
sizeof(*uart->xue.dbc_reg)) - 1) )
+printk(XENLOG_INFO "Error while adding MMIO range of device to
mmio_ro_ranges\n");
+#endif
}
static int cf_check xue_uart_tx_ready(struct serial_port *port)
--
git-series 0.9.1
[PATCH v1 05/10] console: support multiple serial console simultaneously
Previously only one serial console was supported at the same time. Using
console=com1,dbgp,vga silently ignored all but last serial console (in
this case: only dbgp and vga were active).
Fix this by storing not a single sercon_handle, but an array of them, up
to MAX_SERCONS entries. The value of MAX_SERCONS (4) is arbitrary,
inspired by the number of SERHND_IDX values.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/char/console.c | 58 ++-
1 file changed, 45 insertions(+), 13 deletions(-)
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index f9937c5134c0..44b703296487 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -113,7 +113,9 @@ static char *__read_mostly conring = _conring;
static uint32_t __read_mostly conring_size = _CONRING_SIZE;
static uint32_t conringc, conringp;
-static int __read_mostly sercon_handle = -1;
+#define MAX_SERCONS 4
+static int __read_mostly sercon_handle[MAX_SERCONS];
+static int __read_mostly nr_sercon_handle = 0;
#ifdef CONFIG_X86
/* Tristate: 0 disabled, 1 user enabled, -1 default enabled */
@@ -395,9 +397,17 @@ static unsigned int serial_rx_cons, serial_rx_prod;
static void (*serial_steal_fn)(const char *, size_t nr) = early_puts;
+/* Redirect any console output to *fn*, if *handle* is configured as a
console. */
int console_steal(int handle, void (*fn)(const char *, size_t nr))
{
-if ( (handle == -1) || (handle != sercon_handle) )
+int i;
+
+if ( handle == -1 )
+return 0;
+for ( i = 0; i < nr_sercon_handle; i++ )
+if ( handle == sercon_handle[i] )
+break;
+if ( nr_sercon_handle && i == nr_sercon_handle )
return 0;
if ( serial_steal_fn != NULL )
@@ -415,10 +425,13 @@ void console_giveback(int id)
void console_serial_puts(const char *s, size_t nr)
{
+int i;
+
if ( serial_steal_fn != NULL )
serial_steal_fn(s, nr);
else
-serial_puts(sercon_handle, s, nr);
+for ( i = 0; i < nr_sercon_handle; i++ )
+serial_puts(sercon_handle[i], s, nr);
/* Copy all serial output into PV console */
pv_console_puts(s, nr);
@@ -956,7 +969,7 @@ void guest_printk(const struct domain *d, const char *fmt,
...)
void __init console_init_preirq(void)
{
char *p;
-int sh;
+int sh, i;
serial_init_preirq();
@@ -977,7 +990,8 @@ void __init console_init_preirq(void)
continue;
else if ( (sh = serial_parse_handle(p)) >= 0 )
{
-sercon_handle = sh;
+if ( nr_sercon_handle < MAX_SERCONS )
+sercon_handle[nr_sercon_handle++] = sh;
serial_steal_fn = NULL;
}
else
@@ -996,7 +1010,8 @@ void __init console_init_preirq(void)
opt_console_xen = 0;
#endif
-serial_set_rx_handler(sercon_handle, serial_rx);
+for ( i = 0; i < nr_sercon_handle; i++ )
+serial_set_rx_handler(sercon_handle[i], serial_rx);
pv_console_set_rx_handler(serial_rx);
/* HELLO WORLD --- start-of-day banner text. */
@@ -1014,7 +1029,8 @@ void __init console_init_preirq(void)
if ( opt_sync_console )
{
-serial_start_sync(sercon_handle);
+for ( i = 0; i < nr_sercon_handle; i++ )
+serial_start_sync(sercon_handle[i]);
add_taint(TAINT_SYNC_CONSOLE);
printk("Console output is synchronous.\n");
warning_add(warning_sync_console);
@@ -1121,13 +1137,19 @@ int __init console_has(const char *device)
void console_start_log_everything(void)
{
-serial_start_log_everything(sercon_handle);
+int i;
+
+for ( i = 0; i < nr_sercon_handle; i++ )
+serial_start_log_everything(sercon_handle[i]);
atomic_inc(_everything);
}
void console_end_log_everything(void)
{
-serial_end_log_everything(sercon_handle);
+int i;
+
+for ( i = 0; i < nr_sercon_handle; i++ )
+serial_end_log_everything(sercon_handle[i]);
atomic_dec(_everything);
}
@@ -1149,23 +1171,32 @@ void console_unlock_recursive_irqrestore(unsigned long
flags)
void console_force_unlock(void)
{
+int i;
+
watchdog_disable();
spin_debug_disable();
spin_lock_init(_lock);
-serial_force_unlock(sercon_handle);
+for ( i = 0 ; i < nr_sercon_handle ; i++ )
+serial_force_unlock(sercon_handle[i]);
console_locks_busted = 1;
console_start_sync();
}
void console_start_sync(void)
{
+int i;
+
atomic_inc(_everything);
-serial_start_sync(sercon_handle);
+for ( i = 0 ; i < nr_sercon_handle ; i++ )
+serial_start_sync(sercon_handle[i]);
}
void console_end_sync(void)
{
-serial_end_sync(sercon_handle);
+int i;
+
+for ( i = 0; i < nr_sercon_handle; i++ )
+serial_end_sync(sercon_handle[i]);
atomic_dec(_everything);
}
@@ -1291,7 +1322,8 @@ static int suspend_steal_id;
int console_suspend(void)
{
-suspend_steal_id =
[PATCH v1 07/10] IOMMU/VT-d: wire common device reserved memory API
Re-use rmrr= parameter handling code to handle common device reserved
memory.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/passthrough/vtd/dmar.c | 201 +-
1 file changed, 119 insertions(+), 82 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/dmar.c
b/xen/drivers/passthrough/vtd/dmar.c
index 367304c8739c..661a182b08d9 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -861,111 +861,148 @@ static struct user_rmrr __initdata
user_rmrrs[MAX_USER_RMRR];
/* Macro for RMRR inclusive range formatting. */
#define ERMRRU_FMT "[%lx-%lx]"
-#define ERMRRU_ARG(eru) eru.base_pfn, eru.end_pfn
+#define ERMRRU_ARG base_pfn, end_pfn
+
+static int __init add_one_user_rmrr(unsigned long base_pfn,
+unsigned long end_pfn,
+unsigned int dev_count,
+u32 *sbdf);
static int __init add_user_rmrr(void)
{
+unsigned int i;
+int ret;
+
+for ( i = 0; i < nr_rmrr; i++ )
+{
+ret = add_one_user_rmrr(user_rmrrs[i].base_pfn,
+user_rmrrs[i].end_pfn,
+user_rmrrs[i].dev_count,
+user_rmrrs[i].sbdf);
+if ( ret < 0 )
+return ret;
+}
+return 0;
+}
+
+/* Returns 1 on success, 0 when ignoring and < 0 on error. */
+static int __init add_one_user_rmrr(unsigned long base_pfn,
+unsigned long end_pfn,
+unsigned int dev_count,
+u32 *sbdf)
+{
struct acpi_rmrr_unit *rmrr, *rmrru;
-unsigned int idx, seg, i;
-unsigned long base, end;
+unsigned int idx, seg;
+unsigned long base_iter;
bool overlap;
-for ( i = 0; i < nr_rmrr; i++ )
+if ( iommu_verbose )
+printk(XENLOG_DEBUG VTDPREFIX
+ "Adding RMRR for %d device ([0]: %#x) range "ERMRRU_FMT"\n",
+ dev_count, sbdf[0], ERMRRU_ARG);
+
+if ( base_pfn > end_pfn )
+{
+printk(XENLOG_ERR VTDPREFIX
+ "Invalid RMRR Range "ERMRRU_FMT"\n",
+ ERMRRU_ARG);
+return 0;
+}
+
+if ( (end_pfn - base_pfn) >= MAX_USER_RMRR_PAGES )
{
-base = user_rmrrs[i].base_pfn;
-end = user_rmrrs[i].end_pfn;
+printk(XENLOG_ERR VTDPREFIX
+ "RMRR range "ERMRRU_FMT" exceeds "\
+ __stringify(MAX_USER_RMRR_PAGES)" pages\n",
+ ERMRRU_ARG);
+return 0;
+}
-if ( base > end )
+overlap = false;
+list_for_each_entry(rmrru, _rmrr_units, list)
+{
+if ( pfn_to_paddr(base_pfn) <= rmrru->end_address &&
+ rmrru->base_address <= pfn_to_paddr(end_pfn) )
{
printk(XENLOG_ERR VTDPREFIX
- "Invalid RMRR Range "ERMRRU_FMT"\n",
- ERMRRU_ARG(user_rmrrs[i]));
-continue;
+ "Overlapping RMRRs: "ERMRRU_FMT" and [%lx-%lx]\n",
+ ERMRRU_ARG,
+ paddr_to_pfn(rmrru->base_address),
+ paddr_to_pfn(rmrru->end_address));
+overlap = true;
+break;
}
+}
+/* Don't add overlapping RMRR. */
+if ( overlap )
+return 0;
-if ( (end - base) >= MAX_USER_RMRR_PAGES )
+base_iter = base_pfn;
+do
+{
+if ( !mfn_valid(_mfn(base_iter)) )
{
printk(XENLOG_ERR VTDPREFIX
- "RMRR range "ERMRRU_FMT" exceeds "\
- __stringify(MAX_USER_RMRR_PAGES)" pages\n",
- ERMRRU_ARG(user_rmrrs[i]));
-continue;
+ "Invalid pfn in RMRR range "ERMRRU_FMT"\n",
+ ERMRRU_ARG);
+break;
}
+} while ( base_iter++ < end_pfn );
-overlap = false;
-list_for_each_entry(rmrru, _rmrr_units, list)
-{
-if ( pfn_to_paddr(base) <= rmrru->end_address &&
- rmrru->base_address <= pfn_to_paddr(end) )
-{
-printk(XENLOG_ERR VTDPREFIX
- "Overlapping RMRRs: "ERMRRU_FMT" and [%lx-%lx]\n",
- ERMRRU_ARG(user_rmrrs[i]),
- paddr_to_pfn(rmrru->base_address),
- paddr_to_pfn(rmrru->end_address));
-overlap = true;
-break;
-}
-}
-/* Don't add overlapping RMRR. */
-if ( overlap )
-continue;
+/* Invalid pfn in range as the loop ended before end_pfn was reached. */
+if ( base_iter <= end_pfn )
+return 0;
-do
-{
-if ( !mfn_valid(_mfn(base)) )
-{
-printk(XENLOG_ERR VTDPREFIX
- "Invalid pfn in RMRR range "ERMRRU_FMT"\n",
-
[PATCH v1 08/10] IOMMU/AMD: wire common device reserved memory API
Register common device reserved memory similar to how ivmd= parameter is
handled.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/passthrough/amd/iommu_acpi.c | 16
1 file changed, 16 insertions(+)
diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c
b/xen/drivers/passthrough/amd/iommu_acpi.c
index ac6835225bae..2a4896c05442 100644
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -1078,6 +1078,20 @@ static inline bool_t is_ivmd_block(u8 type)
type == ACPI_IVRS_TYPE_MEMORY_IOMMU);
}
+static int __init cf_check add_one_extra_ivmd(xen_pfn_t start, xen_ulong_t nr,
u32 id, void *ctxt)
+{
+struct acpi_ivrs_memory ivmd;
+
+ivmd.start_address = start << PAGE_SHIFT;
+ivmd.memory_length = nr << PAGE_SHIFT;
+ivmd.header.flags = ACPI_IVMD_UNITY |
+ACPI_IVMD_READ | ACPI_IVMD_WRITE;
+ivmd.header.length = sizeof(ivmd);
+ivmd.header.device_id = id;
+ivmd.header.type = ACPI_IVRS_TYPE_MEMORY_ONE;
+return parse_ivmd_block();
+}
+
static int __init cf_check parse_ivrs_table(struct acpi_table_header *table)
{
const struct acpi_ivrs_header *ivrs_block;
@@ -1121,6 +1135,8 @@ static int __init cf_check parse_ivrs_table(struct
acpi_table_header *table)
AMD_IOMMU_DEBUG("IVMD: %u command line provided entries\n", nr_ivmd);
for ( i = 0; !error && i < nr_ivmd; ++i )
error = parse_ivmd_block(user_ivmds + i);
+if ( !error )
+error = iommu_get_extra_reserved_device_memory(add_one_extra_ivmd,
NULL);
/* Each IO-APIC must have been mentioned in the table. */
for ( apic = 0; !error && iommu_intremap && apic < nr_ioapics; ++apic )
--
git-series 0.9.1
[PATCH v1 03/10] xue: add support for selecting specific xhci
Handle parameters similar to dbgp=ehci.
Implement this by not resettting xhc_cf8 again in xue_init_xhc(), but
using a value found there if non-zero. Additionally, add xue->xhc_num to
select n-th controller.
Signed-off-by: Marek Marczykowski-Górecki
---
docs/misc/xen-command-line.pandoc | 5 +++-
xen/drivers/char/xue.c| 56
2 files changed, 47 insertions(+), 14 deletions(-)
diff --git a/docs/misc/xen-command-line.pandoc
b/docs/misc/xen-command-line.pandoc
index 881fe409ac76..37a564c2386f 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -721,10 +721,15 @@ Available alternatives, with their meaning, are:
### dbgp
> `= ehci[ | @pci:. ]`
+> `= xue[ | @pci:. ]`
Specify the USB controller to use, either by instance number (when going
over the PCI busses sequentially) or by PCI device (must be on segment 0).
+Use `ehci` for EHCI debug port, use `xue` for XHCI debug capability.
+Xue driver will wait indefinitely for the debug host to connect - make sure the
+cable is connected.
+
### debug_stack_lines
> `= `
diff --git a/xen/drivers/char/xue.c b/xen/drivers/char/xue.c
index a9ba25d9d07e..b253426a95f8 100644
--- a/xen/drivers/char/xue.c
+++ b/xen/drivers/char/xue.c
@@ -204,6 +204,7 @@ struct xue {
void *xhc_mmio;
int open;
+int xhc_num; /* look for n-th xhc */
};
static void xue_sys_pause(void)
@@ -252,24 +253,34 @@ static int xue_init_xhc(struct xue *xue)
uint64_t bar1;
uint64_t devfn;
-/*
- * Search PCI bus 0 for the xHC. All the host controllers supported so far
- * are part of the chipset and are on bus 0.
- */
-for ( devfn = 0; devfn < 256; devfn++ ) {
-uint32_t dev = (devfn & 0xF8) >> 3;
-uint32_t fun = devfn & 0x07;
-pci_sbdf_t sbdf = PCI_SBDF(0, dev, fun);
-uint32_t hdr = pci_conf_read8(sbdf, PCI_HEADER_TYPE);
-
-if ( hdr == 0 || hdr == 0x80 )
+if ( xue->sbdf.sbdf == 0 )
+{
+/*
+ * Search PCI bus 0 for the xHC. All the host controllers supported so
far
+ * are part of the chipset and are on bus 0.
+ */
+for ( devfn = 0; devfn < 256; devfn++ )
{
-if ( (pci_conf_read32(sbdf, PCI_CLASS_REVISION) >> 8) ==
XUE_XHC_CLASSC )
+uint32_t dev = (devfn & 0xF8) >> 3;
+uint32_t fun = devfn & 0x07;
+pci_sbdf_t sbdf = PCI_SBDF(0, dev, fun);
+uint32_t hdr = pci_conf_read8(sbdf, PCI_HEADER_TYPE);
+
+if ( hdr == 0 || hdr == 0x80 )
{
-xue->sbdf = sbdf;
-break;
+if ( (pci_conf_read32(sbdf, PCI_CLASS_REVISION) >> 8) ==
XUE_XHC_CLASSC )
+{
+if ( xue->xhc_num-- )
+continue;
+xue->sbdf = sbdf;
+break;
+}
}
}
+} else {
+/* Verify if selected device is really xHC */
+if ( (pci_conf_read32(xue->sbdf, PCI_CLASS_REVISION) >> 8) !=
XUE_XHC_CLASSC )
+xue->sbdf.sbdf = 0;
}
if ( !xue->sbdf.sbdf )
@@ -999,12 +1010,29 @@ void __init xue_uart_init(void)
{
struct xue_uart *uart = _uart;
struct xue *xue = >xue;
+const char *e;
if ( strncmp(opt_dbgp, "xue", 3) )
return;
memset(xue, 0, sizeof(*xue));
+if ( isdigit(opt_dbgp[3]) || !opt_dbgp[3] )
+{
+if ( opt_dbgp[3] )
+xue->xhc_num = simple_strtoul(opt_dbgp + 3, , 10);
+}
+else if ( strncmp(opt_dbgp + 3, "@pci", 4) == 0 )
+{
+unsigned int bus, slot, func;
+
+e = parse_pci(opt_dbgp + 7, NULL, , , );
+if ( !e || *e )
+return;
+
+xue->sbdf = PCI_SBDF(0, bus, slot, func);
+}
+
xue->dbc_ctx =
xue->dbc_erst =
xue->dbc_ering.trb = evt_trb;
--
git-series 0.9.1
[PATCH v1 01/10] drivers/char: Add support for Xue USB3 debugger
From: Connor Davis
[Connor]
Xue is a cross-platform USB 3 debugger that drives the Debug
Capability (DbC) of xHCI-compliant host controllers. This patch
implements the operations needed for xue to initialize the host
controller's DbC and communicate with it. It also implements a struct
uart_driver that uses xue as a backend. Note that only target -> host
communication is supported for now. To use Xue as a console, add
'console=dbgp dbgp=xue' to the command line.
[Marek]
The Xue driver is taken from https://github.com/connojd/xue and heavily
refactored to fit into Xen code base. Major changes include:
- drop support for non-Xen systems
- drop xue_ops abstraction
- use Xen's native helper functions for PCI access
- move all the code to xue.c, drop "inline"
- build for x86 only
- annotate functions with cf_check
- adjust for Xen's code style
Signed-off-by: Connor Davis
Signed-off-by: Marek Marczykowski-Górecki
---
xen/arch/x86/Kconfig | 1 +-
xen/arch/x86/include/asm/fixmap.h | 4 +-
xen/arch/x86/setup.c | 1 +-
xen/drivers/char/Kconfig | 7 +-
xen/drivers/char/Makefile | 1 +-
xen/drivers/char/xue.c| 957 +++-
xen/include/xen/serial.h | 1 +-
7 files changed, 972 insertions(+)
create mode 100644 xen/drivers/char/xue.c
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 06d6fbc86478..9260f464d478 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -13,6 +13,7 @@ config X86
select HAS_COMPAT
select HAS_CPUFREQ
select HAS_EHCI
+ select HAS_XHCI
select HAS_EX_TABLE
select HAS_FAST_MULTIPLY
select HAS_IOPORTS
diff --git a/xen/arch/x86/include/asm/fixmap.h
b/xen/arch/x86/include/asm/fixmap.h
index 20746afd0a2a..bc39ffe896b1 100644
--- a/xen/arch/x86/include/asm/fixmap.h
+++ b/xen/arch/x86/include/asm/fixmap.h
@@ -25,6 +25,8 @@
#include
#include
+#define MAX_XHCI_PAGES 16
+
/*
* Here we define all the compile-time 'special' virtual
* addresses. The point is to have a constant address at
@@ -43,6 +45,8 @@ enum fixed_addresses {
FIX_COM_BEGIN,
FIX_COM_END,
FIX_EHCI_DBGP,
+FIX_XHCI_BEGIN,
+FIX_XHCI_END = FIX_XHCI_BEGIN + MAX_XHCI_PAGES - 1,
#ifdef CONFIG_XEN_GUEST
FIX_PV_CONSOLE,
FIX_XEN_SHARED_INFO,
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 53a73010e029..801081befa78 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -946,6 +946,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
ns16550.irq = 3;
ns16550_init(1, );
ehci_dbgp_init();
+xue_uart_init();
console_init_preirq();
if ( pvh_boot )
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index e5f7b1d8eb8a..55d35af960e5 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -74,3 +74,10 @@ config HAS_EHCI
help
This selects the USB based EHCI debug port to be used as a UART. If
you have an x86 based system with USB, say Y.
+
+config HAS_XHCI
+ bool
+ depends on X86
+ help
+ This selects the USB based XHCI debug capability to be used as a UART. If
+ you have an x86 based system with USB3, say Y.
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index 14e67cf072d7..bda1e44d3f39 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_HAS_MVEBU) += mvebu-uart.o
obj-$(CONFIG_HAS_OMAP) += omap-uart.o
obj-$(CONFIG_HAS_SCIF) += scif-uart.o
obj-$(CONFIG_HAS_EHCI) += ehci-dbgp.o
+obj-$(CONFIG_HAS_XHCI) += xue.o
obj-$(CONFIG_HAS_IMX_LPUART) += imx-lpuart.o
obj-$(CONFIG_ARM) += arm-uart.o
obj-y += serial.o
diff --git a/xen/drivers/char/xue.c b/xen/drivers/char/xue.c
new file mode 100644
index ..e95dd09d39a8
--- /dev/null
+++ b/xen/drivers/char/xue.c
@@ -0,0 +1,957 @@
+/*
+ * drivers/char/xue.c
+ *
+ * Xen port for the xue debugger
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see
[PATCH v1 02/10] xue: reset XHCI ports when initializing dbc
Reset ports, to force host system to re-enumerate devices. Otheriwse it
will require the cable to be re-plugged, or will wait in the
"configuring" state indefinitely.
Trick and code copied from Linux:
drivers/usb/early/xhci-dbc.c:xdbc_start()->xdbc_reset_debug_port()
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/char/xue.c | 70 +++-
1 file changed, 70 insertions(+)
diff --git a/xen/drivers/char/xue.c b/xen/drivers/char/xue.c
index e95dd09d39a8..a9ba25d9d07e 100644
--- a/xen/drivers/char/xue.c
+++ b/xen/drivers/char/xue.c
@@ -60,6 +60,10 @@
((1UL << XUE_PSC_CSC) | (1UL << XUE_PSC_PRC) | (1UL << XUE_PSC_PLC) |
\
(1UL << XUE_PSC_CEC))
+#define XUE_XHC_EXT_PORT_MAJOR(x) (((x) >> 24) & 0xff)
+#define PORT_RESET (1 << 4)
+#define PORT_CONNECT (1 << 0)
+
#define xue_debug(...) printk("xue debug: " __VA_ARGS__)
#define xue_alert(...) printk("xue alert: " __VA_ARGS__)
#define xue_error(...) printk("xue error: " __VA_ARGS__)
@@ -604,6 +608,68 @@ static void xue_init_strings(struct xue *xue, uint32_t
*info)
info[8] = (4 << 24) | (30 << 16) | (8 << 8) | 6;
}
+static void xue_do_reset_debug_port(struct xue *xue, u32 id, u32 count)
+{
+uint32_t *ops_reg;
+uint32_t *portsc;
+u32 val, cap_length;
+int i;
+
+cap_length = (*(uint32_t*)xue->xhc_mmio) & 0xff;
+ops_reg = xue->xhc_mmio + cap_length;
+
+id--;
+for ( i = id; i < (id + count); i++ )
+{
+portsc = ops_reg + 0x100 + i * 0x4;
+val = *portsc;
+if ( !(val & PORT_CONNECT) )
+*portsc = val | PORT_RESET;
+}
+}
+
+
+static void xue_reset_debug_port(struct xue *xue)
+{
+u32 val, port_offset, port_count;
+uint32_t *xcap;
+uint32_t next;
+uint32_t id;
+uint8_t *mmio = (uint8_t *)xue->xhc_mmio;
+uint32_t *hccp1 = (uint32_t *)(mmio + 0x10);
+const uint32_t PROTOCOL_ID = 0x2;
+
+/**
+ * Paranoid check against a zero value. The spec mandates that
+ * at least one "supported protocol" capability must be implemented,
+ * so this should always be false.
+ */
+if ( (*hccp1 & 0x) == 0 )
+return;
+
+xcap = (uint32_t *)(mmio + (((*hccp1 & 0x) >> 16) << 2));
+next = (*xcap & 0xFF00) >> 8;
+id = *xcap & 0xFF;
+
+/* Look for "supported protocol" capability, major revision 3 */
+for ( ; next; xcap += next, id = *xcap & 0xFF, next = (*xcap & 0xFF00) >>
8)
+{
+if ( id != PROTOCOL_ID && next )
+continue;
+
+if ( XUE_XHC_EXT_PORT_MAJOR(*xcap) != 0x3 )
+continue;
+
+/* extract ports offset and count from the capability structure */
+val = *(xcap + 2);
+port_offset = val & 0xff;
+port_count = (val >> 8) & 0xff;
+
+/* and reset them all */
+xue_do_reset_debug_port(xue, port_offset, port_count);
+}
+}
+
static void xue_dump(struct xue *xue)
{
struct xue_dbc_reg *r = xue->dbc_reg;
@@ -639,6 +705,10 @@ static void xue_enable_dbc(struct xue *xue)
while ( (reg->ctrl & (1UL << XUE_CTRL_DCE)) == 0 )
xue_sys_pause();
+/* reset ports on initial open, to force re-enumerating by the host */
+if ( !xue->open )
+xue_reset_debug_port(xue);
+
wmb();
reg->portsc |= (1UL << XUE_PSC_PED);
wmb();
--
git-series 0.9.1
[PATCH v1 04/10] ehci-dbgp: fix selecting n-th ehci controller
The ehci number was parsed but ignored. Signed-off-by: Marek Marczykowski-Górecki --- xen/drivers/char/ehci-dbgp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/drivers/char/ehci-dbgp.c b/xen/drivers/char/ehci-dbgp.c index 16c8ff394d5c..92c588ec0aa3 100644 --- a/xen/drivers/char/ehci-dbgp.c +++ b/xen/drivers/char/ehci-dbgp.c @@ -1480,7 +1480,7 @@ void __init ehci_dbgp_init(void) unsigned int num = 0; if ( opt_dbgp[4] ) -simple_strtoul(opt_dbgp + 4, , 10); +num = simple_strtoul(opt_dbgp + 4, , 10); dbgp->cap = find_dbgp(dbgp, num); if ( !dbgp->cap ) -- git-series 0.9.1
[PATCH v1 00/10] Add Xue - console over USB 3 Debug Capability
This is integration of https://github.com/connojd/xue into mainline Xen. This patch series includes several patches that I made in the process, some are very loosely related. The driver developed by Connor supports output-only console via USB3 debug capability. The capability is designed to operate mostly independently of normal XHCI driver, so this patch series allows dom0 to drive standard USB3 controller part, while Xen uses DbC for console output. Changes since RFC: - move the driver to xue.c, remove non-Xen parts, remove now unneeded abstraction - adjust for Xen code style - build for x86 only - drop patch hidding the device from dom0 Cc: Andrew Cooper Cc: George Dunlap Cc: Jan Beulich Cc: Julien Grall Cc: Stefano Stabellini Cc: Wei Liu Cc: "Roger Pau Monné" Cc: Paul Durrant Cc: Kevin Tian Cc: Connor Davis Connor Davis (1): drivers/char: Add support for Xue USB3 debugger Marek Marczykowski-Górecki (9): xue: reset XHCI ports when initializing dbc xue: add support for selecting specific xhci ehci-dbgp: fix selecting n-th ehci controller console: support multiple serial console simultaneously IOMMU: add common API for device reserved memory IOMMU/VT-d: wire common device reserved memory API IOMMU/AMD: wire common device reserved memory API xue: mark DMA buffers as reserved for the device xue: allow driving the rest of XHCI by a domain while Xen uses DbC docs/misc/xen-command-line.pandoc|5 +- xen/arch/x86/Kconfig |1 +- xen/arch/x86/include/asm/fixmap.h|4 +- xen/arch/x86/setup.c |1 +- xen/drivers/char/Kconfig |7 +- xen/drivers/char/Makefile|1 +- xen/drivers/char/console.c | 58 +- xen/drivers/char/ehci-dbgp.c |2 +- xen/drivers/char/xue.c | 1089 +++- xen/drivers/passthrough/amd/iommu_acpi.c | 16 +- xen/drivers/passthrough/iommu.c | 40 +- xen/drivers/passthrough/vtd/dmar.c | 203 ++-- xen/include/xen/iommu.h | 11 +- xen/include/xen/serial.h |1 +- 14 files changed, 1342 insertions(+), 97 deletions(-) create mode 100644 xen/drivers/char/xue.c base-commit: 49dd52fb1311dadab29f6634d0bc1f4c022c357a -- git-series 0.9.1
[PATCH v1 09/10] xue: mark DMA buffers as reserved for the device
The important part is to include those buffers in IOMMU page table
relevant for the USB controller. Otherwise, DbC will stop working as
soon as IOMMU is enabled, regardless of to which domain device assigned
(be it xen or dom0).
If the device is passed through to dom0 or other domain (see later
patches), that domain will effectively have access to those buffers too.
It does give such domain yet another way to DoS the system (as is the
case when having PCI device assigned already), but also possibly steal
the console ring content. Thus, such domain should be a trusted one.
In any case, prevent anything else being placed on those pages by adding
artificial padding.
Using this API for DbC pages requires raising MAX_USER_RMRR_PAGES.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/char/xue.c | 45 ---
xen/drivers/passthrough/vtd/dmar.c | 2 +-
2 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/xen/drivers/char/xue.c b/xen/drivers/char/xue.c
index b253426a95f8..6fd26c3d38a8 100644
--- a/xen/drivers/char/xue.c
+++ b/xen/drivers/char/xue.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -995,13 +996,21 @@ static struct uart_driver xue_uart_driver = {
.getc = NULL
};
-static struct xue_trb evt_trb[XUE_TRB_RING_CAP] __aligned(XUE_PAGE_SIZE);
-static struct xue_trb out_trb[XUE_TRB_RING_CAP] __aligned(XUE_PAGE_SIZE);
-static struct xue_trb in_trb[XUE_TRB_RING_CAP] __aligned(XUE_PAGE_SIZE);
-static struct xue_erst_segment erst __aligned(64);
-static struct xue_dbc_ctx ctx __aligned(64);
-static uint8_t wrk_buf[XUE_WORK_RING_CAP] __aligned(XUE_PAGE_SIZE);
-static char str_buf[XUE_PAGE_SIZE] __aligned(64);
+struct xue_dma_bufs {
+struct xue_trb evt_trb[XUE_TRB_RING_CAP] __aligned(XUE_PAGE_SIZE);
+struct xue_trb out_trb[XUE_TRB_RING_CAP] __aligned(XUE_PAGE_SIZE);
+struct xue_trb in_trb[XUE_TRB_RING_CAP] __aligned(XUE_PAGE_SIZE);
+struct xue_erst_segment erst __aligned(64);
+struct xue_dbc_ctx ctx __aligned(64);
+uint8_t wrk_buf[XUE_WORK_RING_CAP] __aligned(XUE_PAGE_SIZE);
+char str_buf[XUE_PAGE_SIZE] __aligned(64);
+/*
+ * Don't place anything else on this page - it will be
+ * DMA-reachable by the USB controller.
+ */
+char _pad[0] __aligned(XUE_PAGE_SIZE);
+};
+static struct xue_dma_bufs xue_dma_bufs __aligned(XUE_PAGE_SIZE);
static char __initdata opt_dbgp[30];
string_param("dbgp", opt_dbgp);
@@ -1033,15 +1042,21 @@ void __init xue_uart_init(void)
xue->sbdf = PCI_SBDF(0, bus, slot, func);
}
-xue->dbc_ctx =
-xue->dbc_erst =
-xue->dbc_ering.trb = evt_trb;
-xue->dbc_oring.trb = out_trb;
-xue->dbc_iring.trb = in_trb;
-xue->dbc_owork.buf = wrk_buf;
-xue->dbc_str = str_buf;
+xue->dbc_ctx = _dma_bufs.ctx;
+xue->dbc_erst = _dma_bufs.erst;
+xue->dbc_ering.trb = xue_dma_bufs.evt_trb;
+xue->dbc_oring.trb = xue_dma_bufs.out_trb;
+xue->dbc_iring.trb = xue_dma_bufs.in_trb;
+xue->dbc_owork.buf = xue_dma_bufs.wrk_buf;
+xue->dbc_str = xue_dma_bufs.str_buf;
-xue_open(xue);
+if ( xue_open(xue) )
+{
+iommu_add_extra_reserved_device_memory(
+PFN_DOWN(virt_to_maddr(_dma_bufs)),
+PFN_UP(sizeof(xue_dma_bufs)),
+uart->xue.sbdf.sbdf);
+}
serial_register_uart(SERHND_DBGP, _uart_driver, _uart);
}
diff --git a/xen/drivers/passthrough/vtd/dmar.c
b/xen/drivers/passthrough/vtd/dmar.c
index 661a182b08d9..2caa3e9ad1b0 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -845,7 +845,7 @@ out:
return ret;
}
-#define MAX_USER_RMRR_PAGES 16
+#define MAX_USER_RMRR_PAGES 64
#define MAX_USER_RMRR 10
/* RMRR units derived from command line rmrr option. */
--
git-series 0.9.1
[PATCH v1 06/10] IOMMU: add common API for device reserved memory
Add API similar to rmrr= and ivmd= arguments, but in a common code. This
will allow drivers to register reserved memory regardless of the IOMMU
vendor.
The direct reason for this API is xhci-dbc console driver (aka xue),
that needs to use DMA. But future change may unify command line
arguments for user-supplied reserved memory, and it may be useful for
other drivers in the future too.
This commit just introduces an API, subsequent patches will plug it in
appropriate places. The reserved memory ranges needs to be saved
locally, because at the point when they are collected, Xen doesn't know
yet which IOMMU driver will be used.
Signed-off-by: Marek Marczykowski-Górecki
---
xen/drivers/passthrough/iommu.c | 40 ++-
xen/include/xen/iommu.h | 11 +-
2 files changed, 51 insertions(+)
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 9393d987c788..5c4162912359 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -654,6 +654,46 @@ bool_t iommu_has_feature(struct domain *d, enum
iommu_feature feature)
return is_iommu_enabled(d) && test_bit(feature, dom_iommu(d)->features);
}
+#define MAX_EXTRA_RESERVED_RANGES 20
+struct extra_reserved_range {
+xen_pfn_t start;
+xen_ulong_t nr;
+u32 sbdf;
+};
+static unsigned int __initdata nr_extra_reserved_ranges;
+static struct extra_reserved_range __initdata
extra_reserved_ranges[MAX_EXTRA_RESERVED_RANGES];
+
+int iommu_add_extra_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
u32 sbdf)
+{
+unsigned int idx;
+
+if ( nr_extra_reserved_ranges >= MAX_EXTRA_RESERVED_RANGES )
+return -ENOMEM;
+
+idx = nr_extra_reserved_ranges++;
+extra_reserved_ranges[idx].start = start;
+extra_reserved_ranges[idx].nr = nr;
+extra_reserved_ranges[idx].sbdf = sbdf;
+return 0;
+}
+
+int iommu_get_extra_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
+{
+unsigned int idx;
+int ret;
+
+for ( idx = 0; idx < nr_extra_reserved_ranges; idx++ )
+{
+ret = func(extra_reserved_ranges[idx].start,
+ extra_reserved_ranges[idx].nr,
+ extra_reserved_ranges[idx].sbdf,
+ ctxt);
+if ( ret < 0 )
+return ret;
+}
+return 0;
+}
+
/*
* Local variables:
* mode: C
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index e0f82712ed73..97424130247c 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -296,6 +296,17 @@ struct iommu_ops {
#endif
};
+/*
+ * To be called by Xen internally, to register extra RMRR/IVMD ranges.
+ * Needs to be called before IOMMU initialization.
+ */
+extern int iommu_add_extra_reserved_device_memory(xen_pfn_t start, xen_ulong_t
nr, u32 sbdf);
+/*
+ * To be called by specific IOMMU driver during initialization,
+ * to fetch ranges registered with iommu_add_extra_reserved_device_memory().
+ */
+extern int iommu_get_extra_reserved_device_memory(iommu_grdm_t *func, void
*ctxt);
+
#include
#ifndef iommu_call
--
git-series 0.9.1
Re: [PATCH v4 2/3] xsm: consolidate loading the policy buffer
On Tue, Jun 7, 2022 at 9:16 AM Daniel P. Smith wrote: > Unfortunately the scope of what this series started out to solve, not to > walk all the boot modules when no policy file is needed, and what the > reviewers have been requesting be addressed is continually diverging. You only need patch 1/3 to skip the walk, AFAICT. So maybe you should just submit that independently. Regards, Jason
Re: [PATCH v4 2/3] xsm: consolidate loading the policy buffer
On 07.06.2022 16:10, Daniel P. Smith wrote:
> On 6/7/22 09:58, Jan Beulich wrote:
>> On 07.06.2022 15:47, Daniel P. Smith wrote:
>>>
>>> On 6/2/22 05:47, Jan Beulich wrote:
On 31.05.2022 20:20, Daniel P. Smith wrote:
> Previously, initializing the policy buffer was split between two
> functions,
> xsm_{multiboot,dt}_policy_init() and xsm_core_init(). The latter for
> loading
> the policy from boot modules and the former for falling back to built-in
> policy.
>
> This patch moves all policy buffer initialization logic under the
> xsm_{multiboot,dt}_policy_init() functions. It then ensures that an error
> message is printed for every error condition that may occur in the
> functions.
> With all policy buffer init contained and only called when the policy
> buffer
> must be populated, the respective xsm_{mb,dt}_init() functions will panic
> for
> all errors except ENOENT. An ENOENT signifies that a policy file could
> not be
> located. Since it is not possible to know if late loading of the policy
> file is
> intended, a warning is reported and XSM initialization is continued.
Is it really not possible to know? flask_init() panics in the one case
where a policy is strictly required. And I'm not convinced it is
appropriate to issue both an error and a warning in most (all?) of the
other cases (and it should be at most one of the two anyway imo).
>>>
>>> With how XSM currently works, I do not see how without creating a
>>> layering violation, as you had mentioned before. It is possible for
>>> flask_init() to know because the flask= parameter belongs to the flask
>>> policy module and can be directly checked.
>>>
>>> I think we view this differently. A call to
>>> xsm_{multiboot,dt}_policy_init() is asking for a policy file to be
>>> loaded. If it is not able to do so is an error. This error is reported
>>> back to xsm_{multiboot,dt}_init() which is responsible for initializing
>>> the XSM framework. If it encounters an error for which inhibits it from
>>> initializing XSM would be an error whereas an error it encounters that
>>> does not block initialization should warn the user as such. While it is
>>> true that the only error for the xsm_multiboot_policy_init() currently
>>> is a failure to locate a policy file, ENOENT, I don't see how that
>>> changes the understanding.
>>
>> Well, I think that to avoid the layering violation the decision whether
>> an error is severe enough to warrant a warning (or is even fatal) needs
>> to be left to the specific model (i.e. Flask in this case).
>
> Except that it is not the policy module that loads the policy, where the
> error could occur. As you pointed out for MISRA compliance, you cannot
> have unhandled errors. So either, the errors must be ignored where they
> occur and wait for a larger, non-specific panic, or a nesting of
> handling/reporting the errors needs to be provided for a user to see in
> the log as to why they ended up at the panic.
Right - I was thinking that the error code could be propagated to Flask
instead of (or, less desirable, along with) the NULL pointer indicating
the absence of a policy module. That still would satisfy the "error
indications need to be checked for" MISRA requirement.
Jan
Re: [PATCH v4 2/3] xsm: consolidate loading the policy buffer
On 6/7/22 09:58, Jan Beulich wrote:
> On 07.06.2022 15:47, Daniel P. Smith wrote:
>>
>> On 6/2/22 05:47, Jan Beulich wrote:
>>> On 31.05.2022 20:20, Daniel P. Smith wrote:
Previously, initializing the policy buffer was split between two functions,
xsm_{multiboot,dt}_policy_init() and xsm_core_init(). The latter for
loading
the policy from boot modules and the former for falling back to built-in
policy.
This patch moves all policy buffer initialization logic under the
xsm_{multiboot,dt}_policy_init() functions. It then ensures that an error
message is printed for every error condition that may occur in the
functions.
With all policy buffer init contained and only called when the policy
buffer
must be populated, the respective xsm_{mb,dt}_init() functions will panic
for
all errors except ENOENT. An ENOENT signifies that a policy file could not
be
located. Since it is not possible to know if late loading of the policy
file is
intended, a warning is reported and XSM initialization is continued.
>>>
>>> Is it really not possible to know? flask_init() panics in the one case
>>> where a policy is strictly required. And I'm not convinced it is
>>> appropriate to issue both an error and a warning in most (all?) of the
>>> other cases (and it should be at most one of the two anyway imo).
>>
>> With how XSM currently works, I do not see how without creating a
>> layering violation, as you had mentioned before. It is possible for
>> flask_init() to know because the flask= parameter belongs to the flask
>> policy module and can be directly checked.
>>
>> I think we view this differently. A call to
>> xsm_{multiboot,dt}_policy_init() is asking for a policy file to be
>> loaded. If it is not able to do so is an error. This error is reported
>> back to xsm_{multiboot,dt}_init() which is responsible for initializing
>> the XSM framework. If it encounters an error for which inhibits it from
>> initializing XSM would be an error whereas an error it encounters that
>> does not block initialization should warn the user as such. While it is
>> true that the only error for the xsm_multiboot_policy_init() currently
>> is a failure to locate a policy file, ENOENT, I don't see how that
>> changes the understanding.
>
> Well, I think that to avoid the layering violation the decision whether
> an error is severe enough to warrant a warning (or is even fatal) needs
> to be left to the specific model (i.e. Flask in this case).
Except that it is not the policy module that loads the policy, where the
error could occur. As you pointed out for MISRA compliance, you cannot
have unhandled errors. So either, the errors must be ignored where they
occur and wait for a larger, non-specific panic, or a nesting of
handling/reporting the errors needs to be provided for a user to see in
the log as to why they ended up at the panic.
v/r,
dps
Re: [PATCH v4 2/3] xsm: consolidate loading the policy buffer
On 07.06.2022 15:47, Daniel P. Smith wrote:
>
> On 6/2/22 05:47, Jan Beulich wrote:
>> On 31.05.2022 20:20, Daniel P. Smith wrote:
>>> Previously, initializing the policy buffer was split between two functions,
>>> xsm_{multiboot,dt}_policy_init() and xsm_core_init(). The latter for loading
>>> the policy from boot modules and the former for falling back to built-in
>>> policy.
>>>
>>> This patch moves all policy buffer initialization logic under the
>>> xsm_{multiboot,dt}_policy_init() functions. It then ensures that an error
>>> message is printed for every error condition that may occur in the
>>> functions.
>>> With all policy buffer init contained and only called when the policy buffer
>>> must be populated, the respective xsm_{mb,dt}_init() functions will panic
>>> for
>>> all errors except ENOENT. An ENOENT signifies that a policy file could not
>>> be
>>> located. Since it is not possible to know if late loading of the policy
>>> file is
>>> intended, a warning is reported and XSM initialization is continued.
>>
>> Is it really not possible to know? flask_init() panics in the one case
>> where a policy is strictly required. And I'm not convinced it is
>> appropriate to issue both an error and a warning in most (all?) of the
>> other cases (and it should be at most one of the two anyway imo).
>
> With how XSM currently works, I do not see how without creating a
> layering violation, as you had mentioned before. It is possible for
> flask_init() to know because the flask= parameter belongs to the flask
> policy module and can be directly checked.
>
> I think we view this differently. A call to
> xsm_{multiboot,dt}_policy_init() is asking for a policy file to be
> loaded. If it is not able to do so is an error. This error is reported
> back to xsm_{multiboot,dt}_init() which is responsible for initializing
> the XSM framework. If it encounters an error for which inhibits it from
> initializing XSM would be an error whereas an error it encounters that
> does not block initialization should warn the user as such. While it is
> true that the only error for the xsm_multiboot_policy_init() currently
> is a failure to locate a policy file, ENOENT, I don't see how that
> changes the understanding.
Well, I think that to avoid the layering violation the decision whether
an error is severe enough to warrant a warning (or is even fatal) needs
to be left to the specific model (i.e. Flask in this case).
Jan
Re: [PATCH v4 3/3] xsm: properly handle error from XSM init
On 6/1/22 02:49, Jan Beulich wrote:
> On 31.05.2022 21:18, Andrew Cooper wrote:
>> On 31/05/2022 19:20, Daniel P. Smith wrote:
>>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>>> index 53a73010e0..ed67b50c9d 100644
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -1700,7 +1701,11 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>> mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
>>>RANGESETF_prettyprint_hex);
>>>
>>> -xsm_multiboot_init(module_map, mbi);
>>> +if ( xsm_multiboot_init(module_map, mbi) )
>>> +warning_add("WARNING: XSM failed to initialize.\n"
>>> +"This has implications on the security of the
>>> system,\n"
>>> +"as uncontrolled communications between trusted and\n"
>>> +"untrusted domains may occur.\n");
>>
>> The problem with this approach is that it forces each architecture to
>> opencode the failure string, in a function which is very busy with other
>> things too.
>>
>> Couldn't xsm_{multiboot,dt}_init() be void, and the warning_add() move
>> into them, like the SLIO warning for ARM already?
>
> I, too, was considering to suggest this (but then didn't on v3). Furthermore
> the warning_add() could then be wrapped in a trivial helper function to be
> used by both MB and DT.
Re: helper function, ack.
Re: [PATCH v4 3/3] xsm: properly handle error from XSM init
On 5/31/22 15:18, Andrew Cooper wrote:
> On 31/05/2022 19:20, Daniel P. Smith wrote:
>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>> index 53a73010e0..ed67b50c9d 100644
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -1700,7 +1701,11 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>> mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
>>RANGESETF_prettyprint_hex);
>>
>> -xsm_multiboot_init(module_map, mbi);
>> +if ( xsm_multiboot_init(module_map, mbi) )
>> +warning_add("WARNING: XSM failed to initialize.\n"
>> +"This has implications on the security of the system,\n"
>> +"as uncontrolled communications between trusted and\n"
>> +"untrusted domains may occur.\n");
>
> The problem with this approach is that it forces each architecture to
> opencode the failure string, in a function which is very busy with other
> things too.
>
> Couldn't xsm_{multiboot,dt}_init() be void, and the warning_add() move
> into them, like the SLIO warning for ARM already?
>
> That would simplify both ARM and x86's __start_xen(), and be an
> improvement for the RISC-V series just posted to xen-devel...
I was trying to address the MISRA review comment by handling the
unhandled return while trying to provide a uniform implementation across
arch. Moving the xsm_{multiboot,dt}_init() to void will address both and
as you point out make it simpler overall.
v/r,
dps
Re: [PATCH v4 2/3] xsm: consolidate loading the policy buffer
On 6/2/22 05:47, Jan Beulich wrote:
> On 31.05.2022 20:20, Daniel P. Smith wrote:
>> Previously, initializing the policy buffer was split between two functions,
>> xsm_{multiboot,dt}_policy_init() and xsm_core_init(). The latter for loading
>> the policy from boot modules and the former for falling back to built-in
>> policy.
>>
>> This patch moves all policy buffer initialization logic under the
>> xsm_{multiboot,dt}_policy_init() functions. It then ensures that an error
>> message is printed for every error condition that may occur in the functions.
>> With all policy buffer init contained and only called when the policy buffer
>> must be populated, the respective xsm_{mb,dt}_init() functions will panic for
>> all errors except ENOENT. An ENOENT signifies that a policy file could not be
>> located. Since it is not possible to know if late loading of the policy file
>> is
>> intended, a warning is reported and XSM initialization is continued.
>
> Is it really not possible to know? flask_init() panics in the one case
> where a policy is strictly required. And I'm not convinced it is
> appropriate to issue both an error and a warning in most (all?) of the
> other cases (and it should be at most one of the two anyway imo).
With how XSM currently works, I do not see how without creating a
layering violation, as you had mentioned before. It is possible for
flask_init() to know because the flask= parameter belongs to the flask
policy module and can be directly checked.
I think we view this differently. A call to
xsm_{multiboot,dt}_policy_init() is asking for a policy file to be
loaded. If it is not able to do so is an error. This error is reported
back to xsm_{multiboot,dt}_init() which is responsible for initializing
the XSM framework. If it encounters an error for which inhibits it from
initializing XSM would be an error whereas an error it encounters that
does not block initialization should warn the user as such. While it is
true that the only error for the xsm_multiboot_policy_init() currently
is a failure to locate a policy file, ENOENT, I don't see how that
changes the understanding.
>> --- a/xen/include/xsm/xsm.h
>> +++ b/xen/include/xsm/xsm.h
>> @@ -775,7 +775,7 @@ int xsm_multiboot_init(
>> unsigned long *module_map, const multiboot_info_t *mbi);
>> int xsm_multiboot_policy_init(
>> unsigned long *module_map, const multiboot_info_t *mbi,
>> -void **policy_buffer, size_t *policy_size);
>> +const unsigned char *policy_buffer[], size_t *policy_size);
>
> See my v3 comment on the use of [] here. And that comment was actually
> made before you sent v4 (unlike the later comment on patch 1). Oh,
> actually you did change this in the function definition, just not here.
ack
>> @@ -32,14 +32,21 @@
>> #ifdef CONFIG_MULTIBOOT
>> int __init xsm_multiboot_policy_init(
>> unsigned long *module_map, const multiboot_info_t *mbi,
>> -void **policy_buffer, size_t *policy_size)
>> +const unsigned char **policy_buffer, size_t *policy_size)
>> {
>> int i;
>> module_t *mod = (module_t *)__va(mbi->mods_addr);
>> -int rc = 0;
>> +int rc = -ENOENT;
>> u32 *_policy_start;
>> unsigned long _policy_len;
>>
>> +#ifdef CONFIG_XSM_FLASK_POLICY
>> +/* Initially set to builtin policy, overriden if boot module is found.
>> */
>
> Nit: "overridden"
ack
v/r,
dps
[ovmf test] 170867: all pass - PUSHED
flight 170867 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/170867/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf a81a650da1dc40ec2b2825d1878cdf2778b4be14 baseline version: ovmf 4f89e4b3e80329b9a44559c658d2ebce8475 Last test of basis 170855 2022-06-07 01:57:37 Z0 days Testing same since 170867 2022-06-07 11:10:44 Z0 days1 attempts People who touched revisions under test: Min M Xu Min Xu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 4f89e4b3e8..a81a650da1 a81a650da1dc40ec2b2825d1878cdf2778b4be14 -> xen-tested-master
Re: [PATCH v3 3/3] xsm: properly handle error from XSM init
On 07.06.2022 14:14, Daniel P. Smith wrote: > On 6/1/22 02:14, Jan Beulich wrote: >> Now that return values are checked, I think that in addition to what >> you already do the two function declarations may want decorating with >> __must_check. > > Understood but likely not necessary based on Andy's review suggestion to > move these functions to void. Of course - once they return void, they cannot be __must_check. Jan
Re: [PATCH v4 2/3] xsm: consolidate loading the policy buffer
On 5/31/22 15:07, Andrew Cooper wrote:
> On 31/05/2022 19:20, Daniel P. Smith wrote:
>> diff --git a/xen/xsm/xsm_policy.c b/xen/xsm/xsm_policy.c
>> index 8dafbc9381..690fd23e9f 100644
>> --- a/xen/xsm/xsm_policy.c
>> +++ b/xen/xsm/xsm_policy.c
>> @@ -8,7 +8,7 @@
>> * Contributors:
>> * Michael LeMay,
>> * George Coker,
>> - *
>> + *
>> * This program is free software; you can redistribute it and/or modify
>> * it under the terms of the GNU General Public License version 2,
>> * as published by the Free Software Foundation.
>> @@ -32,14 +32,21 @@
>> #ifdef CONFIG_MULTIBOOT
>> int __init xsm_multiboot_policy_init(
>> unsigned long *module_map, const multiboot_info_t *mbi,
>> -void **policy_buffer, size_t *policy_size)
>> +const unsigned char **policy_buffer, size_t *policy_size)
>> {
>> int i;
>> module_t *mod = (module_t *)__va(mbi->mods_addr);
>> -int rc = 0;
>> +int rc = -ENOENT;
>> u32 *_policy_start;
>> unsigned long _policy_len;
>>
>> +#ifdef CONFIG_XSM_FLASK_POLICY
>> +/* Initially set to builtin policy, overriden if boot module is found.
>> */
>> +*policy_buffer = xsm_flask_init_policy;
>> +*policy_size = xsm_flask_init_policy_size;
>> +rc = 0;
>> +#endif
>
> Does
>
> if ( IS_ENABLED(CONFIG_XSM_FLASK_POLICY) )
> {
> ...
> }
>
> compile properly? You'll need to drop the ifdefary in xsm.h, but this
> would be a better approach (more compiler coverage in normal builds).
>
> Same for the related hunk on the DT side.
Yes, I know this pattern is used elsewhere, so it should work here fine.
>> +
>> /*
>> * Try all modules and see whichever could be the binary policy.
>> * Adjust module_map for the module that is the binary policy.
>> @@ -54,13 +61,14 @@ int __init xsm_multiboot_policy_init(
>>
>> if ( (xsm_magic_t)(*_policy_start) == XSM_MAGIC )
>> {
>> -*policy_buffer = _policy_start;
>> +*policy_buffer = (unsigned char *)_policy_start;
>
> The existing logic is horrible. To start with, there's a buffer overrun
> for a module of fewer than 4 bytes. (Same on the DT side.)
>
> It would be slightly less horrible as
>
> for ( ... )
> {
> void *ptr;
>
> if ( !test_bit(i, module_map) || mod[i].mod_end < sizeof(xsm_header) )
> continue;
>
> ptr = bootstrap_map(...);
>
> if ( memcmp(ptr, XSM_MAGIC, sizeof(XSM_MAGIC)) == 0 )
> {
> *policy_buffer = ptr;
> *policy_len = mod[i].mod_end;
>
> ...
> break;
> }
>
> bootstrap_map(NULL);
> }
>
> because at least this gets rid of the intermediate variables, the buffer
> overrun, and the awkward casting to find XSM_MAGIC.
Since you were kind enough to take the time to write out the fix, I can
incorporate.
> That said, it's still unclear what's going on, because has_xsm_magic()
> says the header is 16 bytes long, rather than 4 (assuming that it means
> uint32_t. policydb_read() uses uint32_t).
>
> Also, policydb_read() uses le32_to_cpu() so the multiboot/dt checks are
> wrong on big-endian systems.
>
> Also also, policydb_read() really doesn't need to make a temporary
> memory allocation to check a fixed string of fixed length. This is
> horrible.
>
> I suspect we're getting into "in a subsequent patch" territory here.
Unfortunately the scope of what this series started out to solve, not to
walk all the boot modules when no policy file is needed, and what the
reviewers have been requesting be addressed is continually diverging.
Granted, with the technical debt currently present in XSM, I understand
why this is occurring. Unfortunately, subsequent patch here means, going
on to my list of things I would like to fix/work on in XSM.
v/r,
dps
Re: [PATCH v3 3/3] xsm: properly handle error from XSM init
On 6/1/22 02:14, Jan Beulich wrote:
> On 31.05.2022 17:08, Daniel P. Smith wrote:
>> @@ -1690,7 +1691,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>
>> open_softirq(NEW_TLBFLUSH_CLOCK_PERIOD_SOFTIRQ,
>> new_tlbflush_clock_period);
>>
>> -if ( opt_watchdog )
>> +if ( opt_watchdog )
>> nmi_watchdog = NMI_LOCAL_APIC;
>>
>> find_smp_config();
>
> Please omit formatting changes to entirely unrelated pieces of code.
Ack. this was in simliar vein of the other patches where I cleaned
nearby trailing space.
>> @@ -1700,7 +1701,11 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>> mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges",
>>RANGESETF_prettyprint_hex);
>>
>> -xsm_multiboot_init(module_map, mbi);
>> +if ( xsm_multiboot_init(module_map, mbi) )
>> +warning_add("WARNING: XSM failed to initialize.\n"
>> +"This has implications on the security of the system,\n"
>> +"as uncontrolled communications between trusted and\n"
>> +"untrusted domains may occur.\n");
>
> Uncontrolled communication isn't the only thing that could occur, aiui.
> So at the very least "e.g." or some such would want adding imo.
Agreed, this was a reuse of the existing message and honestly I would
like to believe this was the original author's attempt at brevity versus
writing a detailed message of every implication to the security of the
system.
> Now that return values are checked, I think that in addition to what
> you already do the two function declarations may want decorating with
> __must_check.
Understood but likely not necessary based on Andy's review suggestion to
move these functions to void.
v/r,
dps
Re: [PATCH v3 1/3] xsm: only search for a policy file when needed
On 6/1/22 02:08, Jan Beulich wrote: > On 31.05.2022 17:08, Daniel P. Smith wrote: >> It is possible to select a few different build configurations that results in >> the unnecessary walking of the boot module list looking for a policy module. >> This specifically occurs when the flask policy is enabled but either the >> dummy >> or the SILO policy is selected as the enforcing policy. This is not ideal for >> configurations like hyperlaunch and dom0less when there could be a number of >> modules to be walked or doing an unnecessary device tree lookup. >> >> This patch introduces the policy_file_required flag for tracking when an XSM >> policy module requires a policy file. > > In light of the "flask=late" aspect of patch 2, I'd like to suggest to > slightly alter wording here: "... requires looking for a policy file." ack >> --- a/xen/xsm/xsm_core.c >> +++ b/xen/xsm/xsm_core.c >> @@ -55,19 +55,31 @@ static enum xsm_bootparam __initdata xsm_bootparam = >> XSM_BOOTPARAM_DUMMY; >> #endif >> >> +static bool __initdata policy_file_required = >> +IS_ENABLED(CONFIG_XSM_FLASK_DEFAULT); > > The variable may then also want renaming, to e.g. "find_policy_file". ack v/r, dps
Re: [PATCH v3 1/3] xsm: only search for a policy file when needed
On 6/1/22 02:04, Jan Beulich wrote:
> On 31.05.2022 18:15, Daniel P. Smith wrote:
>>
>> On 5/31/22 11:51, Jan Beulich wrote:
>>> On 31.05.2022 17:08, Daniel P. Smith wrote:
It is possible to select a few different build configurations that results
in
the unnecessary walking of the boot module list looking for a policy
module.
This specifically occurs when the flask policy is enabled but either the
dummy
or the SILO policy is selected as the enforcing policy. This is not ideal
for
configurations like hyperlaunch and dom0less when there could be a number
of
modules to be walked or doing an unnecessary device tree lookup.
This patch introduces the policy_file_required flag for tracking when an
XSM
policy module requires a policy file. Only when the policy_file_required
flag
is set to true, will XSM search the boot modules for a policy file.
Signed-off-by: Daniel P. Smith
>>>
>>> Looks technically okay, so
>>> Reviewed-by: Jan Beulich
>>> but couldn't you ...
>>>
@@ -148,7 +160,7 @@ int __init xsm_multiboot_init(
printk("XSM Framework v" XSM_FRAMEWORK_VERSION " initialized\n");
-if ( XSM_MAGIC )
+if ( policy_file_required && XSM_MAGIC )
{
ret = xsm_multiboot_policy_init(module_map, mbi, _buffer,
_size);
@@ -176,7 +188,7 @@ int __init xsm_dt_init(void)
printk("XSM Framework v" XSM_FRAMEWORK_VERSION " initialized\n");
-if ( XSM_MAGIC )
+if ( policy_file_required && XSM_MAGIC )
{
ret = xsm_dt_policy_init(_buffer, _size);
if ( ret )
>>>
>>> ... drop the two "&& XSM_MAGIC" here at this time? Afaict
>>> policy_file_required
>>> cannot be true when XSM_MAGIC is zero.
>>
>> I was on the fence about this, as it should be rendered as redundant as
>> you point out. I am good with dropping on next spin.
>
> I'd also be okay dropping this while committing, unless a v4 appears
> first ...
ack
v/r,
dps
[linux-linus test] 170853: regressions - FAIL
flight 170853 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/170853/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-xl-pvhv2-intel 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-qemuu-nested-intel 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-pair 12 xen-boot/src_host fail REGR. vs. 170714 test-amd64-amd64-libvirt-pair 13 xen-boot/dst_host fail REGR. vs. 170714 test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-freebsd12-amd64 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl-seattle 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-qcow2 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-raw 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-examine 8 reboot fail REGR. vs. 170714 test-arm64-arm64-xl-credit1 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-libvirt-raw 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-examine-bios 8 reboot fail REGR. vs. 170714 test-amd64-amd64-examine-uefi 8 reboot fail REGR. vs. 170714 test-amd64-amd64-examine 8 reboot fail REGR. vs. 170714 test-arm64-arm64-libvirt-xsm 8 xen-boot fail REGR. vs. 170714 Tests which are failing intermittently (not blocking): test-arm64-arm64-xl-vhd 8 xen-boot fail pass in 170844 test-amd64-amd64-freebsd11-amd64 21 guest-start/freebsd.repeat fail pass in 170844 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-vhd 14 migrate-support-check fail in 170844 never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail in 170844 never pass test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 170714 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 170714 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 170714 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 170714 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170714 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 170714 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 170714 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 170714 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass version targeted for testing: linuxf2906aa863381afb0015a9eb7fefad885d4e5a56 baseline version: linuxd6ecaa0024485effd065124fe774de2e22095f2d Last test of basis 170714 2022-05-24 03:27:44 Z 14 days Failing since170716 2022-05-24 11:12:06 Z 14 days 39 attempts Testing same since 170841 2022-06-06
Re: [RFC PATCH 1/4] kconfig: allow configuration of maximum modules
Hi, On 02/06/2022 09:49, Jan Beulich wrote: On 01.06.2022 19:35, Julien Grall wrote: On 31/05/2022 11:53, Daniel P. Smith wrote: On 5/31/22 05:25, Julien Grall wrote: Hi, On 31/05/2022 03:41, Daniel P. Smith wrote: diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig index f16eb0df43..57b14e22c9 100644 --- a/xen/arch/Kconfig +++ b/xen/arch/Kconfig @@ -17,3 +17,15 @@ config NR_CPUS For CPU cores which support Simultaneous Multi-Threading or similar technologies, this the number of logical threads which Xen will support. + +config NR_BOOTMODS + int "Maximum number of boot modules that a loader can pass" + range 1 64 OOI, any reason to limit the size? I modelled this entirely after NR_CPUS, which applied a limit The limit for NR_CPUS makes sense because there are scalability issues after that (although 4095 seems quite high) and/or the HW impose a limit. The 4095 is actually a software limit (due to how spinlocks are implemented). , and it seemed reasonable to me at the time. I choose 64 since it was double currently what Arm had set for MAX_MODULES. As such, I have no hard reason for there to be a limit. It can easily be removed or adjusted to whatever the reviewers feel would be appropriate. Ok. In which case I would drop the limit beause it also prevent a users to create more 64 dom0less domUs (actually a bit less because some modules are used by Xen). I don't think there are a strong reason to prevent that, right? At least as per the kconfig language doc the upper bound is not optional, so if a range is specified (which I think it should be, to enforce the lower limit of 1) and upper bound is needed. To address your concern with dom0less - 32768 maybe? I am fine with that. Cheers, -- Julien Grall
Re: [RFC PATCH 1/4] kconfig: allow configuration of maximum modules
On 01/06/2022 10:06, Roger Pau Monné wrote: On Wed, Jun 01, 2022 at 07:40:12AM +, George Dunlap wrote: The down side of this is that you can’t use “automatically remove trailing whitespace on save” features of some editors. Without such automation, I introduce loads of trailing whitespace. With such automation, I end up removing random trailing whitespace as I happen to touch files. I’ve always done this by just adding “While here, remove some trailing whitespace” to the commit message, and there haven’t been any complaints. FWIW, I have an editor feature that highlights trailing whitespace, but doesn't remove it. As said, I find it cumbersome to have to go through more jumps while using `git blame` or similar, just because of unrelated cleanups. IMO I don't think it's good practice to wholesale replace all trailing whitespace from a file as part of an unrelated change. +1 Cheers, -- Julien Grall
[xen-unstable test] 170852: regressions - FAIL
flight 170852 xen-unstable real [real] flight 170862 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/170852/ http://logs.test-lab.xenproject.org/osstest/logs/170862/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 7 xen-install fail REGR. vs. 170840 Tests which did not succeed, but are not blocking: test-amd64-i386-pair 11 xen-install/dst_host fail like 170840 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 170840 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 170840 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 170840 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 170840 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 170840 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 170840 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 170840 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 170840 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 170840 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 170840 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 170840 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170840 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16
[PATCH 2/2] xen/arm: add FF-A mediator
Adds a FF-A version 1.1 [1] mediator to communicate with a Secure
Partition in secure world.
The implementation is the bare minimum to be able to communicate with
OP-TEE running as an SPMC at S-EL1.
This is loosely based on the TEE mediator framework and the OP-TEE
mediator.
[1] https://developer.arm.com/documentation/den0077/latest
Signed-off-by: Jens Wiklander
---
xen/arch/arm/Kconfig | 11 +
xen/arch/arm/Makefile|1 +
xen/arch/arm/domain.c| 10 +
xen/arch/arm/ffa.c | 1624 ++
xen/arch/arm/vsmc.c | 17 +-
xen/include/asm-arm/domain.h |4 +
xen/include/asm-arm/ffa.h| 71 ++
7 files changed, 1735 insertions(+), 3 deletions(-)
create mode 100644 xen/arch/arm/ffa.c
create mode 100644 xen/include/asm-arm/ffa.h
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 277738826581..281edb85cbff 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -114,6 +114,17 @@ config TEE
source "arch/arm/tee/Kconfig"
+config FFA
+ bool "Enable FF-A mediator support" if EXPERT
+ default n
+ depends on ARM_64
+ help
+ This option enables a minamal FF-A mediator. The mediator is
+ generic as it follows the FF-A specification [1], but it only
+ implements a small substet of the specification.
+
+ [1] https://developer.arm.com/documentation/den0077/latest
+
endmenu
menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 1ded44d20047..90c43a4a9edf 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -17,6 +17,7 @@ obj-y += domain.o
obj-y += domain_build.init.o
obj-y += domctl.o
obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
+obj-$(CONFIG_FFA) += ffa.o
obj-y += gic.o
obj-y += gic-v2.o
obj-$(CONFIG_GICV3) += gic-v3.o
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index ac6a419f55c9..451f3eed550f 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -737,6 +738,9 @@ int arch_domain_create(struct domain *d,
if ( (rc = tee_domain_init(d, config->arch.tee_type)) != 0 )
goto fail;
+if ( (rc = ffa_domain_init(d)) != 0 )
+goto fail;
+
update_domain_wallclock_time(d);
/*
@@ -974,6 +978,7 @@ static int relinquish_memory(struct domain *d, struct
page_list_head *list)
*/
enum {
PROG_tee = 1,
+PROG_ffa,
PROG_xen,
PROG_page,
PROG_mapping,
@@ -1012,6 +1017,11 @@ int domain_relinquish_resources(struct domain *d)
if (ret )
return ret;
+PROGRESS(ffa):
+ret = ffa_relinquish_resources(d);
+if (ret )
+return ret;
+
PROGRESS(xen):
ret = relinquish_memory(d, >xenpage_list);
if ( ret )
diff --git a/xen/arch/arm/ffa.c b/xen/arch/arm/ffa.c
new file mode 100644
index ..9063b7f2b59e
--- /dev/null
+++ b/xen/arch/arm/ffa.c
@@ -0,0 +1,1624 @@
+/*
+ * xen/arch/arm/ffa.c
+ *
+ * Arm Firmware Framework for ARMv8-A(FFA) mediator
+ *
+ * Copyright (C) 2021 Linaro Limited
+ *
+ * Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without restriction,
+ * including without limitation the rights to use, copy, modify, merge,
+ * publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so,
+ * subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+ * IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ * CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+/* Error codes */
+#define FFA_RET_OK 0
+#define FFA_RET_NOT_SUPPORTED -1
+#define FFA_RET_INVALID_PARAMETERS -2
+#define FFA_RET_NO_MEMORY -3
+#define FFA_RET_BUSY -4
+#define FFA_RET_INTERRUPTED-5
+#define FFA_RET_DENIED -6
+#define FFA_RET_RETRY -7
+#define FFA_RET_ABORTED-8
+
+/* FFA_VERSION helpers */
+#define FFA_VERSION_MAJOR _AC(1,U)
+#define FFA_VERSION_MAJOR_SHIFT_AC(16,U)
[PATCH 0/2] Xen FF-A mediator
Hi, This patch sets add a FF-A [1] mediator modeled after the TEE mediator already present in Xen. The FF-A mediator implements the subset of the FF-A 1.1 specification needed to communicate with OP-TEE using FF-A as transport mechanism instead of SMC/HVC as with the TEE mediator. It allows a similar design in OP-TEE as with the TEE mediator where OP-TEE presents one virtual partition of itself to each guest in Xen. The FF-A mediator is generic in the sense it has nothing OP-TEE specific except that only the subset needed for OP-TEE is implemented so far. The hooks needed to inform OP-TEE that a guest is created or destroyed is part of the FF-A specification. It should be possible to extend the FF-A mediator to implement a larger portion of the FF-A 1.1 specification without breaking with the way OP-TEE is communicated with here. So it should be possible to support any TEE or Secure Partition using FF-A as transport with this mediator. [1] https://developer.arm.com/documentation/den0077/latest Thanks, Jens Jens Wiklander (2): xen/arm: smccc: add support for SMCCCv1.2 extended input/output registers xen/arm: add FF-A mediator xen/arch/arm/Kconfig | 11 + xen/arch/arm/Makefile|1 + xen/arch/arm/arm64/smc.S | 43 + xen/arch/arm/domain.c| 10 + xen/arch/arm/ffa.c | 1624 ++ xen/arch/arm/vsmc.c | 19 +- xen/include/asm-arm/domain.h |4 + xen/include/asm-arm/ffa.h| 71 ++ xen/include/asm-arm/smccc.h | 42 + 9 files changed, 1821 insertions(+), 4 deletions(-) create mode 100644 xen/arch/arm/ffa.c create mode 100644 xen/include/asm-arm/ffa.h -- 2.31.1
[PATCH 1/2] xen/arm: smccc: add support for SMCCCv1.2 extended input/output registers
SMCCC v1.2 AArch64 allows x0-x17 to be used as both parameter registers
and result registers for the SMC and HVC instructions.
Arm Firmware Framework for Armv8-A specification makes use of x0-x7 as
parameter and result registers.
Let us add new interface to support this extended set of input/output
registers.
This is based on 3fdc0cb59d97 ("arm64: smccc: Add support for SMCCCv1.2
extended input/output registers") by Sudeep Holla from the Linux kernel
Signed-off-by: Jens Wiklander
---
xen/arch/arm/arm64/smc.S| 43 +
xen/arch/arm/vsmc.c | 2 +-
xen/include/asm-arm/smccc.h | 42
3 files changed, 86 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/arm64/smc.S b/xen/arch/arm/arm64/smc.S
index b0752be57e8f..e024fa4d44d1 100644
--- a/xen/arch/arm/arm64/smc.S
+++ b/xen/arch/arm/arm64/smc.S
@@ -30,3 +30,46 @@ ENTRY(__arm_smccc_1_0_smc)
stp x2, x3, [x4, #SMCCC_RES_a2]
1:
ret
+
+
+/*
+ * void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args,
+ *struct arm_smccc_1_2_regs *res)
+ */
+ENTRY(arm_smccc_1_2_smc)
+/* Save `res` and free a GPR that won't be clobbered */
+stp x1, x19, [sp, #-16]!
+
+/* Ensure `args` won't be clobbered while loading regs in next step */
+movx19, x0
+
+/* Load the registers x0 - x17 from the struct arm_smccc_1_2_regs */
+ldpx0, x1, [x19, #0]
+ldpx2, x3, [x19, #16]
+ldpx4, x5, [x19, #32]
+ldpx6, x7, [x19, #48]
+ldpx8, x9, [x19, #64]
+ldpx10, x11, [x19, #80]
+ldpx12, x13, [x19, #96]
+ldpx14, x15, [x19, #112]
+ldpx16, x17, [x19, #128]
+
+smc #0
+
+/* Load the `res` from the stack */
+ldrx19, [sp]
+
+/* Store the registers x0 - x17 into the result structure */
+stpx0, x1, [x19, #0]
+stpx2, x3, [x19, #16]
+stpx4, x5, [x19, #32]
+stpx6, x7, [x19, #48]
+stpx8, x9, [x19, #64]
+stpx10, x11, [x19, #80]
+stpx12, x13, [x19, #96]
+stpx14, x15, [x19, #112]
+stpx16, x17, [x19, #128]
+
+/* Restore original x19 */
+ldp xzr, x19, [sp], #16
+ret
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index a36db15fffc0..33b0ddc634da 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -93,7 +93,7 @@ static bool handle_arch(struct cpu_user_regs *regs)
switch ( fid )
{
case ARM_SMCCC_VERSION_FID:
-set_user_reg(regs, 0, ARM_SMCCC_VERSION_1_1);
+set_user_reg(regs, 0, ARM_SMCCC_VERSION_1_2);
return true;
case ARM_SMCCC_ARCH_FEATURES_FID:
diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 9d94beb3df2d..8128283bc7b6 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -33,6 +33,7 @@
#define ARM_SMCCC_VERSION_1_0 SMCCC_VERSION(1, 0)
#define ARM_SMCCC_VERSION_1_1 SMCCC_VERSION(1, 1)
+#define ARM_SMCCC_VERSION_1_2 SMCCC_VERSION(1, 2)
/*
* This file provides common defines for ARM SMC Calling Convention as
@@ -217,6 +218,7 @@ struct arm_smccc_res {
#ifdef CONFIG_ARM_32
#define arm_smccc_1_0_smc(...) arm_smccc_1_1_smc(__VA_ARGS__)
#define arm_smccc_smc(...) arm_smccc_1_1_smc(__VA_ARGS__)
+
#else
void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2,
@@ -265,8 +267,48 @@ void __arm_smccc_1_0_smc(register_t a0, register_t a1,
register_t a2,
else\
arm_smccc_1_0_smc(__VA_ARGS__); \
} while ( 0 )
+
+/**
+ * struct arm_smccc_1_2_regs - Arguments for or Results from SMC call
+ * @a0-a17 argument values from registers 0 to 17
+ */
+struct arm_smccc_1_2_regs {
+unsigned long a0;
+unsigned long a1;
+unsigned long a2;
+unsigned long a3;
+unsigned long a4;
+unsigned long a5;
+unsigned long a6;
+unsigned long a7;
+unsigned long a8;
+unsigned long a9;
+unsigned long a10;
+unsigned long a11;
+unsigned long a12;
+unsigned long a13;
+unsigned long a14;
+unsigned long a15;
+unsigned long a16;
+unsigned long a17;
+};
#endif /* CONFIG_ARM_64 */
+/**
+ * arm_smccc_1_2_smc() - make SMC calls
+ * @args: arguments passed via struct arm_smccc_1_2_regs
+ * @res: result values via struct arm_smccc_1_2_regs
+ *
+ * This function is used to make SMC calls following SMC Calling Convention
+ * v1.2 or above. The content of the supplied param are copied from the
+ * structure to registers prior to the SMC instruction. The return values
+ * are updated with the content from registers on return from the SMC
+ * instruction.
+ */
+void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args,
+ struct arm_smccc_1_2_regs *res);
+
+
#endif /* __ASSEMBLY__ */
/*
--
2.31.1
Re: [PATCH v2 3/3] x86/vmx: implement Notify VM Exit
On Tue, Jun 07, 2022 at 09:43:25AM +0200, Jan Beulich wrote:
> On 03.06.2022 16:46, Roger Pau Monné wrote:
> > On Fri, Jun 03, 2022 at 02:49:54PM +0200, Jan Beulich wrote:
> >> On 26.05.2022 13:11, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/hvm/vmx/vmx.c
> >>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> >>> @@ -1419,10 +1419,19 @@ static void cf_check vmx_update_host_cr3(struct
> >>> vcpu *v)
> >>>
> >>> void vmx_update_debug_state(struct vcpu *v)
> >>> {
> >>> +unsigned int mask = 1u << TRAP_int3;
> >>> +
> >>> +if ( !cpu_has_monitor_trap_flag && cpu_has_vmx_notify_vm_exiting )
> >>
> >> I'm puzzled by the lack of symmetry between this and ...
> >>
> >>> +/*
> >>> + * Only allow toggling TRAP_debug if notify VM exit is enabled,
> >>> as
> >>> + * unconditionally setting TRAP_debug is part of the XSA-156 fix.
> >>> + */
> >>> +mask |= 1u << TRAP_debug;
> >>> +
> >>> if ( v->arch.hvm.debug_state_latch )
> >>> -v->arch.hvm.vmx.exception_bitmap |= 1U << TRAP_int3;
> >>> +v->arch.hvm.vmx.exception_bitmap |= mask;
> >>> else
> >>> -v->arch.hvm.vmx.exception_bitmap &= ~(1U << TRAP_int3);
> >>> +v->arch.hvm.vmx.exception_bitmap &= ~mask;
> >>>
> >>> vmx_vmcs_enter(v);
> >>> vmx_update_exception_bitmap(v);
> >>> @@ -4155,6 +4164,9 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
> >>> switch ( vector )
> >>> {
> >>> case TRAP_debug:
> >>> +if ( cpu_has_monitor_trap_flag &&
> >>> cpu_has_vmx_notify_vm_exiting )
> >>> +goto exit_and_crash;
> >>
> >> ... this condition. Shouldn't one be the inverse of the other (and
> >> then it's the one down here which wants adjusting)?
> >
> > The condition in vmx_update_debug_state() sets the mask so that
> > TRAP_debug will only be added or removed from the bitmap if
> > !cpu_has_monitor_trap_flag && cpu_has_vmx_notify_vm_exiting (note that
> > otherwise TRAP_debug is unconditionally set if
> > !cpu_has_vmx_notify_vm_exiting).
> >
> > Hence it's impossible to get a VMExit TRAP_debug with
> > cpu_has_monitor_trap_flag && cpu_has_vmx_notify_vm_exiting because
> > TRAP_debug will never be set by vmx_update_debug_state() in that
> > case.
>
> Hmm, yes, I've been misguided by you not altering the existing setting
> of v->arch.hvm.vmx.exception_bitmap in construct_vmcs(). Instead you
> add an entirely new block of code near the bottom of the function. Is
> there any chance you could move up that adjustment, perhaps along the
> lines of
>
> v->arch.hvm.vmx.exception_bitmap = HVM_TRAP_MASK
> | (paging_mode_hap(d) ? 0 : (1U << TRAP_page_fault))
> | (v->arch.fully_eager_fpu ? 0 : (1U << TRAP_no_device));
> if ( cpu_has_vmx_notify_vm_exiting )
> {
> __vmwrite(NOTIFY_WINDOW, vm_notify_window);
> /*
> * Disable #AC and #DB interception: by using VM Notify Xen is
> * guaranteed to get a VM exit even if the guest manages to lock the
> * CPU.
> */
> v->arch.hvm.vmx.exception_bitmap &= ~((1U << TRAP_debug) |
> (1U << TRAP_alignment_check));
> }
> vmx_update_exception_bitmap(v);
Sure, will move up when posting a new version then. I will wait for
feedback from Jun or Kevin regarding the default window size before
doing so.
Thanks, Roger.
Re: [PATCH v2 1/3] x86/vmx: implement Bus Lock detection
On Tue, Jun 07, 2022 at 08:54:15AM +0200, Jan Beulich wrote:
> On 06.06.2022 15:27, Andrew Cooper wrote:
> > On 26/05/2022 12:11, Roger Pau Monne wrote:
> >> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> >> index f08a00dcbb..476ab72463 100644
> >> --- a/xen/arch/x86/hvm/vmx/vmx.c
> >> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> >> @@ -4065,6 +4065,16 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
> >>
> >> if ( unlikely(exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY) )
> >> return vmx_failed_vmentry(exit_reason, regs);
> >> +if ( unlikely(exit_reason & VMX_EXIT_REASONS_BUS_LOCK) )
> >> +{
> >> +/*
> >> + * Delivery of Bus Lock VM exit was pre-empted by a higher
> >> priority VM
> >> + * exit.
> >> + */
> >> +exit_reason &= ~VMX_EXIT_REASONS_BUS_LOCK;
> >> +if ( exit_reason != EXIT_REASON_BUS_LOCK )
> >> +perfc_incr(buslock);
> >> +}
> >
> > I know this post-dates you posting v2, but given the latest update from
> > Intel, VMX_EXIT_REASONS_BUS_LOCK will be set on all exits.
>
> Mind me asking what "latest update" you're referring to? Neither SDM nor
> ISE have seen a recent update, afaict.
After Andrew's request we got in touch with Intel regarding whether
VMX_EXIT_REASONS_BUS_LOCK is set when exit_reason ==
EXIT_REASON_BUS_LOCK, and they will update the ISE to contain:
"the bit 26 in the exit-reason field will always be set on VM exits
due to bus locks."
So I will apply the changes requested by Andrew to match this
behavior.
Thanks, Roger.
Re: [PATCH v6 7/9] xen/arm: unpopulate memory when domain is static
Hi Penny, On 07/06/2022 08:30, Penny Zheng wrote: Today when a domain unpopulates the memory on runtime, they will always hand the memory back to the heap allocator. And it will be a problem if domain is static. Pages as guest RAM for static domain shall be reserved to only this domain and not be used for any other purposes, so they shall never go back to heap allocator. This commit puts reserved pages on the new list resv_page_list only after having taken them off the "normal" list, when the last ref dropped. Signed-off-by: Penny Zheng Acked-by: Jan Beulich --- v6 changes: - refine in-code comment - move PGC_static !CONFIG_STATIC_MEMORY definition to common header I don't understand why this change is necessary for this patch. AFAICT, all the users of PGC_static will be protected by #ifdef CONFIG_STATIC_MEMORY and therefore PGC_static should always be defined. Cheers, -- Julien Grall
Re: [PATCH v6 2/9] xen: do not free reserved memory into heap
Hi Penny,
On 07/06/2022 08:30, Penny Zheng wrote:
Pages used as guest RAM for static domain, shall be reserved to this
domain only.
So in case reserved pages being used for other purpose, users
shall not free them back to heap, even when last ref gets dropped.
free_staticmem_pages will be called by free_heap_pages in runtime
for static domain freeing memory resource, so let's drop the __init
flag.
Signed-off-by: Penny Zheng
---
v6 changes:
- adapt to PGC_static
- remove #ifdef aroud function declaration
---
v5 changes:
- In order to avoid stub functions, we #define PGC_staticmem to non-zero only
when CONFIG_STATIC_MEMORY
- use "unlikely()" around pg->count_info & PGC_staticmem
- remove pointless "if", since mark_page_free() is going to set count_info
to PGC_state_free and by consequence clear PGC_staticmem
- move #define PGC_staticmem 0 to mm.h
---
v4 changes:
- no changes
---
v3 changes:
- fix possible racy issue in free_staticmem_pages()
- introduce a stub free_staticmem_pages() for the !CONFIG_STATIC_MEMORY case
- move the change to free_heap_pages() to cover other potential call sites
- fix the indentation
---
v2 changes:
- new commit
---
xen/arch/arm/include/asm/mm.h | 4 +++-
xen/common/page_alloc.c | 12 +---
xen/include/xen/mm.h | 2 --
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
index fbff11c468..7442893e77 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -108,9 +108,11 @@ struct page_info
/* Page is Xen heap? */
#define _PGC_xen_heap PG_shift(2)
#define PGC_xen_heap PG_mask(1, 2)
- /* Page is static memory */
NITpicking: You added this comment in patch #1 and now removing the
space. Any reason to drop the space?
+#ifdef CONFIG_STATIC_MEMORY
I think this change ought to be explained in the commit message. AFAIU,
this is necessary to allow the compiler to remove code and avoid linking
issues. Is that correct?
+/* Page is static memory */
#define _PGC_staticPG_shift(3)
#define PGC_static PG_mask(1, 3)
+#endif
/* ... */
/* Page is broken? */
#define _PGC_broken PG_shift(7)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 9e5c757847..6876869fa6 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1443,6 +1443,13 @@ static void free_heap_pages(
ASSERT(order <= MAX_ORDER);
+if ( unlikely(pg->count_info & PGC_static) )
+{
+/* Pages of static memory shall not go back to the heap. */
+free_staticmem_pages(pg, 1UL << order, need_scrub);
I can't remember whether I asked this before (I couldn't find a thread).
free_staticmem_pages() doesn't seem to be protected by any lock. So how
do you prevent the concurrent access to the page info with the acquire part?
Cheers,
--
Julien Grall
Re: [PATCH v6 1/9] xen/arm: rename PGC_reserved to PGC_static
Hi,
On 07/06/2022 08:30, Penny Zheng wrote:
PGC_reserved could be ambiguous, and we have to tell what the pages are
reserved for, so this commit intends to rename PGC_reserved to
PGC_static, which clearly indicates the page is reserved for static
memory.
Signed-off-by: Penny Zheng
Acked-by: Julien Grall
Cheers,
---
v6 changes:
- rename PGC_staticmem to PGC_static
---
v5 changes:
- new commit
---
xen/arch/arm/include/asm/mm.h | 6 +++---
xen/common/page_alloc.c | 22 +++---
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
index 424aaf2823..fbff11c468 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -108,9 +108,9 @@ struct page_info
/* Page is Xen heap? */
#define _PGC_xen_heap PG_shift(2)
#define PGC_xen_heap PG_mask(1, 2)
- /* Page is reserved */
-#define _PGC_reserved PG_shift(3)
-#define PGC_reserved PG_mask(1, 3)
+ /* Page is static memory */
+#define _PGC_staticPG_shift(3)
+#define PGC_static PG_mask(1, 3)
/* ... */
/* Page is broken? */
#define _PGC_broken PG_shift(7)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 319029140f..9e5c757847 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -151,8 +151,8 @@
#define p2m_pod_offline_or_broken_replace(pg) BUG_ON(pg != NULL)
#endif
-#ifndef PGC_reserved
-#define PGC_reserved 0
+#ifndef PGC_static
+#define PGC_static 0
#endif
/*
@@ -2286,7 +2286,7 @@ int assign_pages(
for ( i = 0; i < nr; i++ )
{
-ASSERT(!(pg[i].count_info & ~(PGC_extra | PGC_reserved)));
+ASSERT(!(pg[i].count_info & ~(PGC_extra | PGC_static)));
if ( pg[i].count_info & PGC_extra )
extra_pages++;
}
@@ -2346,7 +2346,7 @@ int assign_pages(
page_set_owner([i], d);
smp_wmb(); /* Domain pointer must be visible before updating refcnt.
*/
pg[i].count_info =
-(pg[i].count_info & (PGC_extra | PGC_reserved)) | PGC_allocated |
1;
+(pg[i].count_info & (PGC_extra | PGC_static)) | PGC_allocated | 1;
page_list_add_tail([i], page_to_list(d, [i]));
}
@@ -2652,8 +2652,8 @@ void __init free_staticmem_pages(struct page_info *pg,
unsigned long nr_mfns,
scrub_one_page(pg);
}
-/* In case initializing page of static memory, mark it PGC_reserved. */
-pg[i].count_info |= PGC_reserved;
+/* In case initializing page of static memory, mark it PGC_static. */
+pg[i].count_info |= PGC_static;
}
}
@@ -2682,8 +2682,8 @@ static struct page_info * __init acquire_staticmem_pages(mfn_t smfn,
for ( i = 0; i < nr_mfns; i++ )
{
-/* The page should be reserved and not yet allocated. */
-if ( pg[i].count_info != (PGC_state_free | PGC_reserved) )
+/* The page should be static and not yet allocated. */
+if ( pg[i].count_info != (PGC_state_free | PGC_static) )
{
printk(XENLOG_ERR
"pg[%lu] Static MFN %"PRI_mfn" c=%#lx t=%#x\n",
@@ -2697,10 +2697,10 @@ static struct page_info * __init
acquire_staticmem_pages(mfn_t smfn,
_timestamp);
/*
- * Preserve flag PGC_reserved and change page state
+ * Preserve flag PGC_static and change page state
* to PGC_state_inuse.
*/
-pg[i].count_info = PGC_reserved | PGC_state_inuse;
+pg[i].count_info = PGC_static | PGC_state_inuse;
/* Initialise fields which have other uses for free pages. */
pg[i].u.inuse.type_info = 0;
page_set_owner([i], NULL);
@@ -2722,7 +2722,7 @@ static struct page_info * __init
acquire_staticmem_pages(mfn_t smfn,
out_err:
while ( i-- )
-pg[i].count_info = PGC_reserved | PGC_state_free;
+pg[i].count_info = PGC_static | PGC_state_free;
spin_unlock(_lock);
--
Julien Grall
Re: [PATCH RFC 3/6] x86/ioapic: RTE modifications must use ioapic_write_entry
On 03.06.2022 17:01, Roger Pau Monné wrote:
> On Fri, Jun 03, 2022 at 03:34:33PM +0200, Jan Beulich wrote:
>> On 21.04.2022 15:21, Roger Pau Monne wrote:
>>> Do not allow to write to RTE registers using io_apic_write and instead
>>> require changes to RTE to be performed using ioapic_write_entry.
>>
>> Hmm, this doubles the number of MMIO access in affected code fragments.
>
> But it does allow to simplify the IOMMU side quite a lot by no longer
> having to update the IRTE using two different calls. I'm quite sure
> it saves quite some accesses to the IOMMU RTE in the following
> patches.
Right. You may want to mention upsides and downsides (and the ultimate
balance) in the description.
>>> --- a/xen/arch/x86/include/asm/io_apic.h
>>> +++ b/xen/arch/x86/include/asm/io_apic.h
>>> @@ -161,22 +161,11 @@ static inline void __io_apic_write(unsigned int apic,
>>> unsigned int reg, unsigned
>>>
>>> static inline void io_apic_write(unsigned int apic, unsigned int reg,
>>> unsigned int value)
>>> {
>>> -if ( ioapic_reg_remapped(reg) )
>>> -return iommu_update_ire_from_apic(apic, reg, value);
>>> +/* RTE writes must use ioapic_write_entry. */
>>> +BUG_ON(reg >= 0x10);
>>> __io_apic_write(apic, reg, value);
>>> }
>>>
>>> -/*
>>> - * Re-write a value: to be used for read-modify-write
>>> - * cycles where the read already set up the index register.
>>> - */
>>> -static inline void io_apic_modify(unsigned int apic, unsigned int reg,
>>> unsigned int value)
>>> -{
>>> -if ( ioapic_reg_remapped(reg) )
>>> -return iommu_update_ire_from_apic(apic, reg, value);
>>> -*(IO_APIC_BASE(apic) + 4) = value;
>>> -}
>>
>> While the last caller goes away, I don't think this strictly needs to
>> be dropped (but could just gain a BUG_ON() like you do a few lines up)?
>
> Hm, could do, but it won't be suitable to be used to modify RTEs
> anymore, and given that was it's only usage I didn't see much value
> for leaving it around.
I could see room for use of it elsewhere, e.g. setup_ioapic_ids_from_mpc(),
io_apic_get_unique_id() (albeit read and write may be a little far apart in
both of them) or ioapic_resume(). Otoh one may argue its benefit is
marginal, so with some extra justification I could also see the function go
away at this occasion.
Jan
Re: [PATCH RFC 1/6] x86/ioapic: set disable hook for masking edge interrupts
On 03.06.2022 16:53, Roger Pau Monné wrote: > On Fri, Jun 03, 2022 at 03:19:34PM +0200, Jan Beulich wrote: >> On 21.04.2022 15:21, Roger Pau Monne wrote: >>> Allow disabling (masking) IO-APIC pins set to edge trigger mode. This >>> is required in order to safely migrate such interrupts between CPUs, >>> as the write to update the IO-APIC RTE (or the IRTE) is not done >>> atomically, >> >> For IRTE on VT-d we use cmpxchg16b if available (i.e. virtually always). >> >>> so there's a window where there's a mismatch between the >>> destination CPU and the vector: >>> >>> (XEN) CPU1: No irq handler for vector b5 (IRQ -11, LAPIC) >>> (XEN) IRQ10 a=0002[0002,0008] v=bd[b5] t=IO-APIC-edge s=0030 >> >> I think this needs some further explanation, as we generally move >> edge IRQs only when an un-acked interrupt is in flight (and hence >> no further one can arrive). > > A further one can arrive as soon as you modify either the vector or > the destination fields of the IO-APIC RTE, as then the non-EOI'ed > lapic vector is no longer there (because you have moved to a different > destination or vector). Right - this is what I'm asking you to spell out in the description. Jan > This is the issue with updating the IO-APIC RTE using two separate > writes: even when using interrupt remapping the IRTE cannot be > atomically updated and there's a window where the interrupt is not > masked, but the destination and vector fields are not in sync, because > they reside in different parts of the RTE (destination is in the high > 32bits, vector in the low 32bits part of the RTE). > > Thanks, Roger. >
Re: [PATCH v6 9/9] xen: retrieve reserved pages on populate_physmap
On 07.06.2022 09:30, Penny Zheng wrote:
> +/*
> + * Acquire a page from reserved page list(resv_page_list), when populating
> + * memory for static domain on runtime.
> + */
> +mfn_t acquire_reserved_page(struct domain *d, unsigned int memflags)
> +{
> +struct page_info *page;
> +
> +spin_lock(>page_alloc_lock);
> +/* Acquire a page from reserved page list(resv_page_list). */
> +page = page_list_remove_head(>resv_page_list);
> +spin_unlock(>page_alloc_lock);
With page removal done under lock, ...
> +if ( unlikely(!page) )
> +return INVALID_MFN;
> +
> +if ( !prepare_staticmem_pages(page, 1, memflags) )
> +goto fail;
> +
> +if ( assign_domstatic_pages(d, page, 1, memflags) )
> +goto fail;
> +
> +return page_to_mfn(page);
> +
> + fail:
> +page_list_add_tail(page, >resv_page_list);
> +return INVALID_MFN;
... doesn't re-adding the page to the list also need to be done
with the lock held?
Jan
Re: [PATCH v6 6/9] xen/arm: introduce CDF_staticmem
On 07.06.2022 09:30, Penny Zheng wrote:
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -3287,9 +3287,12 @@ void __init create_domUs(void)
> if ( !dt_device_is_compatible(node, "xen,domain") )
> continue;
>
> +if ( dt_find_property(node, "xen,static-mem", NULL) )
> +flags |= CDF_staticmem;
> +
> if ( dt_property_read_bool(node, "direct-map") )
> {
> -if ( !IS_ENABLED(CONFIG_STATIC_MEMORY) ||
> !dt_find_property(node, "xen,static-mem", NULL) )
> +if ( !IS_ENABLED(CONFIG_STATIC_MEMORY) || !(flags &
> CDF_staticmem) )
> panic("direct-map is not valid for domain %s without static
> allocation.\n",
>dt_node_name(node));
I think there's either a change needed elsewhere (which you may have in a
later patch, but which would look to belong here) or you may want to deal
right here with CDF_staticmem being invalid without STATIC_MEMORY:
if ( IS_ENABLED(CONFIG_STATIC_MEMORY) &&
dt_find_property(node, "xen,static-mem", NULL) )
flags |= CDF_staticmem;
if ( dt_property_read_bool(node, "direct-map") )
{
if ( !(flags & CDF_staticmem) )
panic("direct-map is not valid for domain %s without static
allocation.\n",
dt_node_name(node));
Another option would seem to be
/* Is domain memory on static allocation? */
#ifdef CONFIG_STATIC_MEMORY
# define CDF_staticmem(1U << 2)
#else
# define CDF_staticmem0
#endif
in xen/domain.h (at which point no IS_ENABLED() would be needed
anymore afaict).
Jan
Re: [PATCH v6 2/9] xen: do not free reserved memory into heap
On 07.06.2022 09:30, Penny Zheng wrote: > Pages used as guest RAM for static domain, shall be reserved to this > domain only. > So in case reserved pages being used for other purpose, users > shall not free them back to heap, even when last ref gets dropped. > > free_staticmem_pages will be called by free_heap_pages in runtime > for static domain freeing memory resource, so let's drop the __init > flag. > > Signed-off-by: Penny Zheng Acked-by: Jan Beulich
Re: [PATCH v6 1/9] xen/arm: rename PGC_reserved to PGC_static
On 07.06.2022 09:30, Penny Zheng wrote: > PGC_reserved could be ambiguous, and we have to tell what the pages are > reserved for, so this commit intends to rename PGC_reserved to > PGC_static, which clearly indicates the page is reserved for static > memory. > > Signed-off-by: Penny Zheng Acked-by: Jan Beulich
Re: [PATCH v2 3/3] x86/vmx: implement Notify VM Exit
On 03.06.2022 16:46, Roger Pau Monné wrote:
> On Fri, Jun 03, 2022 at 02:49:54PM +0200, Jan Beulich wrote:
>> On 26.05.2022 13:11, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -1419,10 +1419,19 @@ static void cf_check vmx_update_host_cr3(struct
>>> vcpu *v)
>>>
>>> void vmx_update_debug_state(struct vcpu *v)
>>> {
>>> +unsigned int mask = 1u << TRAP_int3;
>>> +
>>> +if ( !cpu_has_monitor_trap_flag && cpu_has_vmx_notify_vm_exiting )
>>
>> I'm puzzled by the lack of symmetry between this and ...
>>
>>> +/*
>>> + * Only allow toggling TRAP_debug if notify VM exit is enabled, as
>>> + * unconditionally setting TRAP_debug is part of the XSA-156 fix.
>>> + */
>>> +mask |= 1u << TRAP_debug;
>>> +
>>> if ( v->arch.hvm.debug_state_latch )
>>> -v->arch.hvm.vmx.exception_bitmap |= 1U << TRAP_int3;
>>> +v->arch.hvm.vmx.exception_bitmap |= mask;
>>> else
>>> -v->arch.hvm.vmx.exception_bitmap &= ~(1U << TRAP_int3);
>>> +v->arch.hvm.vmx.exception_bitmap &= ~mask;
>>>
>>> vmx_vmcs_enter(v);
>>> vmx_update_exception_bitmap(v);
>>> @@ -4155,6 +4164,9 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>>> switch ( vector )
>>> {
>>> case TRAP_debug:
>>> +if ( cpu_has_monitor_trap_flag &&
>>> cpu_has_vmx_notify_vm_exiting )
>>> +goto exit_and_crash;
>>
>> ... this condition. Shouldn't one be the inverse of the other (and
>> then it's the one down here which wants adjusting)?
>
> The condition in vmx_update_debug_state() sets the mask so that
> TRAP_debug will only be added or removed from the bitmap if
> !cpu_has_monitor_trap_flag && cpu_has_vmx_notify_vm_exiting (note that
> otherwise TRAP_debug is unconditionally set if
> !cpu_has_vmx_notify_vm_exiting).
>
> Hence it's impossible to get a VMExit TRAP_debug with
> cpu_has_monitor_trap_flag && cpu_has_vmx_notify_vm_exiting because
> TRAP_debug will never be set by vmx_update_debug_state() in that
> case.
Hmm, yes, I've been misguided by you not altering the existing setting
of v->arch.hvm.vmx.exception_bitmap in construct_vmcs(). Instead you
add an entirely new block of code near the bottom of the function. Is
there any chance you could move up that adjustment, perhaps along the
lines of
v->arch.hvm.vmx.exception_bitmap = HVM_TRAP_MASK
| (paging_mode_hap(d) ? 0 : (1U << TRAP_page_fault))
| (v->arch.fully_eager_fpu ? 0 : (1U << TRAP_no_device));
if ( cpu_has_vmx_notify_vm_exiting )
{
__vmwrite(NOTIFY_WINDOW, vm_notify_window);
/*
* Disable #AC and #DB interception: by using VM Notify Xen is
* guaranteed to get a VM exit even if the guest manages to lock the
* CPU.
*/
v->arch.hvm.vmx.exception_bitmap &= ~((1U << TRAP_debug) |
(1U << TRAP_alignment_check));
}
vmx_update_exception_bitmap(v);
Jan
[PATCH v6 8/9] xen: introduce prepare_staticmem_pages
Later, we want to use acquire_domstatic_pages() for populating memory
for static domain on runtime, however, there are a lot of pointless work
(checking mfn_valid(), scrubbing the free part, cleaning the cache...)
considering we know the page is valid and belong to the guest.
This commit splits acquire_staticmem_pages() in two parts, and
introduces prepare_staticmem_pages to bypass all "pointless work".
Signed-off-by: Penny Zheng
Acked-by: Jan Beulich
---
v6 changes:
- adapt to PGC_static
---
v5 changes:
- new commit
---
xen/common/page_alloc.c | 61 -
1 file changed, 36 insertions(+), 25 deletions(-)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 886b5d82a2..9004dd41c1 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2661,26 +2661,13 @@ void free_staticmem_pages(struct page_info *pg,
unsigned long nr_mfns,
}
}
-/*
- * Acquire nr_mfns contiguous reserved pages, starting at #smfn, of
- * static memory.
- * This function needs to be reworked if used outside of boot.
- */
-static struct page_info * __init acquire_staticmem_pages(mfn_t smfn,
- unsigned long nr_mfns,
- unsigned int memflags)
+static bool __init prepare_staticmem_pages(struct page_info *pg,
+ unsigned long nr_mfns,
+ unsigned int memflags)
{
bool need_tlbflush = false;
uint32_t tlbflush_timestamp = 0;
unsigned long i;
-struct page_info *pg;
-
-ASSERT(nr_mfns);
-for ( i = 0; i < nr_mfns; i++ )
-if ( !mfn_valid(mfn_add(smfn, i)) )
-return NULL;
-
-pg = mfn_to_page(smfn);
spin_lock(_lock);
@@ -2691,7 +2678,7 @@ static struct page_info * __init
acquire_staticmem_pages(mfn_t smfn,
{
printk(XENLOG_ERR
"pg[%lu] Static MFN %"PRI_mfn" c=%#lx t=%#x\n",
- i, mfn_x(smfn) + i,
+ i, mfn_x(page_to_mfn(pg)) + i,
pg[i].count_info, pg[i].tlbflush_timestamp);
goto out_err;
}
@@ -2715,6 +2702,38 @@ static struct page_info * __init
acquire_staticmem_pages(mfn_t smfn,
if ( need_tlbflush )
filtered_flush_tlb_mask(tlbflush_timestamp);
+return true;
+
+ out_err:
+while ( i-- )
+pg[i].count_info = PGC_static | PGC_state_free;
+
+spin_unlock(_lock);
+
+return false;
+}
+
+/*
+ * Acquire nr_mfns contiguous reserved pages, starting at #smfn, of
+ * static memory.
+ * This function needs to be reworked if used outside of boot.
+ */
+static struct page_info * __init acquire_staticmem_pages(mfn_t smfn,
+ unsigned long nr_mfns,
+ unsigned int memflags)
+{
+unsigned long i;
+struct page_info *pg;
+
+ASSERT(nr_mfns);
+for ( i = 0; i < nr_mfns; i++ )
+if ( !mfn_valid(mfn_add(smfn, i)) )
+return NULL;
+
+pg = mfn_to_page(smfn);
+if ( !prepare_staticmem_pages(pg, nr_mfns, memflags) )
+return NULL;
+
/*
* Ensure cache and RAM are consistent for platforms where the guest
* can control its own visibility of/through the cache.
@@ -2723,14 +2742,6 @@ static struct page_info * __init
acquire_staticmem_pages(mfn_t smfn,
flush_page_to_ram(mfn_x(smfn) + i, !(memflags & MEMF_no_icache_flush));
return pg;
-
- out_err:
-while ( i-- )
-pg[i].count_info = PGC_static | PGC_state_free;
-
-spin_unlock(_lock);
-
-return NULL;
}
/*
--
2.25.1
[PATCH v6 7/9] xen/arm: unpopulate memory when domain is static
Today when a domain unpopulates the memory on runtime, they will always
hand the memory back to the heap allocator. And it will be a problem if domain
is static.
Pages as guest RAM for static domain shall be reserved to only this domain
and not be used for any other purposes, so they shall never go back to heap
allocator.
This commit puts reserved pages on the new list resv_page_list only after
having taken them off the "normal" list, when the last ref dropped.
Signed-off-by: Penny Zheng
Acked-by: Jan Beulich
---
v6 changes:
- refine in-code comment
- move PGC_static !CONFIG_STATIC_MEMORY definition to common header
---
v5 changes:
- adapt this patch for PGC_staticmem
---
v4 changes:
- no changes
---
v3 changes:
- have page_list_del() just once out of the if()
- remove resv_pages counter
- make arch_free_heap_page be an expression, not a compound statement.
---
v2 changes:
- put reserved pages on resv_page_list after having taken them off
the "normal" list
---
xen/arch/arm/include/asm/mm.h | 12
xen/common/domain.c | 4
xen/common/page_alloc.c | 4
xen/include/xen/mm.h | 4
xen/include/xen/sched.h | 3 +++
5 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
index 7442893e77..2ce4d80796 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -360,6 +360,18 @@ void clear_and_clean_page(struct page_info *page);
unsigned int arch_get_dma_bitsize(void);
+/*
+ * Put free pages on the resv page list after having taken them
+ * off the "normal" page list, when pages from static memory
+ */
+#ifdef CONFIG_STATIC_MEMORY
+#define arch_free_heap_page(d, pg) ({ \
+page_list_del(pg, page_to_list(d, pg)); \
+if ( (pg)->count_info & PGC_static ) \
+page_list_add_tail(pg, &(d)->resv_page_list); \
+})
+#endif
+
#endif /* __ARCH_ARM_MM__ */
/*
* Local variables:
diff --git a/xen/common/domain.c b/xen/common/domain.c
index a3ef991bd1..a49574fa24 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -604,6 +604,10 @@ struct domain *domain_create(domid_t domid,
INIT_PAGE_LIST_HEAD(>page_list);
INIT_PAGE_LIST_HEAD(>extra_page_list);
INIT_PAGE_LIST_HEAD(>xenpage_list);
+#ifdef CONFIG_STATIC_MEMORY
+INIT_PAGE_LIST_HEAD(>resv_page_list);
+#endif
+
spin_lock_init(>node_affinity_lock);
d->node_affinity = NODE_MASK_ALL;
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 7fb28e2e07..886b5d82a2 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -151,10 +151,6 @@
#define p2m_pod_offline_or_broken_replace(pg) BUG_ON(pg != NULL)
#endif
-#ifndef PGC_static
-#define PGC_static 0
-#endif
-
/*
* Comma-separated list of hexadecimal page numbers containing bad bytes.
* e.g. 'badpage=0x3f45,0x8a321'.
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 1c4ddb336b..e80b4bdcde 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -210,6 +210,10 @@ extern struct domain *dom_cow;
#include
+#ifndef PGC_static
+#define PGC_static 0
+#endif
+
static inline bool is_special_page(const struct page_info *page)
{
return is_xen_heap_page(page) || (page->count_info & PGC_extra);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 5191853c18..bd2782b3c5 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -381,6 +381,9 @@ struct domain
struct page_list_head page_list; /* linked list */
struct page_list_head extra_page_list; /* linked list (size extra_pages) */
struct page_list_head xenpage_list; /* linked list (size xenheap_pages) */
+#ifdef CONFIG_STATIC_MEMORY
+struct page_list_head resv_page_list; /* linked list */
+#endif
/*
* This field should only be directly accessed by domain_adjust_tot_pages()
--
2.25.1
[PATCH v6 9/9] xen: retrieve reserved pages on populate_physmap
When a static domain populates memory through populate_physmap at runtime,
it shall retrieve reserved pages from resv_page_list to make sure that
guest RAM is still restricted in statically configured memory regions.
This commit also introduces a new helper acquire_reserved_page to make it work.
Signed-off-by: Penny Zheng
---
v6 changes:
- drop the lock before returning
---
v5 changes:
- extract common codes for assigning pages into a helper assign_domstatic_pages
- refine commit message
- remove stub function acquire_reserved_page
- Alloc/free of memory can happen concurrently. So access to rsv_page_list
needs to be protected with a spinlock
---
v4 changes：
- miss dropping __init in acquire_domstatic_pages
- add the page back to the reserved list in case of error
- remove redundant printk
- refine log message and make it warn level
---
v3 changes:
- move is_domain_using_staticmem to the common header file
- remove #ifdef CONFIG_STATIC_MEMORY-ary
- remove meaningless page_to_mfn(page) in error log
---
v2 changes:
- introduce acquire_reserved_page to retrieve reserved pages from
resv_page_list
- forbid non-zero-order requests in populate_physmap
- let is_domain_static return ((void)(d), false) on x86
---
xen/common/memory.c | 23 ++
xen/common/page_alloc.c | 70 +++--
xen/include/xen/mm.h| 1 +
3 files changed, 77 insertions(+), 17 deletions(-)
diff --git a/xen/common/memory.c b/xen/common/memory.c
index f2d009843a..cb330ce877 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -245,6 +245,29 @@ static void populate_physmap(struct memop_args *a)
mfn = _mfn(gpfn);
}
+else if ( is_domain_using_staticmem(d) )
+{
+/*
+ * No easy way to guarantee the retrieved pages are contiguous,
+ * so forbid non-zero-order requests here.
+ */
+if ( a->extent_order != 0 )
+{
+gdprintk(XENLOG_WARNING,
+ "Cannot allocate static order-%u pages for static
%pd\n",
+ a->extent_order, d);
+goto out;
+}
+
+mfn = acquire_reserved_page(d, a->memflags);
+if ( mfn_eq(mfn, INVALID_MFN) )
+{
+gdprintk(XENLOG_WARNING,
+ "%pd: failed to retrieve a reserved page\n",
+ d);
+goto out;
+}
+}
else
{
page = alloc_domheap_pages(d, a->extent_order, a->memflags);
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 9004dd41c1..57d28304df 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2661,9 +2661,8 @@ void free_staticmem_pages(struct page_info *pg, unsigned
long nr_mfns,
}
}
-static bool __init prepare_staticmem_pages(struct page_info *pg,
- unsigned long nr_mfns,
- unsigned int memflags)
+static bool prepare_staticmem_pages(struct page_info *pg, unsigned long
nr_mfns,
+unsigned int memflags)
{
bool need_tlbflush = false;
uint32_t tlbflush_timestamp = 0;
@@ -2744,21 +2743,9 @@ static struct page_info * __init
acquire_staticmem_pages(mfn_t smfn,
return pg;
}
-/*
- * Acquire nr_mfns contiguous pages, starting at #smfn, of static memory,
- * then assign them to one specific domain #d.
- */
-int __init acquire_domstatic_pages(struct domain *d, mfn_t smfn,
- unsigned int nr_mfns, unsigned int memflags)
+static int assign_domstatic_pages(struct domain *d, struct page_info *pg,
+ unsigned int nr_mfns, unsigned int memflags)
{
-struct page_info *pg;
-
-ASSERT(!in_irq());
-
-pg = acquire_staticmem_pages(smfn, nr_mfns, memflags);
-if ( !pg )
-return -ENOENT;
-
if ( !d || (memflags & (MEMF_no_owner | MEMF_no_refcount)) )
{
/*
@@ -2777,6 +2764,55 @@ int __init acquire_domstatic_pages(struct domain *d,
mfn_t smfn,
return 0;
}
+
+/*
+ * Acquire nr_mfns contiguous pages, starting at #smfn, of static memory,
+ * then assign them to one specific domain #d.
+ */
+int __init acquire_domstatic_pages(struct domain *d, mfn_t smfn,
+ unsigned int nr_mfns, unsigned int memflags)
+{
+struct page_info *pg;
+
+ASSERT(!in_irq());
+
+pg = acquire_staticmem_pages(smfn, nr_mfns, memflags);
+if ( !pg )
+return -ENOENT;
+
+if ( assign_domstatic_pages(d, pg, nr_mfns, memflags) )
+return -EINVAL;
+
+return 0;
+}
+
+/*
+ * Acquire a page from reserved page list(resv_page_list), when populating
+ * memory for static domain on runtime.
+ */
+mfn_t
[PATCH v6 6/9] xen/arm: introduce CDF_staticmem
In order to have an easy and quick way to find out whether this domain memory
is statically configured, this commit introduces a new flag CDF_staticmem and a
new helper is_domain_using_staticmem() to tell.
Signed-off-by: Penny Zheng
---
v6 changes:
- move non-zero is_domain_using_staticmem() from ARM header to common
header
---
v5 changes:
- guard "is_domain_using_staticmem" under CONFIG_STATIC_MEMORY
- #define is_domain_using_staticmem zero if undefined
---
v4 changes:
- no changes
---
v3 changes:
- change name from "is_domain_static()" to "is_domain_using_staticmem"
---
v2 changes:
- change name from "is_domain_on_static_allocation" to "is_domain_static()"
---
xen/arch/arm/domain_build.c | 5 -
xen/include/xen/domain.h| 8
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 7ddd16c26d..f6e2e44c1e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -3287,9 +3287,12 @@ void __init create_domUs(void)
if ( !dt_device_is_compatible(node, "xen,domain") )
continue;
+if ( dt_find_property(node, "xen,static-mem", NULL) )
+flags |= CDF_staticmem;
+
if ( dt_property_read_bool(node, "direct-map") )
{
-if ( !IS_ENABLED(CONFIG_STATIC_MEMORY) || !dt_find_property(node,
"xen,static-mem", NULL) )
+if ( !IS_ENABLED(CONFIG_STATIC_MEMORY) || !(flags & CDF_staticmem)
)
panic("direct-map is not valid for domain %s without static
allocation.\n",
dt_node_name(node));
diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
index 1c3c88a14d..c847452414 100644
--- a/xen/include/xen/domain.h
+++ b/xen/include/xen/domain.h
@@ -34,6 +34,14 @@ void arch_get_domain_info(const struct domain *d,
#ifdef CONFIG_ARM
/* Should domain memory be directly mapped? */
#define CDF_directmap(1U << 1)
+/* Is domain memory on static allocation? */
+#define CDF_staticmem(1U << 2)
+#endif
+
+#ifdef CONFIG_STATIC_MEMORY
+#define is_domain_using_staticmem(d) ((d)->cdf & CDF_staticmem)
+#else
+#define is_domain_using_staticmem(d) ((void)(d), false)
#endif
/*
--
2.25.1
[PATCH v6 5/9] xen: add field "flags" to cover all internal CDF_XXX
With more and more CDF_xxx internal flags in and to save the space, this
commit introduces a new field "flags" in struct domain to store CDF_*
internal flags directly.
Another new CDF_xxx will be introduced in the next patch.
Signed-off-by: Penny Zheng
Acked-by: Julien Grall
---
v6 changes:
- no change
---
v5 changes:
- no change
---
v4 changes:
- no change
---
v3 changes:
- change fixed width type uint32_t to unsigned int
- change "flags" to a more descriptive name "cdf"
---
v2 changes:
- let "flags" live in the struct domain. So other arch can take
advantage of it in the future
- fix coding style
---
xen/arch/arm/domain.c | 2 --
xen/arch/arm/include/asm/domain.h | 3 +--
xen/common/domain.c | 3 +++
xen/include/xen/sched.h | 3 +++
4 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 8110c1df86..74189d9878 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -709,8 +709,6 @@ int arch_domain_create(struct domain *d,
ioreq_domain_init(d);
#endif
-d->arch.directmap = flags & CDF_directmap;
-
/* p2m_init relies on some value initialized by the IOMMU subsystem */
if ( (rc = iommu_domain_init(d, config->iommu_opts)) != 0 )
goto fail;
diff --git a/xen/arch/arm/include/asm/domain.h
b/xen/arch/arm/include/asm/domain.h
index ed63c2b6f9..fe7a029ebf 100644
--- a/xen/arch/arm/include/asm/domain.h
+++ b/xen/arch/arm/include/asm/domain.h
@@ -29,7 +29,7 @@ enum domain_type {
#define is_64bit_domain(d) (0)
#endif
-#define is_domain_direct_mapped(d) (d)->arch.directmap
+#define is_domain_direct_mapped(d) ((d)->cdf & CDF_directmap)
/*
* Is the domain using the host memory layout?
@@ -103,7 +103,6 @@ struct arch_domain
void *tee;
#endif
-bool directmap;
} __cacheline_aligned;
struct arch_vcpu
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 7570eae91a..a3ef991bd1 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -567,6 +567,9 @@ struct domain *domain_create(domid_t domid,
/* Sort out our idea of is_system_domain(). */
d->domain_id = domid;
+/* Holding CDF_* internal flags. */
+d->cdf = flags;
+
/* Debug sanity. */
ASSERT(is_system_domain(d) ? config == NULL : config != NULL);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 463d41ffb6..5191853c18 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -596,6 +596,9 @@ struct domain
struct ioreq_server *server[MAX_NR_IOREQ_SERVERS];
} ioreq_server;
#endif
+
+/* Holding CDF_* constant. Internal flags for domain creation. */
+unsigned int cdf;
};
static inline struct page_list_head *page_to_list(
--
2.25.1
[PATCH v6 4/9] xen: do not merge reserved pages in free_heap_pages()
The code in free_heap_pages() will try to merge pages with the successor/predecessor if pages are suitably aligned. So if the pages reserved are right next to the pages given to the heap allocator, free_heap_pages() will merge them, and give the reserved pages to heap allocator accidently as a result. So in order to avoid the above scenario, this commit updates free_heap_pages() to check whether the predecessor and/or successor has PGC_reserved set, when trying to merge the about-to-be-freed chunk with the predecessor and/or successor. Suggested-by: Julien Grall Signed-off-by: Penny Zheng Reviewed-by: Jan Beulich Reviewed-by: Julien Grall --- v6 changes: - adapt to PGC_static --- v5 changes: - change PGC_reserved to adapt to PGC_staticmem --- v4 changes: - no changes --- v3 changes: - no changes --- v2 changes: - new commit --- xen/common/page_alloc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 6876869fa6..7fb28e2e07 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -1486,6 +1486,7 @@ static void free_heap_pages( /* Merge with predecessor block? */ if ( !mfn_valid(page_to_mfn(predecessor)) || !page_state_is(predecessor, free) || + (predecessor->count_info & PGC_static) || (PFN_ORDER(predecessor) != order) || (phys_to_nid(page_to_maddr(predecessor)) != node) ) break; @@ -1509,6 +1510,7 @@ static void free_heap_pages( /* Merge with successor block? */ if ( !mfn_valid(page_to_mfn(successor)) || !page_state_is(successor, free) || + (successor->count_info & PGC_static) || (PFN_ORDER(successor) != order) || (phys_to_nid(page_to_maddr(successor)) != node) ) break; -- 2.25.1
[PATCH v6 3/9] xen: update SUPPORT.md for static allocation
SUPPORT.md doesn't seem to explicitly say whether static memory is supported, so this commit updates SUPPORT.md to add feature static allocation tech preview for now. Signed-off-by: Penny Zheng Reviewed-by: Stefano Stabellini --- v6 changes: - use domain instead of sub-systems --- v5 changes: - new commit --- SUPPORT.md | 7 +++ 1 file changed, 7 insertions(+) diff --git a/SUPPORT.md b/SUPPORT.md index ee2cd319e2..f50bc3a0fd 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -278,6 +278,13 @@ to boot with memory < maxmem. Status, x86 HVM: Supported +### Static Allocation + +Static allocation refers to domains for which memory areas are +pre-defined by configuration using physical address ranges. + +Status, ARM: Tech Preview + ### Memory Sharing Allow sharing of identical pages between guests -- 2.25.1
[PATCH v6 1/9] xen/arm: rename PGC_reserved to PGC_static
PGC_reserved could be ambiguous, and we have to tell what the pages are
reserved for, so this commit intends to rename PGC_reserved to
PGC_static, which clearly indicates the page is reserved for static
memory.
Signed-off-by: Penny Zheng
---
v6 changes:
- rename PGC_staticmem to PGC_static
---
v5 changes:
- new commit
---
xen/arch/arm/include/asm/mm.h | 6 +++---
xen/common/page_alloc.c | 22 +++---
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
index 424aaf2823..fbff11c468 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -108,9 +108,9 @@ struct page_info
/* Page is Xen heap? */
#define _PGC_xen_heap PG_shift(2)
#define PGC_xen_heap PG_mask(1, 2)
- /* Page is reserved */
-#define _PGC_reserved PG_shift(3)
-#define PGC_reserved PG_mask(1, 3)
+ /* Page is static memory */
+#define _PGC_staticPG_shift(3)
+#define PGC_static PG_mask(1, 3)
/* ... */
/* Page is broken? */
#define _PGC_broken PG_shift(7)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 319029140f..9e5c757847 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -151,8 +151,8 @@
#define p2m_pod_offline_or_broken_replace(pg) BUG_ON(pg != NULL)
#endif
-#ifndef PGC_reserved
-#define PGC_reserved 0
+#ifndef PGC_static
+#define PGC_static 0
#endif
/*
@@ -2286,7 +2286,7 @@ int assign_pages(
for ( i = 0; i < nr; i++ )
{
-ASSERT(!(pg[i].count_info & ~(PGC_extra | PGC_reserved)));
+ASSERT(!(pg[i].count_info & ~(PGC_extra | PGC_static)));
if ( pg[i].count_info & PGC_extra )
extra_pages++;
}
@@ -2346,7 +2346,7 @@ int assign_pages(
page_set_owner([i], d);
smp_wmb(); /* Domain pointer must be visible before updating refcnt. */
pg[i].count_info =
-(pg[i].count_info & (PGC_extra | PGC_reserved)) | PGC_allocated |
1;
+(pg[i].count_info & (PGC_extra | PGC_static)) | PGC_allocated | 1;
page_list_add_tail([i], page_to_list(d, [i]));
}
@@ -2652,8 +2652,8 @@ void __init free_staticmem_pages(struct page_info *pg,
unsigned long nr_mfns,
scrub_one_page(pg);
}
-/* In case initializing page of static memory, mark it PGC_reserved. */
-pg[i].count_info |= PGC_reserved;
+/* In case initializing page of static memory, mark it PGC_static. */
+pg[i].count_info |= PGC_static;
}
}
@@ -2682,8 +2682,8 @@ static struct page_info * __init
acquire_staticmem_pages(mfn_t smfn,
for ( i = 0; i < nr_mfns; i++ )
{
-/* The page should be reserved and not yet allocated. */
-if ( pg[i].count_info != (PGC_state_free | PGC_reserved) )
+/* The page should be static and not yet allocated. */
+if ( pg[i].count_info != (PGC_state_free | PGC_static) )
{
printk(XENLOG_ERR
"pg[%lu] Static MFN %"PRI_mfn" c=%#lx t=%#x\n",
@@ -2697,10 +2697,10 @@ static struct page_info * __init
acquire_staticmem_pages(mfn_t smfn,
_timestamp);
/*
- * Preserve flag PGC_reserved and change page state
+ * Preserve flag PGC_static and change page state
* to PGC_state_inuse.
*/
-pg[i].count_info = PGC_reserved | PGC_state_inuse;
+pg[i].count_info = PGC_static | PGC_state_inuse;
/* Initialise fields which have other uses for free pages. */
pg[i].u.inuse.type_info = 0;
page_set_owner([i], NULL);
@@ -2722,7 +2722,7 @@ static struct page_info * __init
acquire_staticmem_pages(mfn_t smfn,
out_err:
while ( i-- )
-pg[i].count_info = PGC_reserved | PGC_state_free;
+pg[i].count_info = PGC_static | PGC_state_free;
spin_unlock(_lock);
--
2.25.1
[PATCH v6 2/9] xen: do not free reserved memory into heap
Pages used as guest RAM for static domain, shall be reserved to this
domain only.
So in case reserved pages being used for other purpose, users
shall not free them back to heap, even when last ref gets dropped.
free_staticmem_pages will be called by free_heap_pages in runtime
for static domain freeing memory resource, so let's drop the __init
flag.
Signed-off-by: Penny Zheng
---
v6 changes:
- adapt to PGC_static
- remove #ifdef aroud function declaration
---
v5 changes:
- In order to avoid stub functions, we #define PGC_staticmem to non-zero only
when CONFIG_STATIC_MEMORY
- use "unlikely()" around pg->count_info & PGC_staticmem
- remove pointless "if", since mark_page_free() is going to set count_info
to PGC_state_free and by consequence clear PGC_staticmem
- move #define PGC_staticmem 0 to mm.h
---
v4 changes:
- no changes
---
v3 changes:
- fix possible racy issue in free_staticmem_pages()
- introduce a stub free_staticmem_pages() for the !CONFIG_STATIC_MEMORY case
- move the change to free_heap_pages() to cover other potential call sites
- fix the indentation
---
v2 changes:
- new commit
---
xen/arch/arm/include/asm/mm.h | 4 +++-
xen/common/page_alloc.c | 12 +---
xen/include/xen/mm.h | 2 --
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/include/asm/mm.h b/xen/arch/arm/include/asm/mm.h
index fbff11c468..7442893e77 100644
--- a/xen/arch/arm/include/asm/mm.h
+++ b/xen/arch/arm/include/asm/mm.h
@@ -108,9 +108,11 @@ struct page_info
/* Page is Xen heap? */
#define _PGC_xen_heap PG_shift(2)
#define PGC_xen_heap PG_mask(1, 2)
- /* Page is static memory */
+#ifdef CONFIG_STATIC_MEMORY
+/* Page is static memory */
#define _PGC_staticPG_shift(3)
#define PGC_static PG_mask(1, 3)
+#endif
/* ... */
/* Page is broken? */
#define _PGC_broken PG_shift(7)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 9e5c757847..6876869fa6 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1443,6 +1443,13 @@ static void free_heap_pages(
ASSERT(order <= MAX_ORDER);
+if ( unlikely(pg->count_info & PGC_static) )
+{
+/* Pages of static memory shall not go back to the heap. */
+free_staticmem_pages(pg, 1UL << order, need_scrub);
+return;
+}
+
spin_lock(_lock);
for ( i = 0; i < (1 << order); i++ )
@@ -2636,8 +2643,8 @@ struct domain *get_pg_owner(domid_t domid)
#ifdef CONFIG_STATIC_MEMORY
/* Equivalent of free_heap_pages to free nr_mfns pages of static memory. */
-void __init free_staticmem_pages(struct page_info *pg, unsigned long nr_mfns,
- bool need_scrub)
+void free_staticmem_pages(struct page_info *pg, unsigned long nr_mfns,
+ bool need_scrub)
{
mfn_t mfn = page_to_mfn(pg);
unsigned long i;
@@ -2652,7 +2659,6 @@ void __init free_staticmem_pages(struct page_info *pg,
unsigned long nr_mfns,
scrub_one_page(pg);
}
-/* In case initializing page of static memory, mark it PGC_static. */
pg[i].count_info |= PGC_static;
}
}
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 3be754da92..1c4ddb336b 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -85,13 +85,11 @@ bool scrub_free_pages(void);
} while ( false )
#define FREE_XENHEAP_PAGE(p) FREE_XENHEAP_PAGES(p, 0)
-#ifdef CONFIG_STATIC_MEMORY
/* These functions are for static memory */
void free_staticmem_pages(struct page_info *pg, unsigned long nr_mfns,
bool need_scrub);
int acquire_domstatic_pages(struct domain *d, mfn_t smfn, unsigned int nr_mfns,
unsigned int memflags);
-#endif
/* Map machine page range in Xen virtual address space. */
int map_pages_to_xen(
--
2.25.1
[PATCH v6 0/9] populate/unpopulate memory when domain on static allocation
Today when a domain unpopulates the memory on runtime, they will always hand the memory over to the heap allocator. And it will be a problem if it is a static domain. Pages used as guest RAM for static domain shall always be reserved to this domain only, and not be used for any other purposes, so they shall never go back to heap allocator. This patch serie intends to fix this issue, by adding pages on the new list resv_page_list after having taken them off the "normal" list, when unpopulating memory, and retrieving pages from resv page list(resv_page_list) when populating memory. --- v6 changes: - rename PGC_staticmem to PGC_static - remove #ifdef aroud function declaration - use domain instead of sub-systems - move non-zero is_domain_using_staticmem() from ARM header to common header - move PGC_static !CONFIG_STATIC_MEMORY definition to common header - drop the lock before returning --- v5 changes: - introduce three new commits - In order to avoid stub functions, we #define PGC_staticmem to non-zero only when CONFIG_STATIC_MEMORY - use "unlikely()" around pg->count_info & PGC_staticmem - remove pointless "if", since mark_page_free() is going to set count_info to PGC_state_free and by consequence clear PGC_staticmem - move #define PGC_staticmem 0 to mm.h - guard "is_domain_using_staticmem" under CONFIG_STATIC_MEMORY - #define is_domain_using_staticmem zero if undefined - extract common codes for assigning pages into a helper assign_domstatic_pages - refine commit message - remove stub function acquire_reserved_page - Alloc/free of memory can happen concurrently. So access to rsv_page_list needs to be protected with a spinlock --- v4 changes: - commit message refinement - miss dropping __init in acquire_domstatic_pages - add the page back to the reserved list in case of error - remove redundant printk - refine log message and make it warn level - guard "is_domain_using_staticmem" under CONFIG_STATIC_MEMORY - #define is_domain_using_staticmem zero if undefined --- v3 changes: - fix possible racy issue in free_staticmem_pages() - introduce a stub free_staticmem_pages() for the !CONFIG_STATIC_MEMORY case - move the change to free_heap_pages() to cover other potential call sites - change fixed width type uint32_t to unsigned int - change "flags" to a more descriptive name "cdf" - change name from "is_domain_static()" to "is_domain_using_staticmem" - have page_list_del() just once out of the if() - remove resv_pages counter - make arch_free_heap_page be an expression, not a compound statement. - move #ifndef is_domain_using_staticmem to the common header file - remove #ifdef CONFIG_STATIC_MEMORY-ary - remove meaningless page_to_mfn(page) in error log --- v2 changes: - let "flags" live in the struct domain. So other arch can take advantage of it in the future - change name from "is_domain_on_static_allocation" to "is_domain_static()" - put reserved pages on resv_page_list after having taken them off the "normal" list - introduce acquire_reserved_page to retrieve reserved pages from resv_page_list - forbid non-zero-order requests in populate_physmap - let is_domain_static return ((void)(d), false) on x86 - fix coding style Penny Zheng (9): xen/arm: rename PGC_reserved to PGC_static xen: do not free reserved memory into heap xen: update SUPPORT.md for static allocation xen: do not merge reserved pages in free_heap_pages() xen: add field "flags" to cover all internal CDF_XXX xen/arm: introduce CDF_staticmem xen/arm: unpopulate memory when domain is static xen: introduce prepare_staticmem_pages xen: retrieve reserved pages on populate_physmap SUPPORT.md| 7 ++ xen/arch/arm/domain.c | 2 - xen/arch/arm/domain_build.c | 5 +- xen/arch/arm/include/asm/domain.h | 3 +- xen/arch/arm/include/asm/mm.h | 20 +++- xen/common/domain.c | 7 ++ xen/common/memory.c | 23 + xen/common/page_alloc.c | 149 -- xen/include/xen/domain.h | 8 ++ xen/include/xen/mm.h | 7 +- xen/include/xen/sched.h | 6 ++ 11 files changed, 178 insertions(+), 59 deletions(-) -- 2.25.1
Re: [PATCH v2 1/3] x86/vmx: implement Bus Lock detection
On 03.06.2022 16:29, Roger Pau Monné wrote: > On Fri, Jun 03, 2022 at 02:16:47PM +0200, Jan Beulich wrote: >> On 26.05.2022 13:11, Roger Pau Monne wrote: >>> Add support for enabling Bus Lock Detection on Intel systems. Such >>> detection works by triggering a vmexit, which ought to be enough of a >>> pause to prevent a guest from abusing of the Bus Lock. >>> >>> Add an extra Xen perf counter to track the number of Bus Locks detected. >>> This is done because Bus Locks can also be reported by setting the bit >>> 26 in the exit reason field, so also account for those. >>> >>> Suggested-by: Andrew Cooper >>> Signed-off-by: Roger Pau Monné >> >> Reviewed-by: Jan Beulich >> >> This implements just the VMexit part of the feature - maybe the >> title wants to reflect that? The vmx: tag could also mean there >> is exposure to guests included for the #DB part of the feature. > > Maybe: > > "x86/vmx: add Bus Lock detection to the hypervisor" Fine with me. Jan
Re: memory overcomittment with sr-iov device assighment
On 07.06.2022 05:59, alex.nln...@proton.me wrote: > I looked into Xen documentation and also Xen wiki and I could't find a > definitive answer if Xen supports memory over-commitment when VMs use SR-IOV > device assignment (passthrough). Memory over-commitment I mean giving VMs > more RAM than is available in the host. > > I know that ESX doesn't support it, and also QEMU/KVM pins all RAM when a > device is directly assigned to a VM (VFIO_IOMMU_MAP_DMA ioctl). I have two > questions: > > 1. Does Xen supports memory over commitment when all VMs are using direct > device assignment e.g., SR-IOV? What you describe looks to match mem-paging / mem-sharing in Xen. Neither is compatible with device pass-through (SR-IOV or not is irrelevant), and both are only in "experimental" state anyway. > 2. Would you please point me to the code that does the pinning? That's a KVM concept with no direct equivalent in Xen (largely due to Xen being a type-1 hypervisor, while KVM is a type-2 one). Jan
Re: [PATCH v2 1/3] x86/vmx: implement Bus Lock detection
On 06.06.2022 15:27, Andrew Cooper wrote:
> On 26/05/2022 12:11, Roger Pau Monne wrote:
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> index f08a00dcbb..476ab72463 100644
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -4065,6 +4065,16 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>>
>> if ( unlikely(exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY) )
>> return vmx_failed_vmentry(exit_reason, regs);
>> +if ( unlikely(exit_reason & VMX_EXIT_REASONS_BUS_LOCK) )
>> +{
>> +/*
>> + * Delivery of Bus Lock VM exit was pre-empted by a higher priority
>> VM
>> + * exit.
>> + */
>> +exit_reason &= ~VMX_EXIT_REASONS_BUS_LOCK;
>> +if ( exit_reason != EXIT_REASON_BUS_LOCK )
>> +perfc_incr(buslock);
>> +}
>
> I know this post-dates you posting v2, but given the latest update from
> Intel, VMX_EXIT_REASONS_BUS_LOCK will be set on all exits.
Mind me asking what "latest update" you're referring to? Neither SDM nor
ISE have seen a recent update, afaict.
Jan
Re: [XEN PATCH 1/4] build: xen/include: use if_changed
On 06.06.2022 15:39, Anthony PERARD wrote: > On Thu, Jun 02, 2022 at 11:11:15AM +0200, Jan Beulich wrote: >> On 01.06.2022 18:59, Anthony PERARD wrote: >>> Use "define" for the headers*_chk commands as otherwise the "#" >>> is interpreted as a comment and make can't find the end of >>> $(foreach,). >> >> In cmd_xlat_lst you use $(pound) - any reason this doesn't work in >> these rules? Note that I don't mind the use of "define", just that I'm >> puzzled by the justification. > > I think I just forgot about $(pound) when I tried to debug why the > command didn't work in some environment (that is when not using define). > > I think the second thing that make me not replacing '#' by "$(pound)" is > that reading "#include" in the Makefile is probably better that > reading "$(pound)include". > > I guess we should add something to the justification like: > That allow us to keep writing "#include" in the Makefile without > having to replace that by "$(pound)include" which would be a bit > less obvious about the command line purpose. I'd be okay with this, and I'd also be okay with adding this while committing. With it added Acked-by: Jan Beulich Jan
Re: MOVING COMMUNITY CALL Call for agenda items for 9 June Community Call @ 1500 UTC
On 07.06.2022 04:17, Stefano Stabellini wrote: > # Rule 9.4 "An element of an object shall not be initialized more than once" > > Andrew was noting that "There's one pattern using range syntax to set a > default where this rule would be violated, but the code is far cleaner > to read." I'm actually not sure we have such uses, as I seem to vaguely recall clang warning about them. Off the top of your head, do you know of an instance, Andrew? Jan > Range initializers is a GCC extension not part of the C standard. It is > not considered by the MISRA rule. The MISRA rule seems focused on > preveting accidental double-initializations (by copy/pasting errors for > instance) which is fair. > > So I think we should be OK here and we need to clarify our usage of > range initializers. What we do or don't do with range initializer should > be a separate discussion I think. >
