Messages in this thread | | | Subject | Re: [PATCH 1/4] KVM: arm64: Allow saving vgic3 LPI pending status in no running vcpu context | From | Gavin Shan <> | Date | Fri, 20 Jan 2023 10:04:50 +1100 |
| |
Hi Marc,
On 1/20/23 2:47 AM, Marc Zyngier wrote: > On Thu, 19 Jan 2023 01:11:44 +0000, > Gavin Shan <gshan@redhat.com> wrote: >> >> I will have vgic_write_guest_lock() in v2. Note that those 3 paths can't be >> running in parallel since one switch is shared by them. Alternatively, we >> extend struct vgic_dist::save_tables_in_progress from 'bool' to 'unsigned long'. >> Several bit is defined for each site as below. In this way, the 3 paths can be >> running in parallel: >> >> unsigned long struct vgic_dist::save_tables_in_progress >> >> #define VGIC_DIST_SAVE_ITS_ITE 0 /* ITS Translation Entry */ >> #define VGIC_DIST_SAVE_ITS_DTE 1 /* ITS Device Table Entry */ >> #define VGIC_DIST_SAVE_ITS_CTE 2 /* ITS Collection Table Entry */ >> #define VGIC_DIST_SAVE_ITS_CT 3 /* ITS Collection Table */ >> #define VGIC_DIST_SAVE_VGIC3_LPI 4 /* VGIC3 LPI Pending Status */ >> #define VGIC_DIST_SAVE_VGIC3_PENDING_TABLE 5 /* VGIC3 Pending Table */ >> >> The drawback is the calls are limited to 64. If those 3 paths can't be running >> in parallel, we needn't the extension at all. > > It should all be completely sequential. KVM_DEV_ARM_ITS_SAVE_TABLES > runs in a context where everything is locked, and so is > VGIC_DIST_SAVE_VGIC3_PENDING_TABLE. >
Thanks for your confirm. Yeah, it's sequential because 'kvm->lock' is hold on KVM_DEV_ARM_ITS_SAVE_TABLES and VGIC_DIST_SAVE_VGIC3_PENDING_TABLE. So all good to have one shared switch. v2 will be posted pretty soon.
Thanks, Gavin
| |