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

hypercalls with 64-bit results

  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 16 Jun 2021 18:04:02 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=lo7dWu124mDXCjniLtxKg5FLgByRQJ2w3dohpW4Ret8=; b=YG2LMNID6lR7wG3sIx9ii4y/uJycwWUkdoqWcDf0pzTK9OukqiHUMh8ikN5UFLfvoI2HMz/LdXgkvdCuoMvBttcceja7snWcLfzCMj+6CQBTOAR421oE9/okZQUJLSqsm6S/b91a1pMWBYiELZt3MKIMx4cXwYJnj0uVKSOrfaDg4sHToUf0X9+XULWo/8bl5YVzwQVSnsQ3EHJFNDpb6Uf/OJ/Dhg6FTET/68T3I1IcY4O3ig7ASApWQgWV9+i/zjuoy3SkyerV9p4+xtrztAJihhSsiF/+9MDmoEpKqjU/1+2qbDlyGO65DA3cQhqQ++3wDQHkZhe4DL5cyCL8LQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YpGySNvHjPKNWPuBFQWVtTCJTyfpGR8lZC+hqZq0at2dyVUoYWbBP0FHrDTpvDRTQefvzQxZ7+fu96g3jteVRCAS05CBkPyax8tmo5sEPaVa2SpTM/dDS4cEa5pDtjfT9nJDq3p51JyA8ZT6AIyHL/xaFGliblGQj+Llzt2JOT7Zy+Hm4mwRZMWC9J69FHnn/bIErhIAgYq6wRaP+v1viABy+Lq34b9APMyyMDI/szt3D7rO++srxTqd2DqnNMuw1ISs782YY7Yz91OcrXr9J81hiDSGGqCk0kk8mywY3WMihAUNmNYNv6P9FSqNFLeHuKnx4si6uGI/pZ3AtPVMqA==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 16 Jun 2021 16:04:19 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>


several years back do_memory_op() in libxc was changed to have "long"
return type. This is because some of the sub-ops return potentially
large values as the hypercall return value (i.e. not in an argument
structure field). This change, however, didn't have the intended
effect from all I can tell, which apparently manifests in the present
two remaining ovmf failures in the staging osstest flights. Anthony
tells me that ovmf as of not very long ago puts the shared info page
at a really high address, thus making the p2m of the guest very large.
Its size gets returned by XENMEM_maximum_gpfn, as function return

Since hypercalls from the tool stack are based on ioctl(), and since
ioctl() has a return type of "int", I'm afraid there's no way we can
deal with this by adjusting function return types in the libraries.
Instead we appear to need either a new privcmd ioctl or new XENMEM_*
subops (for those cases where potentially large values get returned).

Until we manage to deal with this I wonder whether we should suggest
to the ovmf folks to undo that change. I'm anyway not really
convinced this aggressive enlarging of the p2m is a good idea. There
are a number of cases in the hypervisor where we try to reduce GFN
ranges based on this upper bound, and there in particular is a loop
in mem-sharing code going all the way up to that limit. EPT P2M
dumping also has such a loop.




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