From xen-devel-bounces@lists.xen.org Tue Jan 07 11:28:22 2014 Received: (at maildrop) by bugs.xenproject.org; 7 Jan 2014 11:28:22 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1W0Upa-0008HM-7D for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Tue, 07 Jan 2014 11:28:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1W0UkW-0006Xz-4U; Tue, 07 Jan 2014 11:23:08 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1W0UkR-0006Xr-Lo for xen-devel@lists.xenproject.org; Tue, 07 Jan 2014 11:23:05 +0000 Received: from [85.158.139.211:22136] by server-9.bemta-5.messagelabs.com id DC/38-15098-693EBC25; Tue, 07 Jan 2014 11:23:02 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1389093780!7057980!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23194 invoked from network); 7 Jan 2014 11:23:01 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 7 Jan 2014 11:23:01 -0000 X-IronPort-AV: E=Sophos;i="4.95,618,1384300800"; d="scan'208";a="88230669" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 07 Jan 2014 11:23:00 +0000 Received: from [10.80.2.80] (10.80.2.80) by FTLPEX01CL02.citrite.net (10.13.107.79) with Microsoft SMTP Server id 14.2.342.4; Tue, 7 Jan 2014 06:22:59 -0500 Message-ID: <1389093778.31766.131.camel@kazak.uk.xensource.com> From: Ian Campbell To: Konrad Rzeszutek Wilk Date: Tue, 7 Jan 2014 11:22:58 +0000 In-Reply-To: <20140106175713.GB28636@phenom.dumpdata.com> References: <20140106175713.GB28636@phenom.dumpdata.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.4.4-3 MIME-Version: 1.0 X-Originating-IP: [10.80.2.80] X-DLP: MIA1 Cc: xen-devel@lists.xenproject.org Subject: Re: [Xen-devel] xend vs xl with pci=['' are not owned by pciback or pcistub will still launch. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org create ^ thanks On Mon, 2014-01-06 at 12:57 -0500, Konrad Rzeszutek Wilk wrote: > In Xend, if I had a pci entry in the guest config and the > PCI device was not assigned to xen-pciback or pci-stub it > would refuse to launch the guest. > > Not so with 'xl'. It will complain but still launch: It looks like domcreate_attach_pci() is ignoring the result of libxl__device_pci_add(). It appears to have always done so. I suppose there is an argument that there are usecases where starting the domain at all even without the full set of devices is better than not starting it at all, but I think I agree that the default should be to fail if some devices are not available. Is this a blocker for you for 4.4 or can it wait for 4.5? > > -bash-4.1# cd drivers/pciback/ > -bash-4.1# ls > 0000:01:00.0 0000:03:08.1 0000:03:0a.0 0000:03:0b.1 irq_handlers new_slot remove_id uevent > 0000:01:00.1 0000:03:09.0 0000:03:0a.1 bind module permissive remove_slot unbind > 0000:03:08.0 0000:03:09.1 0000:03:0b.0 irq_handler_state new_id quirks slots > -bash-4.1# echo "0000:03:0b.0" > unbind > -bash-4.1# echo "0000:03:0b.1" > unbind > -bash-4.1# xl create /mnt/lab/security/security.cfg > Parsing config from /mnt/lab/security/security.cfg > libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:3:b.0 is not assignable > libxl: error: libxl_pci.c:1055:libxl__device_pci_add: PCI device 0:3:b.1 is not assignable > -bash-4.1# xl list > Name ID Mem VCPUs State Time(s) > Domain-0 0 2047 4 r----- 14.7 > security 1 1023 1 -b---- 8.0 > -bash-4.1# > -bash-4.1# cat /mnt/lab/security/security.cfg |grep -v \# > device_model_version="qemu-xen-traditional" > builder="hvm" > memory = 1024 > name = "security" > vcpus=1 > vif = [ 'mac=00:0F:4B:00:00:84,bridge=switch' ] > disk = [ 'phy:/dev/sda,xvda,w' ] > pci= ['0000:03:08.0', '000:03:08.1', '0000:03:09.0', '0000:03:09.1', '0000:03:0a.0', '0000:03:0a.1', '0000:03:0b.0', '0000:03:0b.1'] > vnc=1 > vnclisten='0.0.0.0' > vncunused=1 > serial="pty" > > > And naturally when shutting/destroying the guest it will say: > -bash-4.1# xl destroy 1 > libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed: No such device > libxl: error: libxl_pci.c:1265:do_pci_remove: xc_deassign_device failed: No such device > > (XEN) [2014-01-06 17:54:39] deassign 0000:03:0b.0 from dom1 failed (-19) > (XEN) [2014-01-06 17:54:39] deassign 0000:03:0b.1 from dom1 failed (-19) > > because it tries to de-allocate them even though they were not > part of the guest. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel