From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751443AbdION1K (ORCPT ); Fri, 15 Sep 2017 09:27:10 -0400 Received: from mx2.suse.de ([195.135.220.15]:57028 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751207AbdION1J (ORCPT ); Fri, 15 Sep 2017 09:27:09 -0400 Subject: Re: [Xen-devel] [PATCH 4/4] xen: select grant interface version To: Jan Beulich Cc: Andrew Cooper , xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, linux-kernel@vger.kernel.org References: <20170908144849.2958-1-jgross@suse.com> <20170908144849.2958-5-jgross@suse.com> <7d34f929-b45d-c056-865d-94082312b0bc@suse.com> <17e66ddd-cd08-9749-a27b-ac81bf0d3c5d@suse.com> <59BBEFFC020000780017B8EF@suse.com> From: Juergen Gross Message-ID: <302b0b5f-34d2-07e8-ffd1-21b561daa6e2@suse.com> Date: Fri, 15 Sep 2017 15:27:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <59BBEFFC020000780017B8EF@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15/09/17 15:21, Jan Beulich wrote: >>>> On 15.09.17 at 15:00, wrote: >> So I've found the data I've searched in the hypervisor. The maximum >> frame number to expect can be calculated from max_page, mem_hotplug >> and the maximum physical address from cpuid node 0x80000008. If >> CONFIG_BIGMEM isn't defined in Xen it is 16TB max. >> >> The question is how to present this value to a guest. IMHO something >> like the maximum address width similar to cpuid node 0x80000008 >> would be fine. It could be above width for pv guests and the max. >> memory address of the guest for HVM guests (adding a cap for those >> wouldn't be the worst idea, I guess). >> >> What about a new subop of the xen_version hypercall? > > I don't see how that would be a good fit; instead, with the CPUID > similarity you mention, why not provide the information in one of > Xen's CPUID leaves? Otoh I wonder whether returning max_page > from XENMEM_maximum_ram_page is really a good idea, if later > on that value may increase, so perhaps that op should take > mem_hotplug into account. I think Andrew had concerns with the exact value being returned via XENMEM_maximum_ram_page. Using a Xen CPUID leaf returning just the number of address bits would be a better fit, I guess. Juergen