|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v3 02/13] xen: harmonize return types of hypercall handlers
On 16.12.21 03:10, Stefano Stabellini wrote: On Wed, 15 Dec 2021, Juergen Gross wrote:On 14.12.21 18:36, Julien Grall wrote:Hi, On 08/12/2021 15:55, Juergen Gross wrote:Today most hypercall handlers have a return type of long, while the compat ones return an int. There are a few exceptions from that rule, however.So on Arm64, I don't think you can make use of the full 64-bit because a 32-bit domain would not be able to see the top 32-bit. In fact, this could potentially cause us some trouble (see [1]) in Xen. So it feels like the hypercalls should always return a 32-bit signed value on Arm.This would break hypercalls like XENMEM_maximum_ram_page which are able to return larger values, right?The other advantage is it would be clear that the top 32-bit are not usuable. Stefano, what do you think?Wouldn't it make more sense to check the return value to be a sign extended 32-bit value for 32-bit guests in do_trap_hypercall() instead? The question is what to return if this is not the case. -EDOM?I can see where Julien is coming from: we have been trying to keep the arm32 and arm64 ABIs identical since the beginning of the project. So, like Julien, my preference would be to always return 32-bit on ARM, both aarch32 and aarch64. It would make things simple. The case of XENMEM_maximum_ram_page is interesting but it is not a problem in reality because the max physical address size is only 40-bit for aarch32 guests, so 32-bit are always enough to return the highest page in memory for 32-bit guests. You are aware that this isn't the guest's max page, but the host's? And all of this is about a 32-bit guest on a 64-bit host. Juergen Attachment:
OpenPGP_0xB0DE9DD628BF132F.asc Attachment:
OpenPGP_signature
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |