[Top][All Lists]

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

Re: [RFC PATCH 00/19] accel: Introduce AccelvCPUState opaque structure

From: Paolo Bonzini
Subject: Re: [RFC PATCH 00/19] accel: Introduce AccelvCPUState opaque structure
Date: Thu, 4 Mar 2021 16:40:45 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0

On 04/03/21 15:54, Philippe Mathieu-Daudé wrote:
On 3/4/21 2:56 PM, Paolo Bonzini wrote:
On 03/03/21 19:22, Philippe Mathieu-Daudé wrote:
Series is organized as:
- preliminary trivial cleanups
- introduce AccelvCPUState
- move WHPX fields (build-tested)
- move HAX fields (not tested)
- move KVM fields (build-tested)
- move HVF fields (not tested)

This approach prevents adding a TCG state.  Have you thought of using a
union instead, or even a void pointer?

Why does it prevent it? We can only have one accelerator per vCPU.

You're right, my misguided assumption was that there can only be one of WHPX/HAX/KVM/HVF. This is true for WHPX/KVM/HVF but HAX can live with any of the others.

However this means that AccelvCPUState would have multiple definitions. Did you check that gdb copes well with it? It's also forbidden by C++[1], so another thing to check would be LTO when using the C++ compiler for linking.


[1] https://en.wikipedia.org/wiki/One_Definition_Rule

TCG state has to be declared as another AccelvCPUState implementation.

Am I missing something?

Preventing building different accelerator-specific code in the same
unit file is on purpose.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]