Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Sunil Muthuswamy <sunilmut@microsoft.com>
To:     vkuznets <vkuznets@redhat.com>
CC:     "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        KY Srinivasan <kys@microsoft.com>,
        Haiyang Zhang <haiyangz@microsoft.com>,
        Stephen Hemminger <sthemmin@microsoft.com>,
        Wei Liu <liuwe@microsoft.com>,
        Michael Kelley <mikelley@microsoft.com>,
        Tianyu Lan <Tianyu.Lan@microsoft.com>
Subject: RE: [EXTERNAL] Re: [PATCH] x86/Hyper-V: Support for free page
 reporting
Thread-Topic: [EXTERNAL] Re: [PATCH] x86/Hyper-V: Support for free page
 reporting
Thread-Index: AdYuDAEiPLOc+vnoR1KnBaBInLPPAQAePL4AAHTd3lA=
Date:   Fri, 22 May 2020 17:02:41 +0000
Message-ID: <SN4PR2101MB0880E7DD03EF18680A2A88B8C0B40@SN4PR2101MB0880.namprd21.prod.outlook.com>
References: <SN4PR2101MB0880BB5C9780A854B2609992C0B90@SN4PR2101MB0880.namprd21.prod.outlook.com>
 <87ftbvt21h.fsf@vitty.brq.redhat.com>
In-Reply-To: <87ftbvt21h.fsf@vitty.brq.redhat.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 968cffb4-9013-44ec-f398-08d7fe71f0c1
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2020 17:02:41.8807
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8Q8aECZsjIvvc30Ae04m8VHsi2Yz4Z0+v+Z5DankJwpug3h0JUMljfpCG2YaxoBBodUNpKE0M+smhr4/Sqdz3RnWEdNg+n0iQLX9Fru1OU0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR2101MB0815
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> As the only usage of this function looks like
> if (!(hv_query_ext_cap() & HV_EXT_CAPABILITY_MEMORY_COLD_DISCARD_HINT))
>=20
> I would've change the interface to
>=20
> bool hv_query_ext_cap(u64 cap)
>=20
> so the usage would look like
>=20
> if (!(hv_query_ext_cap(HV_EXT_CAPABILITY_MEMORY_COLD_DISCARD_HINT))

Good idea. Will do in v2.

> >  	ms_hyperv.features =3D cpuid_eax(HYPERV_CPUID_FEATURES);
> > +	ms_hyperv.b_features =3D cpuid_ebx(HYPERV_CPUID_FEATURES);
> >  	ms_hyperv.misc_features =3D cpuid_edx(HYPERV_CPUID_FEATURES);
> >  	ms_hyperv.hints    =3D cpuid_eax(HYPERV_CPUID_ENLIGHTMENT_INFO);
> >
> > -	pr_info("Hyper-V: features 0x%x, hints 0x%x, misc 0x%x\n",
> > -		ms_hyperv.features, ms_hyperv.hints, ms_hyperv.misc_features);
> > +	pr_info("Hyper-V: features 0x%x, additional features: 0x%x, hints 0x%=
x, misc 0x%x\n",
> > +		ms_hyperv.features, ms_hyperv.b_features, ms_hyperv.hints,
> > +		ms_hyperv.misc_features);
>=20
> HYPERV_CPUID_FEATURES(0x40000003) EAX and EBX correspond to Partition
> Privilege Flags (TLFS), I'd suggest to take the opportunity and rename
> this to something like 'privilege flags low=3D0x%x high=3D0x%x'.
>=20
> Also, I don't quite like 'ms_hyperv.b_features' as I'll always have to
> look at what it's being assigned to understand what it holds. I'd even
> suggest to rename ms_hyperv.features to ms_hyperv.priv_low and
> ms_hyperv.b_features tp ms_hyperv.priv_high. Or maybe even better, pack
> them to the same 'u64 ms_hyperv.privileges'.

Good idea. I will make the change to rename this to 'priv_high' in v2. I li=
ke the idea of
combining 'features' & 'priv_high' to a u64, but that would be a cleanup ch=
ange and a
separate patch.

>=20
> Why is largepage always '1'?
I have responded to a similar question by Wei. Page reporting only supports=
 huge pages
and, so does the Hyper-V hypervisor. Let's follow this there.

>=20
> > +		range->page.additional_pages =3D (1ull << (order - 9)) - 1;
> > +		range->base_large_pfn =3D page_to_pfn(sg_page(sg)) >> 9;
>=20
> What is '9'? Could you please define it through PAGE_*/HPAGE_* macro?
Yes, I will define a macro. Essentially, it is to get a count of 2M pages.

> Nit: you could've just used
>=20
>         if (status & HV_HYPERCALL_RESULT_MASK !=3D HV_STATUS_SUCCESS) {
Sure, coming in v2.

>         ...
>=20
> > +		pr_err("Cold memory discard hypercall failed with status %llx\n",
> > +			status);
> > +		return -1;
>=20
> -EFAULT or something like it maybe?
Coming in v2.

> > +#ifdef CONFIG_PAGE_REPORTING
> > +	if (enable_page_reporting() < 0)
> > +		goto probe_error;
>=20
> Why? The hyperv-balloon driver itself may still be functional and you
> already set dm_device.pr_dev_info.report to NULL.
An error here would reflect an internal error and should not happen and
it was to make it easy to catch such errors, which are otherwise difficult
with just a print. But, the code should follow the general spirit. I will c=
hange
this in v2.

>=20
> >  enum HV_GENERIC_SET_FORMAT {
> >  	HV_GENERIC_SET_SPARSE_4K,
> >  	HV_GENERIC_SET_ALL,
> > @@ -371,6 +379,12 @@ union hv_gpa_page_range {
>=20
> There is a comment before this structure:
>=20
> /* HvFlushGuestPhysicalAddressList hypercall */
>=20
> which is now obsolete.

I will add that it also applies to 'HvExtCallMemoryHeatHint' hypercall also=
.

>=20
> >  		u64 largepage:1;
> >  		u64 basepfn:52;
> >  	} page;
> > +	struct {
> > +		u64:12;
>=20
> What is this unnamed member? Another 'reserved', 'pad'? Let's name it.

Sure, coming in v2.

>=20
> > +		u64 page_size:1;
> > +		u64 reserved:8;
> > +		u64 base_large_pfn:43;
> > +	};
>=20
> Please name this structure in the union.

Sure, coming in v2.

> > + */
> > +#define HV_MAX_GPA_PAGE_RANGES ((PAGE_SIZE - sizeof(u64)) / \
> > +				sizeof(union hv_gpa_page_range))
> > +
>=20
> The name HV_MAX_GPA_PAGE_RANGES sounds too generic and I think this is
> specific to the HvExtCallMemoryHeatHint hypercall as other hypercalls
> may have a different header length.
>=20

Good idea to rename. Coming in v2.

> > +/* HvExtCallMemoryHeatHint hypercall */
> > +#define HV_EXT_MEMORY_HEAT_HINT_TYPE_COLD_DISCARD	2
> > +struct hv_memory_hint {
> > +	u64 type:2;
> > +	u64 reserved:62;
> > +	union hv_gpa_page_range ranges[1];
>=20
> Why '[1]' and not '[]'? If it was '[]' you could've used 'sizeof(struct
> hv_memory_hint)' in HV_MAX_GPA_PAGE_RANGES macro definition instead of
> 'sizeof(u64)'.
>=20
Good idea, coming in v2.

- Sunil