search for: pci_command_io

Hi, > I was thinking of checking whether pdev is a VGA class device and whether > it decodes vga access, and in that case automatically calling How can I figure that? Ok, class is easy, but decode? pci.h offers functions to set vga decode but not to get that info ... thanks, Gerd

Hi, > I was thinking of checking whether pdev is a VGA class device and whether > it decodes vga access, and in that case automatically calling How can I figure that? Ok, class is easy, but decode? pci.h offers functions to set vga decode but not to get that info ... thanks, Gerd

...inking of checking whether pdev is a VGA class device and whether > > it decodes vga access, and in that case automatically calling > > How can I figure that? Ok, class is easy, but decode? pci.h offers > functions to set vga decode but not to get that info ... PCI_COMMAND_MEM and PCI_COMMAND_IO. There doesn't seem to be any separate bits really. That's at least what I've gleaned from vgaarb.c. The magic legacy vga decode bits only seem to exist on bridges, maybe we can extract that logic from vgaarb.c (yes this is all a bit spiralling out of control). -Daniel -- Daniel Vetter...

..._bdf[2], - 0x10, uart->io_base | 0x1); + PCI_BASE_ADDRESS_0, + uart->io_base | PCI_BASE_ADDRESS_SPACE_IO); pci_conf_write16(0, uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[2], - 0x4, 0x1); + PCI_COMMAND, PCI_COMMAND_IO); } static void ns16550_setup_preirq(struct ns16550 *uart) @@ -265,7 +271,17 @@ static void __init ns16550_init_preirq(s /* I/O ports are distinguished by their size (16 bits). */ if ( uart->io_base >= 0x10000 ) + { +#ifdef CONFIG_X86 + enum fixed_addresses idx = FIX...

See http://www.gossamer-threads.com/lists/xen/devel/297170 for some information on how to get this going. I''ve rebased and addressed the review comments. As before several of the patches are not to be applied because they can be done better using infrastructure from Julien''s "Allow Xen to boot with a raw Device Tree" patch. They are included for completeness. With

Greetings, Following patches are intended to support SR-IOV capability in the Linux kernel. With these patches, people can turn a PCI device with the capability into multiple ones from software perspective, which will benefit KVM and achieve other purposes such as QoS, security, and etc. Changes from v5 to v6: 1, update ABI document to include SR-IOV sysfs entries (Greg KH) 2, fix two coding

Greetings, Following patches are intended to support SR-IOV capability in the Linux kernel. With these patches, people can turn a PCI device with the capability into multiple ones from software perspective, which will benefit KVM and achieve other purposes such as QoS, security, and etc. Changes from v5 to v6: 1, update ABI document to include SR-IOV sysfs entries (Greg KH) 2, fix two coding

Greetings, Following patches are intended to support SR-IOV capability in the Linux kernel. With these patches, people can turn a PCI device with the capability into multiple ones from software perspective, which will benefit KVM and achieve other purposes such as QoS, security, and etc. Changes from v5 to v6: 1, update ABI document to include SR-IOV sysfs entries (Greg KH) 2, fix two coding

Hi List, many People seem to be interested in the Graphic-Card Passthrough Feature (for more or less obvious reasons). Official Support is still under development, and i hope not to interfere with it in any (bad) way ... But i remember my own painfull and timeconsuming research when i wanted this feature to work, so i thought perhaps this spares some time for the unpatient users like me :)

Greetings, Following patches are intended to support SR-IOV capability in the Linux kernel. With these patches, people can turn a PCI device with the capability into multiple ones from software perspective, which will benefit KVM and achieve other purposes such as QoS, security, and etc. Major changes between v4 -> v5: 1, remove interfaces for PF driver to create sysfs entries (Matthew

Greetings, Following patches are intended to support SR-IOV capability in the Linux kernel. With these patches, people can turn a PCI device with the capability into multiple ones from software perspective, which will benefit KVM and achieve other purposes such as QoS, security, and etc. Major changes between v4 -> v5: 1, remove interfaces for PF driver to create sysfs entries (Matthew

...ze == size) + return; + r->size = size; + pci_unmap_region(pci_dev, r); + r->addr = -1; + pci_update_mappings(pci_dev); } diff --git a/hw/pci.h b/hw/pci.h index 8c8d808..339a700 100644 --- a/hw/pci.h +++ b/hw/pci.h @@ -108,6 +108,7 @@ typedef struct PCIIORegion { #define PCI_COMMAND_IO 0x1 /* Enable response in I/O space */ #define PCI_COMMAND_MEMORY 0x2 /* Enable response in Memory space */ #define PCI_STATUS 0x06 /* 16 bits */ +#define PCI_STATUS_CAP_LIST 0x10 /* Support Capability List */ #define PCI_REVISION_ID 0x08 /* 8 bits */ #define PCI_...

...ze == size) + return; + r->size = size; + pci_unmap_region(pci_dev, r); + r->addr = -1; + pci_update_mappings(pci_dev); } diff --git a/hw/pci.h b/hw/pci.h index 8c8d808..339a700 100644 --- a/hw/pci.h +++ b/hw/pci.h @@ -108,6 +108,7 @@ typedef struct PCIIORegion { #define PCI_COMMAND_IO 0x1 /* Enable response in I/O space */ #define PCI_COMMAND_MEMORY 0x2 /* Enable response in Memory space */ #define PCI_STATUS 0x06 /* 16 bits */ +#define PCI_STATUS_CAP_LIST 0x10 /* Support Capability List */ #define PCI_REVISION_ID 0x08 /* 8 bits */ #define PCI_...

See http://www.gossamer-threads.com/lists/xen/devel/297170 for some information on how to get this going. I''ve rebased and addressed the review comments. With this rebase I''ve picked up some patches from Julien which were required to do things properly, so the gic v7 and device blacklisting patches have been changed to use the proper mechanisms. Previously I was able to boot

...vpci->msix_io_block, PCI_IO_SIZE, false, + virtio_pcim__msix_mmio_callback, vpci); + if (r < 0) + goto free_mmio; + + vpci->pci_hdr = (struct pci_device_header) { + .vendor_id = cpu_to_le16(PCI_VENDOR_ID_REDHAT_QUMRANET), + .device_id = cpu_to_le16(device_id), + .command = PCI_COMMAND_IO | PCI_COMMAND_MEMORY, + .header_type = PCI_HEADER_TYPE_NORMAL, + .revision_id = 0, + .class[0] = class & 0xff, + .class[1] = (class >> 8) & 0xff, + .class[2] = (class >> 16) & 0xff, + .subsys_vendor_id = cpu_to_le16(PCI_SUBSYSTEM_VENDOR_ID_REDHAT_QUMRANET), + .su...

...vpci->msix_io_block, PCI_IO_SIZE, false, + virtio_pcim__msix_mmio_callback, vpci); + if (r < 0) + goto free_mmio; + + vpci->pci_hdr = (struct pci_device_header) { + .vendor_id = cpu_to_le16(PCI_VENDOR_ID_REDHAT_QUMRANET), + .device_id = cpu_to_le16(device_id), + .command = PCI_COMMAND_IO | PCI_COMMAND_MEMORY, + .header_type = PCI_HEADER_TYPE_NORMAL, + .revision_id = 0, + .class[0] = class & 0xff, + .class[1] = (class >> 8) & 0xff, + .class[2] = (class >> 16) & 0xff, + .subsys_vendor_id = cpu_to_le16(PCI_SUBSYSTEM_VENDOR_ID_REDHAT_QUMRANET), + .su...

Hello, I have been working on VGA-passthrough in the last month. When Xen was at his version 3.5 there was a few patches to make this work for some graphic cards using the patches developed by Han Weidong and posted here (http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01176.html) and the same patches posted file by file are here

Hello, I have been working on VGA-passthrough in the last month. When Xen was at his version 3.5 there was a few patches to make this work for some graphic cards using the patches developed by Han Weidong and posted here (http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01176.html) and the same patches posted file by file are here