[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 01/11] x86/hvm: drop vcpu parameter from vlapic EOI callbacks
- To: Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>
- From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Date: Wed, 31 Mar 2021 17:24:24 +0100
- 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-SenderADCheck; bh=CTuz3+j7FuRJ6D1vrBmy6H7dyKLgapmZ4kimdqWiNIQ=; b=GURflj4+3hrTSJzWGb+fXXRf1DyUrl7zeL2gAmZW3wRPW+WTeeFVFmqMjgs3QvKXuTUhPUqeGWbvDsJ8bU3FCxhCXLzORlBVtAogt103r4OL1QIGvUU6xGuMylHU1BWZ6gqSSA6JHttqSHEgTBZ7fr95Gj24EfzJP0AAgI+Vixeht04Vkn/d48oJks4z6Gyirx5QJpWuQ/HNRYhs8rpouXtdLRIdcHrIrHBuTF2m208HhDAjks3JywEI8Q4VoK9xzNgNQ1i+UyWs/nqGJyHOMkH439h1/dlw8hBdhy9A+dTRquUiTCAxdQMpc+r623IMvWTBWTOGqd8zmsfq5/NfvA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oIT93A/N7xpC0p9RE3BnLjSUmN0o4QjwFsFTU7cB643180awax3nMZupFgbwqaoC4yaPlfomVVicICEg4t9NLh+G5lVNMjtPZM4favbPWPmGKUB0b93zy3B+OMez4Yc87McIcPuaTGtm4bHW3x/+HAUWSjCI4mjTg6Eimq8yd8ReK+wDo7+ZCA2Dg4LBXBcn61KowYChwAHYXWPb6HdXcBQu64FQbIPWR0rRUHd5tEODBDMY2s9TK1rB/jX71KOC3PngZ5QJCkADkt7fGBZMZwUzle928t8DgHOdrDhpobAMQLnlHl1lCVw1QJCwlDv8k0F/Yc81srLvMsOMYkdOBw==
- Authentication-results: esa2.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
- Cc: Wei Liu <wl@xxxxxxx>, Paul Durrant <paul@xxxxxxx>, Paul Durrant <pdurrant@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Wed, 31 Mar 2021 16:24:41 +0000
- Ironport-hdrordr: A9a23:XD+ec6+Gh5vuKsKP1ftuk+F3cL1zdoIgy1knxilNYDRvWIixi9 2ukPMH1RX9lTYWXzUalcqdPbSbKEmzybdc2qNUGbu5RgHptC+TLI9k5Zb/2DGIIULD38Zn/+ Nbf6B6YeedMXFTkdv67A6kE9wp3dmA9+SSif3Dymp2JDsLV4hLxW5Ce2KmO2dxQxRLAod8MZ Ka6NZOqTbIQwVoUu2QAH4ZU+/f4+DRnJX9bhIcQzIh4g+CjTSngYSKbCSw9BEYTj9J3PMe4X HI+jaJmpmLntOa7lvn12HV54lLg9eJ8Lp+LeGFl8R9EESWti+Gf4JkMofy2gwdgObq01oylc mJnhFIBbUP11r0XkWY5STgwBPh1jFG0Q6R9Xa9jWH4qcL0ABIWYvAx/b5xSRfS50o+sNwU6s sitAj1xvknb2K1oA3H69fFTB1snEavyEBS9tI7tHBDTZAYLIZYsI13xjInLL47ACn45Io7ed Medf302fA+SyL+U1nkpGV1hPSjUnMvdy32OHQqi4i+1jhbm21B1E0IxMATtWdozuNMd7B0o8 vDKahmj7dIU4s/ar98Hv4IRY+NBnXKWg+kChPdHX3XUIU8f17doZ/+57s4oMmsZZwz1ZM33L DMSklRu2Iec1/nYPf+naFjw1ToeiGQTD7twsZR69xSobvnXofmNiWFVRQHj9agi+93OLyYZ9 +DfLZtR9PzJ2rnHohEmyfkXYNJFHUYWMoJ/v4mRlO1pN7RIIGCjJ2ZTN/jYJ7WVRo0UGL2BX UOGBLpIt9b00ytUnjkxDfLXXfAfVH+4IJQHKDW8/N78vlICqR89iwuzXip7MCCLjNP9oYsel FlHb/hmqSn4Um6lFy4qFlBC154NAJ48b/gW3RFqUshKEXva4sOvN2ZZCR31HuDLRlvctPOHG dk1hJK0JPyC6bV6TEpCtqhPG7fpWAUvmi2Q5AVnbDGwsv5ZJUiDNIDVLZqHQvGUzx58Dwa6F trWUshfAvyBznugaKqgNg/H+fEbeRxhw+tPIpzsnLQtUKVoOk1XXsFVzuSUcqa6DxeAgZ8tx lUyesykbCAkTGgJS8Um+IjKmBBb2yRHfZ7FgifXZ5VnbrqYQl0am+PiVWh+kgOU1uv039Xqn 3qLCWSd/2OJlZGoHhX3pzn905OenyHc1h9bW17toNBBX3L00wDpNOjV+6W6S+8e1ECyuYSPH X+bTweLhhH6vq32BSW8QzyWEkO99ELBKjwHb4je7bc1jeRM4WOj7gBBOIR1o1iLsrSvugCVv +/dweZICjjMf4g3xWYqx8eSXFJgUhhtcmt9Azu7WC+0nJ6POHbJ05+QaoHZ/6b9GrpSp+zod 1EpONwmdH1FGr/atSLk/6KKxFCLw7eum6wQaUDr4tOsac7qbt0GN36XFLzpQd69SR7CP2xsk UUBJlfyvTmHKREesQJYSJX/lYzjr20XQEWmz2zJtV7RE0nin/QAsiA7LXJo4c+G0HpnnqGBX Cvtwlmu8rfVySN1bQmG7s9DGRfZk878mlj9oq5BsTtITTvU+FI51yhNHChNJdbVaieAL0Vxy wKr+2grquydyDi3hrXsiY+CqVS83y/Scf3JA6XA+ZH/5ibPluL65Har/KbvXPSSTGhbV4fip AAXUsMbt5bgj1ntbYJ6EGJO+fKi3NgtUBf7zFhnkPs3YbjwF6zJzA2DSTpxrNMXTdSNXCUi9 /i6ubw7gWn3AR4
- Ironport-sdr: 4ZoXZWU0qY0op7T41FSkv1zsS2vN7bDe34bboys6V7v/U4qC6b/4ISKWmNydkwaSZPvEf9fU12 ybVZrEwK9dWprz7lk7S+KJTuAYQTLLqFbYUBqFO16ukizc/h6GxX3VNd0gAzqGCLBGwsNLmWZy zFVkb7kqZ0EUtfSCz7o86jQJ0KAoHv9khuV8rUkuHZ+I6ngQIJkbOC+9nzxyvfgsmTxSFjIGFE L85b01q+ihFaRgJhdKOqzmGskq9ND0oKycank9J4II2ZbyE2fct2lLdhuIUH1HrwwIZIZSu38D MZo=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 31/03/2021 17:02, Jan Beulich wrote:
> On 31.03.2021 12:32, Roger Pau Monne wrote:
>> EOIs are always executed in guest vCPU context, so there's no reason to
>> pass a vCPU parameter around as can be fetched from current.
>>
>> While there make the vector parameter of both callbacks unsigned int.
>>
>> No functional change intended.
>>
>> Suggested-by: Paul Durrant <pdurrant@xxxxxxxxxx>
>> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>> Reviewed-by: Paul Durrant <paul@xxxxxxx>
>> ---
>> Changes since v1:
>> - New in this version.
> I'm afraid the situation with viridian_synic_wrmsr() hasn't changed
> since v2, and hence my previous comment still applies.
Only just spotted that line of reasoning.
Longterm, I do want to remove all the Viridian special cases, and handle
all of the state via architectural mechanisms (cpu policy for static
settings, and the existing MSR records for dynamic content).
A consequence of this cleanup is that guest_{rd,wr}msr() will be
eventually be used to save/restore dynamic state in the migrate stream,
which is why I've been engineering guest_{rd,wr}msr() to work for MSRs
in "current || !scheduled" context.
As such, it is important to retain a vcpu pointer because it will not be
current on the save/restore hypercalls, which execute in control domain
context.
How much is keeping the vcpu pointer going to interfere with this
series? My expectation is that this patch would need reverting to
continue the cleanup plans.
~Andrew
|
