Re: [PATCH v2 04/26] xen: consolidate CONFIG_VM_EVENT

[Jan Beulich <jbeulich@xxxxxxxx>]

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