similar to: AW: Workaround for pcifront issues

Trying to get a myth backend running in fedora core 6 and xend 3.0.3 but having some issues with the DVB ATSC card, I have removed it from Dom0 and presented it to my vm, but I am unable to scan for channels...this is what lspci looks like for the card: lspci -v 00:00.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card (rev 02) Subsystem:

Hi I wanted to instal the exellent DVBviewer application for viewing DVB-T-Television under fedora9 / wine? Under WinXP i need to do the following 3 steps: 1) installing the Driver of my technisat DVB-hardware via the windows control-panel 2) installing the software of my technisat DVB-hardware 3) installing the DVBviewer application. So under fedora9 / wine i don't know to to the first step

Hi gurus, I used xen 4.1.0 (64bit) + dom0 kernel 2.6.32.39 (32bit) + domu kernel 2.6.32.39 (32bit) environment. I was trying to passthru Broadcom NIC to domu. The NIC can be UP but not RUNNING, on domu #ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:10:18:95:25:90 inet addr:10.0.0.3 Bcast:10.0.255.255 Mask:255.255.0.0 UP BROADCAST MULTICAST MTU:1500 Metric:1

When destroying pcifront/pciback, the following message appears in the guest linux kernel log. WARNING: g.e. still in use! WARNING: leaking g.e. and page still in use! This is caused by the wrong disconnect procedure that pcifront terminates the gnttab foreign access before pciback unmaps the ring. This patch corrects the handling of pcifront/pciback destruction sequence. Firstly pcifront

Hi , I am testing pcifront on freebsd domU using following sound card [ Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] Following sound driver is used for this sound card on Freebsd: *snd_csa*-- Crystal Semiconductor CS461x/462x/4280 PCI bridge device driver I am able to detect the card. pci3: <PCI bus> on pcib3 csa0: <CS4280/CS4614/CS4622/CS4624/CS4630> mem

Dear All, The production server supports Intel Virtualization Technology. Processor is an Intel Xeon 1.86 GHz Quad Core. 8 GB DDR2 memory. There is also an Emulex LightPulse Fiber Channel HBA adapter. The host operating system (Dom 0) is RHEL 5 x86 with Xen Virtualization technology. Dom 0 kernel is 2.6.18-8.el5xen. I have recompiled the Dom 0 kernel so that pciback

Hi, It seems that destroying pcifront/pciback always fails on current xen. This patch fixes the problem, making pciback switch to "Closed" state after pcifront switched to "Closing" state. Regards, ------------------- Yosuke Iwamatsu NEC Corporation _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

On Thu, May 18, 2023 at 08:18:39PM +0200, Marek Marczykowski-G?recki wrote: > On Thu, May 18, 2023 at 03:42:51PM +0200, Christoph Hellwig wrote: > > Remove the dangerous late initialization of xen-swiotlb in > > pci_xen_swiotlb_init_late and instead just always initialize > > xen-swiotlb in the boot code if CONFIG_XEN_PCIDEV_FRONTEND is enabled. > > > >

On Fri, May 19, 2023 at 12:10:26PM +0200, Marek Marczykowski-G?recki wrote: > While I would say PCI passthrough is not very common for PV guests, can > the decision about xen-swiotlb be delayed until you can enumerate > xenstore to check if there are any PCI devices connected (and not > allocate xen-swiotlb by default if there are none)? This would > still not cover the hotplug case

On Mon, May 22, 2023 at 10:37:09AM +0200, Juergen Gross wrote: > In normal cases PCI passthrough in PV guests requires to start the guest > with e820_host=1. So it should be rather easy to limit allocating the > 64MB in PV guests to the cases where the memory map has non-RAM regions > especially in the first 1MB of the memory. > > This will cover even hotplug cases. The only case

On 09.06.23 17:38, Juergen Gross wrote: > On 07.06.23 15:12, Christoph Hellwig wrote: >> On Mon, May 22, 2023 at 10:37:09AM +0200, Juergen Gross wrote: >>> In normal cases PCI passthrough in PV guests requires to start the guest >>> with e820_host=1. So it should be rather easy to limit allocating the >>> 64MB in PV guests to the cases where the memory map has

On 19.05.23 12:10, Marek Marczykowski-G?recki wrote: > On Fri, May 19, 2023 at 06:04:05AM +0200, Christoph Hellwig wrote: >> On Thu, May 18, 2023 at 08:18:39PM +0200, Marek Marczykowski-G?recki wrote: >>> On Thu, May 18, 2023 at 03:42:51PM +0200, Christoph Hellwig wrote: >>>> Remove the dangerous late initialization of xen-swiotlb in >>>>

On Fri, May 19, 2023 at 01:49:46PM +0100, Andrew Cooper wrote: > > The alternative would be to finally merge swiotlb-xen into swiotlb, in > > which case we might be able to do this later. Let me see what I can > > do there. > > If that is an option, it would be great to reduce the special-cashing. I think it's doable, and I've been wanting it for a while. I just

On 07.06.23 15:12, Christoph Hellwig wrote: > On Mon, May 22, 2023 at 10:37:09AM +0200, Juergen Gross wrote: >> In normal cases PCI passthrough in PV guests requires to start the guest >> with e820_host=1. So it should be rather easy to limit allocating the >> 64MB in PV guests to the cases where the memory map has non-RAM regions >> especially in the first 1MB of the

Use new PCI interfaces to simplify xen-pcifront implementation: 1) Use pci_create_root_bus() instead of pci_scan_bus_parented() because pci_scan_bus_parented() is marked as __deprecated.This also gets rid of a duplicated call of pci_bus_start_devices(). 2) Use pci_stop_root_bus() and pci_remove_root_bus() instead of open-coded private implementation. 3) Use pci_set_host_bridge_release()

Use new PCI interfaces to simplify xen-pcifront implementation: 1) Use pci_create_root_bus() instead of pci_scan_bus_parented() because pci_scan_bus_parented() is marked as __deprecated.This also gets rid of a duplicated call of pci_bus_start_devices(). 2) Use pci_stop_root_bus() and pci_remove_root_bus() instead of open-coded private implementation. 3) Use pci_set_host_bridge_release()

Use new PCI interfaces to simplify xen-pcifront implementation: 1) Use pci_create_root_bus() instead of pci_scan_bus_parented() because pci_scan_bus_parented() is marked as __deprecated.This also gets rid of a duplicated call of pci_bus_start_devices(). 2) Use pci_stop_root_bus() and pci_remove_root_bus() instead of open-coded private implementation. 3) Use pci_set_host_bridge_release()

Hello, I am desperately trying to get pci-passthrough to working. I want to pass a tg3 nic to domU. when booting domU I get a lot of messages: pcifront pci-0: pciback not responding!!! in domU, "ifconfig eth... adress up" hangs for 2 minutes, finally ifconfig -a shows a correct setting with no data transmitted rx/tx The IP Adress is being assigned, but there is no data transmission

Hi all, I have a problem when from domU I need to configure a network interface. My system configuration is the next: dom0: xen 3.4.3 with 2.6.18-238.9.1.el5xen kernel, making pci back from a network card. All ok. This is the result from "lspci -v -s 09:00.0" 09:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) Subsystem: Broadcom

Jup, 64 Bit Kernel build is done now and works, but 32 Bit kernel config is different, as I use 64 Bit in Dom0 and DomU, 32 Bit only in DomU incl. DomU with DVB etc. XEN options are the same, it''s only the selection of drivers... Andrew, any idea? Boris, do you know a safe way to create a 64 Bit config out of a 32 Bit one? Sorry, I am not so used to kernel building... BR, Carsten.