[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2 03/17] xen/riscv: introduce guest domain's VMID allocation and manegement
On 6/24/25 4:01 PM, Jan Beulich wrote:
+ sbi_remote_hfence_gvma_vmid(d->dirty_cpumask, 0, 0, p2m->vmid);You're creating d; it cannot possibly have run on any CPU yet. IOW d->dirty_cpumask will be reliably empty here. I think it would be hard to avoid issuing the flush to all CPUs here in this scheme.I didn't double check, but I was sure that in case d->dirty_cpumask is empty then rfence for all CPUs will be send. But I was wrong about that. What about just update a code of sbi_rfence_v02()?I don't know, but dealing with the issue there feels wrong. However, before deciding where to do something, it needs to be clear what you actually want to achieve. To me at least, that's not clear at all.I want to achieve the following behavior: if a mask is empty (specifically, in our case|d->dirty_cpumask|), then perform the flush on all CPUs.That's still too far into the "how". The "why" here is still unclear: Why do you need any flushing here at all? (With the scheme you now mean to implement I expect it'll become yet more clear that no flush is needed during domain construction.) For the same reason x86 has flush: /* If there are no free ASIDs, need to go to a new generation */ if ( unlikely(data->next_asid > data->max_asid) ) { hvm_asid_flush_core(); But hvm_asid_flush_core() isn't doing a "real" flush what I missed to check on the first look at hvm_asid_handle_vmenter(). So I assume then a "real" flush will be called somewhere before entry to guest context. I think now it is more or less clear. Anyway, what then do for the cases if it is needed to have ASID which isn't expected to be changed? With this cycling approach after a new generation will be needed, all ASIDs could/will be changed. It isn't a case for RISC-V (at least, at the moment) but AFAIK it is an issue for AMD SEV. ~ Oleksii
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |