[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 6/6] x86/hvm: reduce the need to flush caches in memory_type_changed()



On 19.05.2025 16:33, Roger Pau Monné wrote:
> On Mon, May 19, 2025 at 03:22:32PM +0200, Jan Beulich wrote:
>> On 19.05.2025 13:08, Roger Pau Monné wrote:
>>> On Sun, May 18, 2025 at 01:44:49PM +0200, Jan Beulich wrote:
>>>> On 16.05.2025 11:45, Roger Pau Monne wrote:
>>>>> Not sure whether this attempt to reduce cache flushing should get some
>>>>> mention in the CHANGELOG.
>>>>
>>>> Err on the side of adding an entry there?
>>>
>>> Oleksii would you be fine with me adding:
>>>
>>> diff --git a/CHANGELOG.md b/CHANGELOG.md
>>> index 1ea06524db20..fa971cd9e6ee 100644
>>> --- a/CHANGELOG.md
>>> +++ b/CHANGELOG.md
>>> @@ -11,6 +11,9 @@ The format is based on [Keep a 
>>> Changelog](https://keepachangelog.com/en/1.0.0/)
>>>     - For x86, GCC 5.1 and Binutils 2.25, or Clang/LLVM 11
>>>     - For ARM32 and ARM64, GCC 5.1 and Binutils 2.25
>>>   - Linux based device model stubdomains are now fully supported.
>>> + - On x86:
>>> +   - Restrict the cache flushing done in memory_type_changed() to improve
>>> +     performance.
>>
>> Maybe better to mention function names here, saying "after a memory type 
>> change
>> by a guest" instead?
> 
> It's not just "after a memory type change by a guest", since
> memory_type_changed() is also used for toolstack operations like
> io{mem,ports}_{permit,deny}_access(), that strictly speaking are not
> memory type changes,

Sure, I'm aware. But I didn't think it would matter that much here. Still ...

> neither are done by the guest itself.  I could
> reword to:
> 
>    - Restrict the cache flushing done as a result of guest physical
>      memory map manipulations and memory type changes.
> 
> Does that sound better?

... yes, let's go with this then.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.