On 20.10.20 10:57, Paul Durrant wrote:
Hi Paul
Sorry for the late response.
-----Original Message-----
From: Oleksandr Tyshchenko <[email protected]>
Sent: 15 October 2020 17:44
To: [email protected]
Cc: Oleksandr Tyshchenko <[email protected]>; Andrew Cooper
<[email protected]>;
George Dunlap <[email protected]>; Ian Jackson <[email protected]>;
Jan Beulich
<[email protected]>; Julien Grall <[email protected]>; Stefano Stabellini
<[email protected]>; Wei
Liu <[email protected]>; Roger Pau Monné <[email protected]>; Paul Durrant
<[email protected]>; Tim Deegan
<[email protected]>; Julien Grall <[email protected]>
Subject: [PATCH V2 02/23] xen/ioreq: Make x86's IOREQ feature common
From: Oleksandr Tyshchenko <[email protected]>
As a lot of x86 code can be re-used on Arm later on, this patch
moves previously prepared x86/hvm/ioreq.c to the common code.
The common IOREQ feature is supposed to be built with IOREQ_SERVER
option enabled, which is selected for x86's config HVM for now.
In order to avoid having a gigantic patch here, the subsequent
patches will update remaining bits in the common code step by step:
- Make IOREQ related structs/materials common
- Drop the "hvm" prefixes and infixes
FWIW you could tackle the naming changes in patch #1.
Unfortunately, there are a lot of places that need touching (in order to
replace/drop hvm prefixes), so I decided to keep that in a separate patch.
From the review comments on previous series I got that renaming could
be done before or after the move, but within
a single series, so I chose the latter.
The 'legacy' mechanism of mapping magic pages for ioreq servers should remain
x86 specific I think that aspect of the code needs to remain behind and not get
moved into common code. You could do that in arch specific calls in
hvm_ioreq_server_enable/disable() and hvm_get_ioreq_server_info().
Well, if legacy mechanism is not going to be used for other arch and
should remain x86 specific, I will try to investigate what should be
left in x86 code and rework the series.
As a side note, I am afraid, we won't get a 100% code movement (which I
managed to achieve here) for the next version of this patch as we need
arch/x86/hvm/ioreq.c.
--
Regards,
Oleksandr Tyshchenko
