|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v5 06/11] x86/hvm: processor trace interface in HVM
On 05.07.2020 21:11, Michał Leszczyński wrote:
> ----- 5 lip 2020 o 20:54, Michał Leszczyński michal.leszczynski@xxxxxxx
> napisał(a):
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -2199,6 +2199,25 @@ int domain_relinquish_resources(struct domain *d)
>> altp2m_vcpu_disable_ve(v);
>> }
>>
>> + for_each_vcpu ( d, v )
>> + {
>> + unsigned int i;
>> +
>> + if ( !v->vmtrace.pt_buf )
>> + continue;
>> +
>> + for ( i = 0; i < (v->domain->vmtrace_pt_size >> PAGE_SHIFT);
>> i++ )
>> + {
>> + struct page_info *pg = mfn_to_page(
>> + mfn_add(page_to_mfn(v->vmtrace.pt_buf), i));
>> + if ( (pg->count_info & PGC_count_mask) != 1 )
>> + return -EBUSY;
>> + }
>> +
>> + free_domheap_pages(v->vmtrace.pt_buf,
>> + get_order_from_bytes(v->domain->vmtrace_pt_size));
>
>
> While this works, I don't feel that this is a good solution with this loop
> returning -EBUSY here. I would like to kindly ask for suggestions regarding
> this topic.
I'm sorry to ask, but with the previously give suggestions to mirror
existing code, why do you still need to play with this function? You
really shouldn't have a need to, just like e.g. the ioreq server page
handling code didn't.
Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |