[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 0/8] x86emul: a few small steps towards disintegration
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Wed, 29 Mar 2023 16:17:16 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dX3AXwuNoNFFVSVWPI9acrafKEbTr9scnUpdApMnXrw=; b=KlB4JYu/W0NH+DdnOn+ImJni30WZQKQwK9/JADfshur084wqjWO/gINvPaISV+52maFNhGXqkUgDcPNBPj3qlr7QMXM8wfcIekgv8RMSR1/j95hQ4v2xR7Wux66lLlPn3+KCqrwp0aK1FYiJmTmkS7uxkvsm8ZadQARgosxWkq/L5fBs/yeU1qsJPlWQw3DImHfH/Q86832+CzjSkagqclZWnkn/R3pygE20jO2hrzLf0C+NvSYsOmI4RWDvjGWI69WELTNKr8xxYgEdm9/tm1izXH5O5Che4nxJxzkWW3uIePXuq/+qKEK/ml8ECXPcKjn2KukmhrsaRKPo6gGFCg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XoMHBjiU6jDIuL6e7soRt/Cic0aVK0oWIVuqgeYpH/xDxfOaylXB4PrtFtWyZhTpARacF8PtyYzZ4BJeZPWk7pvrTLX/50EDbbD7fIxRvBoOZrcO+D2F4DT1ZRsR2FNXa4ZWIH2DoiE57g6O4BfoBQHqAwR6h/lmB8TbHZOkGsrOuUwU/cWMa553X93+cdyp2t4zellOwXVRF8T691NQ4wC5gVblfJW3GnRk2YIjD+KVMRRS2n6jMIlFUgwBhXQYdO5tmLiGcbwBcky6eMT4FrI0dbIAhxQhr1FR1VELS3XQ+Xp8+crJDmKyiomy1TtFvnEtJh+T55v+pA6Vw2Zfwg==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Wed, 29 Mar 2023 14:17:34 +0000
- Ironport-data: A9a23:o2mtrK87ZZ9NJYi0G5CzDrUDp3+TJUtcMsCJ2f8bNWPcYEJGY0x3x 2NOUWjQbPiIYDemftxzPNjk/UNSv8CHydZgQVRo/Hs8E34SpcT7XtnIdU2Y0wF+jCHgZBk+s 5hBMImowOQcFCK0SsKFa+C5xZVE/fjUAOG6UKicYXoZqTZMEE8JkQhkl/MynrlmiN24BxLlk d7pqojUNUTNNwRcawr40Ire7kI/1BjOkGlA5AdmPqoa5AW2e0Q9V/rzG4ngdxMUfaEMdgKKb 76r5K20+Grf4yAsBruN+losWhRXKlJ6FVHmZkt+A8BOsDAbzsAB+v9T2M4nQVVWk120c+VZk 72hg3ASpTABZcUgkMxFO/VR/roX0aduoNcrKlDn2SCfItGvn9IBDJyCAWlvVbD09NqbDkltr vJDKQI0SCvZxOWX2uy7ePVRlIcKeZyD0IM34hmMzBn/JNN/G9XmfP+P4tVVmjAtmspJAPDSI dIDbiZiZwjBZBsJPUoLDJU5n6GjgXyXnz9w8QrJ4/ZopTaNilAtuFTuGIO9ltiiX8Jak1zev mvb12/4HgsbJJqUzj/tHneE37eVzXKjCdxOfFG+3u9qo2KC/2sKMiQ5SkOx5uKBm0ecB80Kf iT4/QJr98De7neDTNPwQhm5q36spQMHVpxbFOhSwBGAzO/Y7hiUAkAATyVdc5o2uckuXzso2 1SV2dTzClRHr7m9WX+bsLCOoluP1TM9KGYDYWoBUlED6ty6+oUr1EqTEpBkDbK/icDzFXfo2 TeWoSMihrIVy8kWy6G8+lOBiDWpznTUcjMICszsdjrNxmtEiESNPeRENXCzAS58Ebuk
- Ironport-hdrordr: A9a23:7cRgfaHeAP3LqWwrpLqE/8eALOsnbusQ8zAXPiFKOH9om6mj/K qTdZsgpH3JYUkqKRQdcLy7VZVoIkm9yXcW2+cs1N6ZNWHbUQ2TQL2KhrGC/9SPIULDH+dmpM NdT5Q=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Tue, Mar 28, 2023 at 04:48:10PM +0200, Jan Beulich wrote:
> On 28.03.2023 16:19, Roger Pau Monné wrote:
> > On Wed, Jun 15, 2022 at 11:57:54AM +0200, Jan Beulich wrote:
> >> ... of the huge monolithic source file. The series is largely code
> >> movement and hence has the intention of not incurring any functional
> >> change.
> >
> > I take the intention is to make code simpler and easier to follow by
> > splitting it up into smaller files?
>
> Well, I can't say yes or no to "simpler" or "easier to follow", but
> splitting is the goal, in the hope that these may end up as a side
> effects. There's always the risk that scattering things around may
> also make things less obvious. My main motivation, however, is the
> observation that this huge source file alone consumes a fair part
> of (non-parallelizable) build time. To the degree that with older
> gcc building this one file takes ten (or so) times as long as the
I wouldn't really trade compiler speed for clarity in a piece of code
like the x86 emulator, which is already very complex.
Do you have some figures of the performance difference this series
makes when building the emulator?
A couple of notes from someone that's not familiar with the x86
emulator. It would be clearer if the split files where prefixed with
opcode_ for those that deal with emulation (blk.c, 0f01.c, ...) IMO,
so that you clearly see this is an opcode family that has been split
into a separate file, or maybe insn_{opcode,blk,fpu,...}?
I've noticed in some of the newly introduced files the original
copyright notice from Keir is lost, I assume that's on purpose because
none of the code was contributed by Kier in that file? (see 0f01.c vs
0fae.c for example).
Do we expect to be able to split other opcode handling into separate
files?
I wonder how tied together are the remaining cases, and whether we
will be able to split more of them into separate units?
Overall I don't think the disintegration makes the code harder, as the split
cases seems to be fully isolated, I do however wonder whether further splits
might not be so isolated?
Thanks, Roger.
|
