[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 2/2] domain: expose newly introduced hypercalls as XENFEAT
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Mon, 16 Oct 2023 16:39:53 +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=OsGCoAkeC7OmbU/HP9RcjDahdCKqVEdbh5i52RncR5s=; b=BdZwl9uR1opwcH2t8cRyIN1hph9TqnaW0MOzekp6Xe9dp+Fx3zK1xSjHokW+eEcQUYKWtaZJmzDue9V5W5iW5Qv2MPlKVIJBmHRK+e2Thzjh5kSe1DzjOSxwme2k0x29yDtY9QFfC4xkvMJv1HxsJ2IWFUxp81uKq7mWhZyTDcPCpgIiOuGfCvqWAAgSdN7EEkCQfYq4qgk0QjPKPZI3Cm5nDO+In+WB4lp2D4y77gWiEEoR2XDSJZDVQ5En6Vq0z/71GO6/e0zVJvPb91QjhKDPcx59SyF6vH428UYpVPSVNyCYXlT7TB13MZL4tRK/jas/DKUHPIbaBduz+KnheA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B7Sb3Ce9Zyg7WdaLfqVWE1OO97KV5HIaVzMjUaNnBPEzxRmchD6fVa2SI1nZzG/lYKv/SvM0vw4yL05pJvALs56CyXnjk5BgGFf42oOItR8Y70ULlmWvsfrBfe5a0j6YfJHJ52JN3qSeOv+OcdMQTFM9uX24hqXcctuP/0r9vr1niCB08bG3r1lCG1T9m3oAAudqBGIJqpbFLq3UtOXUx2Rb9sWSTWZJ8ilcLK6fDRro+DznfAS6S+xiEAubsYwHlNeslJQTlIuCZW7oMnK1CqAls9vFxCd5/ekq4ni5CwSCKStwaimVNTZGLwkOwuQqOweTJQIA3JbAl9czBErc6Q==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Henry Wang <Henry.Wang@xxxxxxx>, Community Manager <community.manager@xxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Mon, 16 Oct 2023 14:40:19 +0000
- Ironport-data: A9a23:aJfqDa6m9cYCvwjqvNYqywxRtLzGchMFZxGqfqrLsTDasY5as4F+v mNNX2yBPquLY2Kkftgiaom09R8OvZbcx9Y1GQprqCFnHi5G8cbLO4+Ufxz6V8+wwm8vb2o8t plDNYOQRCwQZiWBzvt4GuG59RGQ7YnRG/ykTraCY3gtLeNdYH9JoQp5nOIkiZJfj9G8Agec0 fv/uMSaM1K+s9JOGjt8B5mr9lU355wehBtC5gZlPKgS4geH/5UoJMl3yZ+ZfiOQrrZ8RoZWd 86bpJml82XQ+QsaC9/Nut4XpWVTH9Y+lSDX4pZnc/DKbipq/0Te4Y5iXBYoUm9Fii3hojxE4 I4lWapc6+seFvakdOw1C3G0GszlVEFM0OevzXOX6aR/w6BaGpdFLjoH4EweZOUlFuhL7W5m2 +VDEhEJKRS/oqHmyfWiSNN+muonM5y+VG8fkikIITDxK98DGMmGaYOaoNhS0XE3m9xEGuvYa 4wBcz1zYR/cYhpJfFAKFJY5m+TujX76G9FagAvN+exrvC6OnEoojumF3Nn9I7RmQe1PmUmVv CTe9nnRCRAGLt2PjzGC9xpAg8eWx36kAdtMROXQGvhCvkGv+TEyAVoqUEqBn8HjmnGSVOhFE hlBksYphe1onKCxdfH/VRClpH+PvjYHRsFdVeY97Wml6qfS+RffOWECQRZIctlgv8gzLRQh0 VqMgtXoGS0ptbSTQH2Q7J+EoDWqIy8XIGQeIygeQmMt4cTnoYw1pgLCSJBkCqHdpsbuBTj6z jSOrS4/r7Yel8gG0+O851+vqy2ojojESEgy/Aq/dnKo6EZ1aZCoY6Ss6EPH9rBQIYCBVF6Ds XMY3c+E44gz4YqlkSWMRKAHGuGv7vPcaTnE2wcxTt8m6iin/GOlccZI+jZiKUx1M8ECPzj0f EvUvgAX75hWVJe3UZJKj0uKI5xC5cDd+R7NDJg4svImjkBNSTK6
- Ironport-hdrordr: A9a23:7qgjeaukNlej0fvAqzoLqV6w7skDstV00zEX/kB9WHVpm6yj+v xG/c5rsCMc7Qx6ZJhOo7+90cW7L080lqQFg7X5X43DYOCOggLBQL2KhbGI/9SKIVycygcy78 Zdm6gVMqyLMbB55/yKnTVRxbwbsaW6GKPDv5ag8590JzsaD52Jd21Ce36m+ksdfnggObMJUK Cyy+BgvDSadXEefq2AdwI4t7iqnaysqHr+CyR2fiIa1A==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Mon, Oct 16, 2023 at 04:04:34PM +0200, Jan Beulich wrote:
> On 16.10.2023 16:01, Roger Pau Monné wrote:
> > On Mon, Oct 16, 2023 at 03:58:22PM +0200, Jan Beulich wrote:
> >> On 16.10.2023 15:00, Roger Pau Monné wrote:
> >>> On Mon, Oct 16, 2023 at 02:35:44PM +0200, Jan Beulich wrote:
> >>>> On 06.10.2023 15:00, Roger Pau Monne wrote:
> >>>>> --- a/xen/common/domain.c
> >>>>> +++ b/xen/common/domain.c
> >>>>> @@ -1998,6 +1998,10 @@ long common_vcpu_op(int cmd, struct vcpu *v,
> >>>>> XEN_GUEST_HANDLE_PARAM(void) arg)
> >>>>> {
> >>>>> struct vcpu_register_runstate_memory_area area;
> >>>>>
> >>>>> + rc = -ENOSYS;
> >>>>> + if ( 0 /* TODO: Dom's XENFEAT_runstate_phys_area setting */ )
> >>>>> + break;
> >>>>> +
> >>>>> rc = -EFAULT;
> >>>>> if ( copy_from_guest(&area.addr.p, arg, 1) )
> >>>>> break;
> >>>>
> >>>> ENOSYS is not correct here. EPERM, EACCES, or EOPNOTSUPP would all be
> >>>> more
> >>>> correct.
> >>>
> >>> I don't think so, common_vcpu_op() default case does return -ENOSYS,
> >>> and the point of this path is to mimic the behavior of an hypervisor
> >>> that doesn't have the hypercalls implemented, hence -ENOSYS is the
> >>> correct behavior.
> >>
> >> Besides that other ENOSYS being wrong too, I question such "mimic-ing".
> >> Imo error codes should be the best representation of the real reason,
> >> not be arbitrarily "made up".
> >
> > The point is for the guest to not take any action that it won't take
> > on an hypervisor that doesn't have the hypercalls implemented, and the
> > only way to be sure about that is to return the same exact error code.
>
> I don't follow this kind of reasoning. Why would a guest, whose code to
> use the new sub-functions has to be newly written, key its decision to
> the specific error code it gets, when at the same time you expose
> feature bits that it can use to decide whether to invoke the hypercall
> in the first place.
Because we don't control all possible guest implementations out there.
AIUI the point of introducing a way to disable the newly added
hypercalls is to make the interface between a Xen previous to the
introduction of the hypercalls vs a Xen that has the hypercalls
disabled equal, and that requires returning the same error code IMO,
or else interfaces are not equal.
Thanks, Roger.
|
