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

Re: [PATCH v3 00/14] x86/hvm: {svm,vmx} {c,h} cleanup


  • To: Xenia Ragiadakou <burzalodowa@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Fri, 24 Feb 2023 21:33:15 +0000
  • 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=d5Su5P1+VSQFCaK7xzz2jg71qjinsOyXOTwnal9daHU=; b=G/ebgzuYVeT7FOyhFPBm+BxHlYEYIUXmoKdKUdEctMbstQJa/9LLUZo2IkFI/Q8ONxG8rW/lP/vYOOU35np+iGVVBeyJWIQ37FD188J4IHwY7JmeJTMYY1nF1w3zR+4g2NRkEpiIrAZLdAyBQnqvkFOddhsxUl9DMSMtNM6PzapGyExo2llgGE5f1elrfYGcqU3jOrwmmdr2UgP5gYiZIl+6PWls1yjGeudAzDG6nmpgWHkfed8aVKg8UYMBhA87Co77i4hZ0FycD2UYlh0dObJ0xcbRerrl5GexJ1Y23GM4evLobKJ2hOFcud3ePzVgaCRJMzJiAsDuCrRpRI4HAA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mkr1EQx6w8p3g4RLfyn5hgqeI/SwQZtKQe3zxpVYgKaSO6uRldy/SQIgIqs482e0g7ijRrRnk4C2jgVIFxV5JZEnyBjiyK7Ide/cnKYDxEpckTtUHxR7bolkj3QSnb966gIsrUkcyU9UYgFGK+vQtJF/6chJY8bIXggg3X+cSP/6HC+4VxdxXPbd8InOCfMqgpMNHAvvRLE6zttTJRe/zseB+65lvncTJ3jhTWVp58K7dOCgldQ5NQC9pGBwGppIrhsnVIQzih8WTv885aKgUvPiVVjLKx4fTGJU94OU4eEoaNicAq3yq3tgwBxCUANFOn1C8ZvZJzKKFuMNyV9pLQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>
  • Delivery-date: Fri, 24 Feb 2023 21:33:40 +0000
  • Ironport-data: A9a23:/BspgK38hdfjaS7XKPbD5T1wkn2cJEfYwER7XKvMYLTBsI5bpz1Sz jcWWW+BPPzZYWSge4p0bI+0oRwH6J6Ey9JkHQRrpC1hF35El5HIVI+TRqvS04F+DeWYFR46s J9OAjXkBJppJpMJjk71atANlVEliefTAOK6ULWeUsxIbVcMYD87jh5+kPIOjIdtgNyoayuAo tq3qMDEULOf82cc3lk8tuTS93uDgNyo4GlD5gZkOagQ1LPjvyJ94Kw3dPnZw0TQGuG4LsbiL 87fwbew+H/u/htFIrtJRZ6iLyXm6paLVeS/oiI+t5qK23CulQRrukoPD9IOaF8/ttm8t4sZJ OOhF3CHYVxB0qXkwIzxWvTDes10FfUuFLTveRBTvSEPpqFvnrSFL/hGVSkL0YMkFulfAWNA3 rseeAo3VyukueH1kbLrRLVTiZF2RCXrFNt3VnBI6xj8VaxjbbWYBqLA6JlfwSs6gd1IEbDGf c0FZDFzbRPGJRpSJlMQD5F4l+Ct7pX9W2QA9BTJ+uxqvS6PkGSd05C0WDbRUvWMSd9YgQCzo WXe8n6iKhobKMae2XyO9XfEaurnzHygANpMROLQGvhC2VyVwGpNVz4qcgW9/N+njWCvGNxgN BlBksYphe1onKCxdfH3QgeqqXqDshkDUvJfFuQ77EeGza+8yxaUAC0IQyBMbPQitdQqXno62 1mRhdTrCDdz9rqPRhq19L2ZsDezMig9NnIZaGkPSg5ty8bniJE+iFTIVNkLOKyoiJvzEDL5w TGPpQA/gakeiYgA0KDT1VPKnTOq4ITIRwgd5wPLU2bj5QR8DLNJfKSt4FnfqPpFd4CQSwHbu GBew5TCqucTEZuKiSqBBv0XG62k7OqENzuahkNzG54m9HKm/HvLkZ1s3QyS7XxBaq4sEQIFq meK0e+NzPe/5EeXUJI=
  • Ironport-hdrordr: A9a23:j+heI6DI4e9FCXPlHelc55DYdb4zR+YMi2TDt3oddfU1SL3+qy nKpp4mPHDP5wr5NEtPpTnEAtjifZq+z+8Q3WByB9eftWDd0QPFEGgh1/qB/9SJIUbDH4VmpM JdmsZFaeEZDTJB/LrHCAvTKade/DFQmprY+9s3zB1WPHBXg7kL1XYeNu4CeHcGPjWvA/ACZe Ohz/sCnRWMU1INYP+2A3EUNtKz2uEixPrdEGY77wdM0nj0sQ+V
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 24/02/2023 8:08 pm, Xenia Ragiadakou wrote:
>
> On 2/24/23 21:29, Andrew Cooper wrote:
>> On 24/02/2023 6:49 pm, Xenia Ragiadakou wrote:
>>> There are more detailed per-patch changesets.
>>>
>>> Xenia Ragiadakou (14):
>>>    x86/svm: move declarations used only by svm code from svm.h to
>>> private
>>>      header
>>>    x86/svm: make asid.h private
>>>    x86/svm: delete header asm/hvm/svm/intr.h
>>
>> Thankyou for this work.  I've acked and committed patches 1 and 3.
>>
>> Note that you had one hunk in patch 5 (whitespace correction in
>> svm_invlpga) that obviously should have been in patch 1, so I've
>> moved it.
>
> Thanks, I missed that  ...
>
>>
>> Looking at asid.h, I still can't bare to keep it even in that state, so
>> I've constructed an alternative which I'll email out in a moment.
>
> I 'm also in favor of less headers.

I've committed as far as the nestedhvm move.  At that point, I've sent
out a small patch to try and help decouple later changes.

But I think we want to change tact slightly at this point, so I'm not
going to do any further tweaking on commit.

Next, I think we want to rename asm/hvm/svm/svm.h to asm/hvm/svm.h,
updating the non-SVM include paths as we go.  Probably best to
chain-include the other svm/hvm/svm/*.h headers temporarily, so we've
only got one tree-wide cleanup of the external include paths.

Quick tangent - I will be making all of that cpu_has_svm_*
infrastructure disappear by moving it into the normal CPUID handling,
but I've not had sufficient time to finish that yet.

Next, hvm/svm/nestedsvm.h can merge straight into hvm/svm.h, and
disappear (after my decoupling patch has gone in).

After that, hvm/svm/vmcb.h can be cleanly split in half.  struct
svm_{domain,vcpu} can move sideways into hvm/svm.h (with a forward
declaration of vmcb_struct), as can the svm msr intercept declarations. 
Everything else can move to being a private vmcb.h

Finally your svmdebug.h can come at the end, pretty much in the same
shape it is now.  One thing to say is that right now, you've left enum
vmcb_sync_state public, but it's type is already decoupled by virtue of
struct svm_vcpu having a uint8_t field rather than an enum field.

And I think that cleanly gets rid of the entire asm/hvm/svm/* dir, which
is a great position to get to.


Beyond that, you will want to clean up the hvm msr intercept handling as
hvm_funcs, which I think will decouple the vpmu files from svm/vmx
specifically, but that will want to be a separate series.

How does this sound?

Thanks,

~Andrew



 


Rackspace

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