On 14.09.2025 01:31, Tamas K Lengyel wrote:
>>> @@ -99,10 +98,40 @@ long p2m_set_mem_access_multi(struct domain *d,
>>> int p2m_get_mem_access(struct domain *d, gfn_t gfn, xenmem_access_t
>>> *access,
>>> unsigned int altp2m_idx);
>>>
>>> -#ifdef CONFIG_VM_EVENT
>>> int mem_access_memop(unsigned long cmd,
>>> XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg);
>>> #else
>>> +static inline bool xenmem_access_to_p2m_access(const struct p2m_domain
>>> *p2m,
>>> + xenmem_access_t xaccess,
>>> + p2m_access_t *paccess)
>>> +{
>>> + return false;
>>> +}
>>
>> So this is needed when VM_EVENT=n and ALTP2M=y. Tamas, is this a
>> configuration
>> which makes sense?
>
> Yes, altp2m should be functional without vm_event being enabled. There
> could very well be in-guest only use of altp2m via #VE. This function
> is used in p2m_init_next_altp2m which means it being stubbed out like
> this when vm_event is disabled breaks altp2m.
Oh, indeed - the stub still needs to handle XENMEM_access_default. Of course
with MEM_ACCESS=n it's not quite clear to me what p2m->default_access ought
to be; imo in principle that field ought to also go away in that case
(becoming hard-coded p2m_access_rwx). While doing that will be a larger
patch, perhaps using the hard-coded value here should be done right away.
Once the code correctly handles MEM_ACCESS=n as an implication from
VM_EVENT=n, it's also questionable whether MEM_ACCESS_ALWAYS_ON should be
retained.
Jan
