From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Issues with PCI-Passtrough (VT-d) in HVM with Xen 4.6 Date: Fri, 03 Jun 2016 08:20:52 -0600 Message-ID: <5751AE6402000078000F1A07@prv-mh.provo.novell.com> References: <57509021.1060506@datanoise.net> <57518B9202000078000F18C7@prv-mh.provo.novell.com> <5751A19502000078000F1982@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartA89EA354.2__=" Return-path: In-Reply-To: <5751A19502000078000F1982@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: juwalter@gmail.com Cc: Sylwester Sosnowski , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartA89EA354.2__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline >>> On 03.06.16 at 15:26, wrote: >>>> On 03.06.16 at 14:02, wrote: >> or is this just some method the overwrite all registers with=20 >> "ffffffff" first and then set the actual value? >>=20 >> [914572] xbk: 06:00.0: write request 4 bytes at 0x10 =3D ffffffff >> [914574] xbk: 06:00.0: read 4 bytes at 0x10 >> [914582] xbk: 06:00.0: read 4 bytes at 0x10 =3D f7a00000 >> [914591] xbk: 06:00.0: read 4 bytes at 0x10 >> [914599] xbk: 06:00.0: read 4 bytes at 0x10 =3D 10000 <---- = fail >=20 > That's an unexpected value, indeed (but seems to match up with > the source, so there's definitely something wrong here - this > presumably ought to be 0xffff0000, meaning the size of that > region is 64k). Mind trying out the attached patch? Jan --=__PartA89EA354.2__= Content-Type: text/plain; name="xen-pciback-BAR-lengths.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xen-pciback-BAR-lengths.patch" xen-pciback: return proper values during BAR sizing=0A=0AReads following = writes with all address bits set to 1 should return all=0Achangeable = address bits as one, not the BAR size (nor, as was the case=0Afor the = upper half of 64-bit BARs, the high half of the region's end=0Aaddress). = Presumably this didn't cause any problems so far because=0Aconsumers use = the value to calculate the size (usually via val & -val),=0Aand do nothing = else with it.=0A=0ABut also consider the exception here: Unimplemented = BARs should always=0Areturn all zeroes.=0A=0AAnd finally, the check for = whether to return the sizing address on read=0Afor the ROM BAR should = ignore all non-address bits, not just the ROM=0AEnable one.=0A=0ASigned-off= -by: Jan Beulich =0A=0A--- head.orig/drivers/xen/xen-pci= back/conf_space_header.c 2015-03-16 15:38:59.000000000 +0100=0A+++ = head/drivers/xen/xen-pciback/conf_space_header.c 2016-06-03 = 15:55:27.629520779 +0200=0A@@ -149,7 +149,7 @@ static int rom_write(struct = pci_dev *dev=0A /* A write to obtain the length must happen as a = 32-bit write.=0A * This does not (yet) support writing individual = bytes=0A */=0A- if (value =3D=3D ~PCI_ROM_ADDRESS_ENABLE)=0A+ if = ((value | ~PCI_ROM_ADDRESS_MASK) =3D=3D ~0)=0A bar->which =3D = 1;=0A else {=0A u32 tmpval;=0A@@ -229,38 +229,42 @@ static = inline void read_dev_bar(struct p=0A (PCI_BASE_ADDRES= S_SPACE_MEMORY |=0A PCI_BASE_ADDRESS_MEM_TYPE_6= 4))) {=0A bar_info->val =3D res[pos - 1].start >> = 32;=0A- bar_info->len_val =3D res[pos - 1].end >> 32;=0A+ = bar_info->len_val =3D -resource_size(&res[pos - 1]) >> = 32;=0A return;=0A }=0A }=0A =0A+ if = (!res[pos].flags ||=0A+ (res[pos].flags & (IORESOURCE_DISABLED | = IORESOURCE_UNSET |=0A+ IORESOURCE_BUSY)))=0A+ = return;=0A+=0A bar_info->val =3D res[pos].start |=0A = (res[pos].flags & PCI_REGION_FLAG_MASK);=0A- bar_info->len_val =3D = resource_size(&res[pos]);=0A+ bar_info->len_val =3D -resource_size(&res[p= os]) |=0A+ (res[pos].flags & PCI_REGION_FLAG_MASK)= ;=0A }=0A =0A static void *bar_init(struct pci_dev *dev, int offset)=0A = {=0A- struct pci_bar_info *bar =3D kmalloc(sizeof(*bar), GFP_KERNEL);=0A+= struct pci_bar_info *bar =3D kzalloc(sizeof(*bar), GFP_KERNEL);=0A = =0A if (!bar)=0A return ERR_PTR(-ENOMEM);=0A =0A = read_dev_bar(dev, bar, offset, ~0);=0A- bar->which =3D 0;=0A =0A = return bar;=0A }=0A =0A static void *rom_init(struct pci_dev *dev, int = offset)=0A {=0A- struct pci_bar_info *bar =3D kmalloc(sizeof(*bar), = GFP_KERNEL);=0A+ struct pci_bar_info *bar =3D kzalloc(sizeof(*bar), = GFP_KERNEL);=0A =0A if (!bar)=0A return ERR_PTR(-ENOMEM);=0A= =0A read_dev_bar(dev, bar, offset, ~PCI_ROM_ADDRESS_ENABLE);=0A- = bar->which =3D 0;=0A =0A return bar;=0A }=0A --=__PartA89EA354.2__= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --=__PartA89EA354.2__=--