From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752296AbdKHM02 (ORCPT ); Wed, 8 Nov 2017 07:26:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46504 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751931AbdKHM00 (ORCPT ); Wed, 8 Nov 2017 07:26:26 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 91C89C049D4E Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=pbonzini@redhat.com Subject: Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest To: Juergen Gross , Jan Beulich Cc: len.brown@intel.com, x86@kernel.org, tglx@linutronix.de, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, mingo@redhat.com, rkrcmar@redhat.com, rjw@rjwysocki.net, pavel@ucw.cz, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, hpa@zytor.com References: <20171108090739.26491-1-jgross@suse.com> <20171108090739.26491-4-jgross@suse.com> <5A02F633020000780018D26A@suse.com> <256b90df-547e-3287-d13f-3ffb346b4bc2@redhat.com> <136bd3b8-5301-84c9-9bdf-6ebf781f9256@suse.com> From: Paolo Bonzini Message-ID: <823fbbfb-d9f7-3b6b-5941-239bf900d0cb@redhat.com> Date: Wed, 8 Nov 2017 13:26:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <136bd3b8-5301-84c9-9bdf-6ebf781f9256@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 08 Nov 2017 12:26:26 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/11/2017 13:24, Juergen Gross wrote: >> My understanding of Xen is very rusty at this point, but I think a >> "completely" legacy-free HVM domain will still have a PCI bus and the >> Xen platform device on that bus. >> >> A PVH domain just knows how to access the Xen PV features. > > A HVM domain does so, too. Today maybe only partially, but e.g. event > channels work in a HVM domain even without the Xen platform device. > Grant tables can be made working without the platform device, too, > and I'm already preparing a patch to do exactly that. What about assigned PCI devices? I think they are not PV pcifront for HVM. So the main difference in the end is the PCI bus. Paolo