Re: [PATCH v3 06/17] KVM: PPC: Book3S HV: XIVE: add controls for the EQ configuration

From: "Cédric Le Goater" <clg@kaod.org>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: linuxppc-dev@lists.ozlabs.org, Paul Mackerras <paulus@samba.org>,
	kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
Subject: Re: [PATCH v3 06/17] KVM: PPC: Book3S HV: XIVE: add controls for the EQ configuration
Date: Mon, 18 Mar 2019 15:38:55 +0100	[thread overview]
Message-ID: <f41e9305-5185-9a04-4de9-502d252a8231@kaod.org> (raw)
In-Reply-To: <8b3caeef-8750-b8db-d516-c722bc08c535@kaod.org>

[ ... ]

>>> +	page = gfn_to_page(kvm, gpa_to_gfn(kvm_eq.qpage));
>>> +	if (is_error_page(page)) {
>>> +		pr_warn("Couldn't get guest page for %llx!\n", kvm_eq.qpage);
>>> +		return -EINVAL;
>>> +	}
>>
>> Yeah.. for the case of a 4kiB page host (these days weird, but not
>> actually prohibited, AFAIK) you need to check that the qsize selected
>> actually fits within the page.
> 
> Ah yes. sure.
>  
>>> +	qaddr = page_to_virt(page) + (kvm_eq.qpage & ~PAGE_MASK);
>>> +
>>> +	/* Backup queue page guest address for migration */
>>
>> Hm.. KVM itself shouldn't generally need to know about migration.
>> IIUC these values won't change from what qemu set them to be, so it
>> should be able to store and migrate them without have to get them back
>> from the kernel.
> 
> Euh. You are completely right. I don't know why I kept those around. 

No. I do need these values in patch 9 "KVM: PPC: Book3S HV: XIVE: add 
a control to dirty the XIVE EQ pages" where the EQ pages are marked
dirty for migration:

+		/* Mark EQ page dirty for migration */
+		mark_page_dirty(vcpu->kvm, gpa_to_gfn(q->guest_qpage));

We could change the kvmppc_xive_native_vcpu_eq_sync() to work on a 
EQ basis and not on a device basis. In this case, we could pass the
EQ guest address again. That would change a bit the save sequence.

C.

>>> +	q->guest_qpage = kvm_eq.qpage;
>>> +	q->guest_qsize = kvm_eq.qsize;