VT-d regression issue

VT-d regression issue

[Hao, Xudong]

Hi, all

On KVM commit cb7eaecb3389c7fa2490ea1bee8f10cfa5df30d4, I met a kvm_run return fasle when assign additional NIC device to KVM guest, but onboard NIC works fine.

command: qemu-system-x86_64  -m 256 -smp 2  -device pci-assign,host=01:00.0 -net none -hda /image/path/guest.img
host print:
kvm_run: Bad address
kvm_run returned -14

platform: Westmere-HEDT
NIC device: 01:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06)

VT-d works fine on KVM commit 8dea5648467102184c65d61cf2be6e0fbfa41060 and new qemu-kvm.

https://bugzilla.kernel.org/show_bug.cgi?id=16437


Best Regards,
Xudong Hao

Re: VT-d regression issue

[Gleb Natapov]

On Thu, Jul 22, 2010 at 03:57:55PM +0800, Hao, Xudong wrote:
> Hi, all
> 
> On KVM commit cb7eaecb3389c7fa2490ea1bee8f10cfa5df30d4, I met a kvm_run return fasle when assign additional NIC device to KVM guest, but onboard NIC works fine.
> 
> command: qemu-system-x86_64  -m 256 -smp 2  -device pci-assign,host=01:00.0 -net none -hda /image/path/guest.img
Which version of qemu-kvm is this?

> host print:
> kvm_run: Bad address
> kvm_run returned -14
> 
> platform: Westmere-HEDT
> NIC device: 01:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06)
> 
lspci -vv -s 01:00.0?

> VT-d works fine on KVM commit 8dea5648467102184c65d61cf2be6e0fbfa41060 and new qemu-kvm.
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=16437
> 
> 
> Best Regards,
> Xudong Hao
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
			Gleb.

RE: VT-d regression issue

[Hao, Xudong]

[root@vt-nhm1 ~]# lspci -vv -s 01:00.0
01:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06)
	Subsystem: Intel Corporation PRO/1000 PT Desktop Adapter
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at d3c20000 (32-bit, non-prefetchable) [size=128K]
	Region 1: Memory at d3c00000 (32-bit, non-prefetchable) [size=128K]
	Region 2: I/O ports at 5000 [size=32]
	Expansion ROM at d3e00000 [size=128K]
	Capabilities: [c8] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [d0] MSI: Mask- 64bit+ Count=1/1 Enable-
		Address: 00000000fee00418  Data: 0000
	Capabilities: [e0] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <4us, L1 <64us
			ClockPM- Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		AERCap:	First Error Pointer: 14, GenCap- CGenEn- ChkCap- ChkEn-
	Capabilities: [140] Device Serial Number 82-ff-04-ff-ff-21-1b-00
	Kernel driver in use: pci-stub
	Kernel modules: e1000e

Gleb Natapov wrote:
> On Thu, Jul 22, 2010 at 03:57:55PM +0800, Hao, Xudong wrote:
>> Hi, all
>> 
>> On KVM commit cb7eaecb3389c7fa2490ea1bee8f10cfa5df30d4, I met a
>> kvm_run return fasle when assign additional NIC device to KVM guest,
>> but onboard NIC works fine.  
>> 
>> command: qemu-system-x86_64  -m 256 -smp 2  -device
>> pci-assign,host=01:00.0 -net none -hda /image/path/guest.img 
> Which version of qemu-kvm is this?
> 
>> host print:
>> kvm_run: Bad address
>> kvm_run returned -14
>> 
>> platform: Westmere-HEDT
>> NIC device: 01:00.0 Ethernet controller: Intel Corporation 82572EI
>> Gigabit Ethernet Controller (Copper) (rev 06) 
>> 
> lspci -vv -s 01:00.0?
> 
>> VT-d works fine on KVM commit
>> 8dea5648467102184c65d61cf2be6e0fbfa41060 and new qemu-kvm. 
>> 
>> https://bugzilla.kernel.org/show_bug.cgi?id=16437
>> 
>> 
>> Best Regards,
>> Xudong Hao
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



Thanks,
Xudong

Re: VT-d regression issue

[Gleb Natapov]

On Thu, Jul 22, 2010 at 04:47:12PM +0800, Hao, Xudong wrote:
> [root@vt-nhm1 ~]# lspci -vv -s 01:00.0
> 01:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06)
> 	Subsystem: Intel Corporation PRO/1000 PT Desktop Adapter
> 	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> 	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> 	Interrupt: pin A routed to IRQ 16
> 	Region 0: Memory at d3c20000 (32-bit, non-prefetchable) [size=128K]
> 	Region 1: Memory at d3c00000 (32-bit, non-prefetchable) [size=128K]
> 	Region 2: I/O ports at 5000 [size=32]
> 	Expansion ROM at d3e00000 [size=128K]
> 	Capabilities: [c8] Power Management version 2
> 		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> 		Status: D0 PME-Enable- DSel=0 DScale=1 PME-
> 	Capabilities: [d0] MSI: Mask- 64bit+ Count=1/1 Enable-
> 		Address: 00000000fee00418  Data: 0000
> 	Capabilities: [e0] Express (v1) Endpoint, MSI 00
> 		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
> 			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
> 		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
> 			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
> 			MaxPayload 128 bytes, MaxReadReq 512 bytes
> 		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
> 		LnkCap:	Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <4us, L1 <64us
> 			ClockPM- Surprise- LLActRep- BwNot-
> 		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
> 			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> 		LnkSta:	Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
> 	Capabilities: [100] Advanced Error Reporting
> 		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
> 		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> 		UESvrt:	DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> 		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
> 		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
> 		AERCap:	First Error Pointer: 14, GenCap- CGenEn- ChkCap- ChkEn-
> 	Capabilities: [140] Device Serial Number 82-ff-04-ff-ff-21-1b-00
> 	Kernel driver in use: pci-stub
> 	Kernel modules: e1000e
> 

Can you try this patch for qemu-kvm please?

diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 2bba22f..7240985 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -238,9 +238,10 @@ static void assigned_dev_iomem_map_slow(PCIDevice *pci_dev, int region_num,
     DEBUG("%s", "slow map\n");
     if (region_num == PCI_ROM_SLOT)
         m = cpu_register_io_memory(slow_bar_read, NULL, region);
-    else
+    else {
         m = cpu_register_io_memory(slow_bar_read, slow_bar_write, region);
-    cpu_register_physical_memory(e_phys, e_size, m);
+        cpu_register_physical_memory(e_phys, e_size, m);
+    }
 
     /* MSI-X MMIO page */
     if ((e_size > 0) &&
--
			Gleb.

RE: VT-d regression issue

[Hao, Xudong]

Patch did not work, qemu stoped @ 
> Can you try this patch for qemu-kvm please?
> 
> diff --git a/hw/device-assignment.c b/hw/device-assignment.c
> index 2bba22f..7240985 100644
> --- a/hw/device-assignment.c
> +++ b/hw/device-assignment.c
> @@ -238,9 +238,10 @@ static void
>      assigned_dev_iomem_map_slow(PCIDevice *pci_dev, int region_num,
>      DEBUG("%s", "slow map\n"); if (region_num == PCI_ROM_SLOT)
>          m = cpu_register_io_memory(slow_bar_read, NULL, region);
> -    else
> +    else {
>          m = cpu_register_io_memory(slow_bar_read, slow_bar_write,
> region); -    cpu_register_physical_memory(e_phys, e_size, m);
> +        cpu_register_physical_memory(e_phys, e_size, m);
> +    }
> 
>      /* MSI-X MMIO page */
>      if ((e_size > 0) &&



Thanks,
Xudong

Re: VT-d regression issue

[Gleb Natapov]

On Thu, Jul 22, 2010 at 07:09:37PM +0800, Hao, Xudong wrote:
> Patch did not work, qemu stoped @ 
Stopped with the same error?

> > 
> > diff --git a/hw/device-assignment.c b/hw/device-assignment.c
> > index 2bba22f..7240985 100644
> > --- a/hw/device-assignment.c
> > +++ b/hw/device-assignment.c
> > @@ -238,9 +238,10 @@ static void
> >      assigned_dev_iomem_map_slow(PCIDevice *pci_dev, int region_num,
> >      DEBUG("%s", "slow map\n"); if (region_num == PCI_ROM_SLOT)
> >          m = cpu_register_io_memory(slow_bar_read, NULL, region);
> > -    else
> > +    else {
> >          m = cpu_register_io_memory(slow_bar_read, slow_bar_write,
> > region); -    cpu_register_physical_memory(e_phys, e_size, m);
> > +        cpu_register_physical_memory(e_phys, e_size, m);
> > +    }
> > 
> >      /* MSI-X MMIO page */
> >      if ((e_size > 0) &&
> 
> 
> 
> Thanks,
> Xudong

--
			Gleb.

RE: VT-d regression issue

[Hao, Xudong]

Gleb,
This patch does not work either, qemu stoped @ Starting Seabios.

> 
> Can you try this patch for qemu-kvm please?
> 
> diff --git a/hw/device-assignment.c b/hw/device-assignment.c
> index 2bba22f..7240985 100644
> --- a/hw/device-assignment.c
> +++ b/hw/device-assignment.c
> @@ -238,9 +238,10 @@ static void
>      assigned_dev_iomem_map_slow(PCIDevice *pci_dev, int region_num,
>      DEBUG("%s", "slow map\n"); if (region_num == PCI_ROM_SLOT)
>          m = cpu_register_io_memory(slow_bar_read, NULL, region);
> -    else
> +    else {
>          m = cpu_register_io_memory(slow_bar_read, slow_bar_write,
> region); -    cpu_register_physical_memory(e_phys, e_size, m);
> +        cpu_register_physical_memory(e_phys, e_size, m);
> +    }
> 
>      /* MSI-X MMIO page */
>      if ((e_size > 0) &&



Thanks,
Xudong

RE: VT-d regression issue

[Hao, Xudong]

Gleb Natapov wrote:
> On Thu, Jul 22, 2010 at 07:09:37PM +0800, Hao, Xudong wrote:
>> Patch did not work, qemu stoped @
> Stopped with the same error?
> 
Yes.

>>> 
>>> diff --git a/hw/device-assignment.c b/hw/device-assignment.c
>>> index 2bba22f..7240985 100644
>>> --- a/hw/device-assignment.c
>>> +++ b/hw/device-assignment.c
>>> @@ -238,9 +238,10 @@ static void
>>>      assigned_dev_iomem_map_slow(PCIDevice *pci_dev, int region_num,
>>>      DEBUG("%s", "slow map\n"); if (region_num == PCI_ROM_SLOT)
>>>          m = cpu_register_io_memory(slow_bar_read, NULL, region); -
>>> else +    else {
>>>          m = cpu_register_io_memory(slow_bar_read, slow_bar_write,
>>> region); -    cpu_register_physical_memory(e_phys, e_size, m);
>>> +        cpu_register_physical_memory(e_phys, e_size, m); +    }
>>> 
>>>      /* MSI-X MMIO page */
>>>      if ((e_size > 0) &&
>> 
>> 
>> 
>> Thanks,
>> Xudong



Thanks,
Xudong

Re: VT-d regression issue

[Gleb Natapov]

On Thu, Jul 22, 2010 at 07:11:34PM +0800, Hao, Xudong wrote:
> Gleb,
> This patch does not work either, qemu stoped @ Starting Seabios.
> 
And this one?

diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 2bba22f..b7e7dc0 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -238,9 +238,10 @@ static void assigned_dev_iomem_map_slow(PCIDevice *pci_dev, int region_num,
     DEBUG("%s", "slow map\n");
     if (region_num == PCI_ROM_SLOT)
         m = cpu_register_io_memory(slow_bar_read, NULL, region);
-    else
+    else {
         m = cpu_register_io_memory(slow_bar_read, slow_bar_write, region);
-    cpu_register_physical_memory(e_phys, e_size, m);
+        cpu_register_physical_memory(e_phys, e_size, m);
+    }
 
     /* MSI-X MMIO page */
     if ((e_size > 0) &&
@@ -272,7 +273,8 @@ static void assigned_dev_iomem_map(PCIDevice *pci_dev, int region_num,
         if (region_num == PCI_ROM_SLOT)
             flags |= IO_MEM_ROM;
 
-        cpu_register_physical_memory(e_phys, e_size, region->memory_index | flags);
+        if (region_num != PCI_ROM_SLOT)
+        	cpu_register_physical_memory(e_phys, e_size, region->memory_index | flags);
 
         /* deal with MSI-X MMIO page */
         if (real_region->base_addr <= r_dev->msix_table_addr &&
--
			Gleb.

RE: VT-d regression issue

[Hao, Xudong]

Well, this patch works fine for me.

Gleb Natapov wrote:
> On Thu, Jul 22, 2010 at 07:11:34PM +0800, Hao, Xudong wrote:
>> Gleb,
>> This patch does not work either, qemu stoped @ Starting Seabios.
>> 
> And this one?
> 
> diff --git a/hw/device-assignment.c b/hw/device-assignment.c
> index 2bba22f..b7e7dc0 100644
> --- a/hw/device-assignment.c
> +++ b/hw/device-assignment.c
> @@ -238,9 +238,10 @@ static void
>      assigned_dev_iomem_map_slow(PCIDevice *pci_dev, int region_num,
>      DEBUG("%s", "slow map\n"); if (region_num == PCI_ROM_SLOT)
>          m = cpu_register_io_memory(slow_bar_read, NULL, region);
> -    else
> +    else {
>          m = cpu_register_io_memory(slow_bar_read, slow_bar_write,
> region); -    cpu_register_physical_memory(e_phys, e_size, m);
> +        cpu_register_physical_memory(e_phys, e_size, m);
> +    }
> 
>      /* MSI-X MMIO page */
>      if ((e_size > 0) &&
> @@ -272,7 +273,8 @@ static void assigned_dev_iomem_map(PCIDevice
>          *pci_dev, int region_num, if (region_num == PCI_ROM_SLOT)
>              flags |= IO_MEM_ROM;
> 
> -        cpu_register_physical_memory(e_phys, e_size,
> region->memory_index | flags); +        if (region_num !=
> PCI_ROM_SLOT) +        	cpu_register_physical_memory(e_phys, e_size,
> region->memory_index | flags); 
> 
>          /* deal with MSI-X MMIO page */
>          if (real_region->base_addr <= r_dev->msix_table_addr &&



Thanks,
Xudong

Re: VT-d regression issue

[Gleb Natapov]

On Thu, Jul 22, 2010 at 08:32:31PM +0800, Hao, Xudong wrote:
> Well, this patch works fine for me.
> 
Looks like userspace problem then. Userspace relied on something that
was not guarantied by the kernel (access to read only page forwarded to
userspace as MMOI).

> Gleb Natapov wrote:
> > On Thu, Jul 22, 2010 at 07:11:34PM +0800, Hao, Xudong wrote:
> >> Gleb,
> >> This patch does not work either, qemu stoped @ Starting Seabios.
> >> 
> > And this one?
> > 
> > diff --git a/hw/device-assignment.c b/hw/device-assignment.c
> > index 2bba22f..b7e7dc0 100644
> > --- a/hw/device-assignment.c
> > +++ b/hw/device-assignment.c
> > @@ -238,9 +238,10 @@ static void
> >      assigned_dev_iomem_map_slow(PCIDevice *pci_dev, int region_num,
> >      DEBUG("%s", "slow map\n"); if (region_num == PCI_ROM_SLOT)
> >          m = cpu_register_io_memory(slow_bar_read, NULL, region);
> > -    else
> > +    else {
> >          m = cpu_register_io_memory(slow_bar_read, slow_bar_write,
> > region); -    cpu_register_physical_memory(e_phys, e_size, m);
> > +        cpu_register_physical_memory(e_phys, e_size, m);
> > +    }
> > 
> >      /* MSI-X MMIO page */
> >      if ((e_size > 0) &&
> > @@ -272,7 +273,8 @@ static void assigned_dev_iomem_map(PCIDevice
> >          *pci_dev, int region_num, if (region_num == PCI_ROM_SLOT)
> >              flags |= IO_MEM_ROM;
> > 
> > -        cpu_register_physical_memory(e_phys, e_size,
> > region->memory_index | flags); +        if (region_num !=
> > PCI_ROM_SLOT) +        	cpu_register_physical_memory(e_phys, e_size,
> > region->memory_index | flags); 
> > 
> >          /* deal with MSI-X MMIO page */
> >          if (real_region->base_addr <= r_dev->msix_table_addr &&
> 
> 
> 
> Thanks,
> Xudong

--
			Gleb.

Re: VT-d regression issue

[Alex Williamson]

On Thu, 2010-07-22 at 16:03 +0300, Gleb Natapov wrote:
> On Thu, Jul 22, 2010 at 08:32:31PM +0800, Hao, Xudong wrote:
> > Well, this patch works fine for me.
> > 
> Looks like userspace problem then. Userspace relied on something that
> was not guarantied by the kernel (access to read only page forwarded to
> userspace as MMOI).

I just submitted a set of patches that should fix this using the slow
mapping path for option ROMs.  Thanks,

Alex

RE: VT-d regression issue

[Hao, Xudong]

Alex Williamson wrote:
> On Thu, 2010-07-22 at 16:03 +0300, Gleb Natapov wrote:
>> On Thu, Jul 22, 2010 at 08:32:31PM +0800, Hao, Xudong wrote:
>>> Well, this patch works fine for me.
>>> 
>> Looks like userspace problem then. Userspace relied on something that
>> was not guarantied by the kernel (access to read only page forwarded
>> to userspace as MMOI).
> 
> I just submitted a set of patches that should fix this using the slow
> mapping path for option ROMs.  Thanks,
> 

Alex, I saw your "PCI option ROM fixes" patches in kvm. Does qemu-kvm have corresponding fix for this issue either?

Thanks,
Xudong

RE: VT-d regression issue

[Alex Williamson]

On Sat, 2010-07-31 at 16:33 +0800, Hao, Xudong wrote:
> Alex Williamson wrote:
> > On Thu, 2010-07-22 at 16:03 +0300, Gleb Natapov wrote:
> >> On Thu, Jul 22, 2010 at 08:32:31PM +0800, Hao, Xudong wrote:
> >>> Well, this patch works fine for me.
> >>> 
> >> Looks like userspace problem then. Userspace relied on something that
> >> was not guarantied by the kernel (access to read only page forwarded
> >> to userspace as MMOI).
> > 
> > I just submitted a set of patches that should fix this using the slow
> > mapping path for option ROMs.  Thanks,
> > 
> 
> Alex, I saw your "PCI option ROM fixes" patches in kvm. Does qemu-kvm have corresponding fix for this issue either?

kvm userspace and qemu-kvm are the same thing.  Device assignment
currently only lives in the kvm userspace, it it not merged into
upstream qemu.  Thanks,

Alex

RE: VT-d regression issue

[Hao, Xudong]

Alex Williamson wrote:
> On Sat, 2010-07-31 at 16:33 +0800, Hao, Xudong wrote:
>> Alex Williamson wrote:
>>> On Thu, 2010-07-22 at 16:03 +0300, Gleb Natapov wrote:
>>>> On Thu, Jul 22, 2010 at 08:32:31PM +0800, Hao, Xudong wrote:
>>>>> Well, this patch works fine for me.
>>>>> 
>>>> Looks like userspace problem then. Userspace relied on something
>>>> that was not guarantied by the kernel (access to read only page
>>>> forwarded to userspace as MMOI).
>>> 
>>> I just submitted a set of patches that should fix this using the
>>> slow mapping path for option ROMs.  Thanks,
>>> 
>> 
>> Alex, I saw your "PCI option ROM fixes" patches in kvm. Does
>> qemu-kvm have corresponding fix for this issue either? 
> 
> kvm userspace and qemu-kvm are the same thing.  Device assignment
> currently only lives in the kvm userspace, it it not merged into
> upstream qemu.  Thanks,
> 
> Alex

Ok, I got it, your patch is for userspace. Thanks,

Xudong