[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: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Mon, 27 Feb 2023 11:15:14 +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=DpYrF7KSDbPhTXNaRG0ucQqP6OoQ/tRzexX94YTas9I=; b=eSpQalusTYnEiJTdjndoz8+ZRCBR89/oRrCbNXJwWdCWS85jE5u33i1N+eANWseMwKzKx0U3xeNiDQyjU46zYOmOKB2TttFSQWJby28D8goz4m9ZjmRDRjWAWFq4I6DIOoJqEwIGdShomua7F6ptU4cXMVqaf3iPbPym3OEfjam3KBqIF7FnRInQ+stpMkeey3D5UiG0CLESb9Y0lnKEhTldKfpk/q/15rWYCE4/8VTCUPiADkOJ5Xg6J1DCIFJX+bQLPX/8tr2DQ8eFZY+HNlEoqtKJfK/L778qcBO7gzwuPTEuieRtuWPIgJ4cwyotkRWPQ+OotXAmyI1jFl0aBw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KNS7E4YU48t1apDzRCvXyhK+qmAx+c55+qfKBQqqux9PR8WpYuor9G5c8bNSdqNA5iIcbo7T3Ds1weWPGRlfojJDRv8Zkq9x3J1pVBJXihfERT8a+trNY6EN0iOvD9A1AsbPJkhglJ1vHJAU+rAa0m9jGBKBZIMUDQ9WaRXMpXOeJWsFwFfDrfkzWJ9bcsgFwQsO9YRsUeCL8NUZ906Tv5NpE3G7gZWVPFCYAU/Xm36Z6BwrEoRS8ZumExGsFxjW0iQOwPiLapv8lzPEFUGmABN/f38phIGGKG9sBhC+ezp5sPOad+mUJK+qz/WdQP9GIoYBGwlcR5vmRJKlfEJ1jQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Xenia Ragiadakou <burzalodowa@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 27 Feb 2023 11:15:45 +0000
  • Ironport-data: A9a23:lzju4amsmd8Ns2sbG7bxEbbo5gxoJ0RdPkR7XQ2eYbSJt1+Wr1Gzt xIWX2iBMvyKYzP0Kop1PoW/9kMO65DXxtVjSwBkqStkRCMWpZLJC+rCIxarNUt+DCFhoGFPt JxCN4aafKjYaleG+39B55C49SEUOZmgH+a6U6icfHgqH2eIcQ954Tp7gek1n4V0ttawBgKJq LvartbWfVSowFaYCEpNg064gE4p7auaVA8w5ARkPqgR5gCGzhH5MbpETU2PByqgKmVrNrbSq 9brlNmR4m7f9hExPdKp+p6TnpoiG+O60aCm0xK6aoD66vRwjnVaPpUTbZLwXXx/mTSR9+2d/ f0W3XCGpaXFCYWX8AgVe0Ew/yiTpsSq8pefSZS0mZT7I0Er7xIAahihZa07FdRwxwp5PY1B3 f8HJD5TMRq7vL+R44vkTMJmhOMlPNa+aevzulk4pd3YJdAPZMmaBonvu5pf1jp2gd1SF/HDY cZfcSBocBnLfxxIPBEQFY46m+CrwHL4dlW0qnrM/fZxvzeVkVM3iea8WDbWUoXiqcF9t0CUv G/ZuU/+BQkXLoe3wjuZ6HO8wOTImEsXXapDRODnr6c20DV/wERLLxwIBGCfsMCk1G+ldcNlI E8x3wgH+P1aGEuDC4OVsweDiHyOswMYWtFQO/Yn8wzLwa3Riy6GAkAUQzgHb8Yp3Oc0WDps0 FaKltHoADVHsbuJRHbb/bCRxRuxNDYUKykeZCYCZQoD/9Tn5oo0i3rnRMt5AqexidHyBjjYz DWDrSx4jLIW5eYb2qP+8V3ZjjaEopnSUhVz9gjRRnii7A5yeMiifYPA1LTAxfNJLYLcQlzfu nEBwpGa9LpXU8DLkzGRSuIQGr3v/+yCLDDXnV9oGd8m6iip/HmgO4tX5VmSOXtUDyrNQhexC Ge7hO+bzMM70KeCBUOvX7+MNg==
  • Ironport-hdrordr: A9a23:Fd2v46379c5xjoafgdmmKAqjBIwkLtp133Aq2lEZdPU1SK2lfq WV954mPHDP+VUssR0b9OxoQZPwJ080lqQa3WByB9uftWDd0QOVxOsL1/qa/9SKIULDH4BmtZ uJf8BFeb/N5VUTt7ec3OGze+xQpeVu/8iT9IPj80s=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 27/02/2023 10:46 am, Jan Beulich wrote:
> On 24.02.2023 22:33, Andrew Cooper wrote:
>> 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).
> Why would you want to fold hvm/svm/nestedsvm.h into hvm/svm/svm.h?
> The latter doesn't use anything from the former, does it?

It's about what else uses them.

hvm_vcpu needs both svm_vcpu and nestedsvm, so both headers are always
included in tandem.

nestedsvm is literally just one struct now, and no subsystem ought to
have multiple headers when one will do.

The resulting "unified" svm.h will have very little in it, but
everything in it (including nestedsvm) should be there.

~Andrew



 


Rackspace

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