[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: PCI pass-through issue with Xen 4.11 under ubuntu 20.04



Sorry, to clarify, allowing the networks to work on the domU after a domU 
reboot..

Marc

-----Original Message-----
From: Marc Tousignant <myrdhn@xxxxxxxxx> 
Sent: Friday, May 22, 2020 3:08 PM
To: 'Oliver Linden' <oliver_linden@xxxxxxxxxxx>; 'Chris' <chris@xxxxxxxxx>
Cc: 'xen-users@xxxxxxxxxxxxxxxxxxxx' <xen-users@xxxxxxxxxxxxxxxxxxxx>
Subject: RE: PCI pass-through issue with Xen 4.11 under ubuntu 20.04

Good news.. Only took me 3 days to update my system fully, but the new XEN 
version is allowing networks to continue working after reboot.

Marc

-----Original Message-----
From: Marc Tousignant <myrdhn@xxxxxxxxx>
Sent: Friday, May 22, 2020 2:16 PM
To: 'Oliver Linden' <oliver_linden@xxxxxxxxxxx>; 'Chris' <chris@xxxxxxxxx>
Cc: 'xen-users@xxxxxxxxxxxxxxxxxxxx' <xen-users@xxxxxxxxxxxxxxxxxxxx>
Subject: RE: PCI pass-through issue with Xen 4.11 under ubuntu 20.04

I too will be testing this out. I'm just updating the rest of my system.

Marc

-----Original Message-----
From: Oliver Linden <oliver_linden@xxxxxxxxxxx>
Sent: Friday, May 22, 2020 9:09 AM
To: Chris <chris@xxxxxxxxx>; Marc Tousignant <myrdhn@xxxxxxxxx>
Cc: xen-users@xxxxxxxxxxxxxxxxxxxx
Subject: Re: PCI pass-through issue with Xen 4.11 under ubuntu 20.04

Hi Chris,

I'm not sure whether the patch will solve my issue since for me also the first 
device is always assigned back to pciback after reboot but I'll give Xen 4.12.1 
a try and let you know. Many thanks for this hint.

Best, Oliver

Am 18.05.20 um 15:29 schrieb Chris:
> Hello,
>
> I had the same issue with an onboard LSI HBA (on a supermicro x10sl7-f 
> motherboard). The upgrade to Xen 4.12.1 solved it.
> I think one of the commits in Xen Git tree related to this issue can be found 
> here :
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=dcc0bf5dec61b3dd1c
> c00683b5b9b5bfe0a318de
>
>
>
> On Sat, 16 May 2020 17:47:41 -0400
> "Marc Tousignant" <myrdhn@xxxxxxxxx> wrote:
>
>> Finally, someone else with this issue. 
>> I first reported it back in 2017 when I tried to upgrade from 4.5 to 4.7. It 
>> also happened in 4.6 and 4.8 during testing, and ended up staying on 4.5 at 
>> the time. 
>>
>> Back in 2019 I upgraded to 4.10 and ran in to it again when I updated my 
>> system fully and could no longer run the older kernel/xen combination. Up 
>> till this point I have not seen anyone else report the issue.
>>
>>  
>>
>> Here is my post from 2019. https://lists.gt.net/xen/users/556111
>>
>>  
>>
>> My systems have been Gentoo/Funtoo based. I then run a linux based firewall 
>> (Sophos UTM) and a Windows server on top. If the Windows server restarts, it 
>> loses the connection to the NIC I pass through, if the UTM restarts the NICs 
>> still work..
>>
>>  
>>
>> MarcT
>>
>>  
>>
>> From: Xen-users <xen-users-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of 
>> Oliver Linden
>> Sent: Saturday, May 16, 2020 3:16 AM
>> To: xen-users@xxxxxxxxxxxxxxxxxxxx
>> Subject: PCI pass-through issue with Xen 4.11 under ubuntu 20.04
>>
>>  
>>
>> Dear all,
>>
>> I recently migrated from an long lasting and always upgraded Xen 4.9 / 
>> ubuntu 18.04 server to a brand new one with a fresh install of ubuntu 20.04 
>> and their version of Xen 4.11.
>>
>> I have two DomU instances using ubuntu 18.04 where I assign PCI device 
>> exclusivly to:
>>
>> *    2 NICs
>> *    1 DVB sattelite card
>>
>> Everything is working fine as long as I don't need to "reboot" any of these 
>> DomU's. When doing so the PCI devices get lost and are assigned back to the 
>> pciback driver in Dom0.
>>
>> A shutdown and recreation of the DomU's does solve the issue (workaround) 
>> but I would like the DomU's to keep the assignments during reboot as it was 
>> with all the previous versions I've used.
>>
>> Please let me know which details you need and many thanks in advance.
>>
>> Best, Oliver
>>





 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.