search for: pt_dev

...pport for HVM guest. Signed-off-by: Yu Zhao <yu.zhao@intel.com> diff --git a/hw/pass-through.c b/hw/pass-through.c index 77ab759..da1a86b 100644 --- a/hw/pass-through.c +++ b/hw/pass-through.c @@ -47,6 +47,10 @@ struct dpci_infos { /* prototype */ static uint32_t pt_common_reg_init(struct pt_dev *ptdev, struct pt_reg_info_tbl *reg, uint32_t real_offset); +static uint32_t pt_vendor_reg_init(struct pt_dev *ptdev, + struct pt_reg_info_tbl *reg, uint32_t real_offset); +static uint32_t pt_device_reg_init(struct pt_dev *ptdev, + struct pt_reg_info_tbl *reg, uint32_t real_offset); sta...

The OpRegion shouldn''t be mapped 1:1 because the address in the host can''t be used in the guest directly. This patch traps read and write access to the opregion of the Intel GPU config space (offset 0xfc). To work correctly this patch needs a change in hvmloader. HVMloader will allocate 2 pages for the OpRegion and write this address on the config space of the Intel GPU. Qemu

...s/qemu-xen-traditional/hw/pass-through.c. and found pt_iomul_init is called if CONFIG_STUBDOM not defined. so should CONFIG_STUBDOM be defined ? Below is part of pass-through.c. #ifndef CONFIG_STUBDOM #define PCI_IOMUL_DEV_PATH "/dev/xen/pci_iomul" static void pt_iomul_init(struct pt_dev *assigned_device, uint8_t r_bus, uint8_t r_dev, uint8_t r_func) { int fd = PCI_IOMUL_INVALID_FD; struct pci_iomul_setup setup = { .segment = 0, .bus = r_bus, .dev = r_dev, .func = r_func, }; fd = open(PCI_IOMUL_DEV_PATH, O_R...

Userspace patches for the pci-passthrough functionality. The major updates since the last post are: - Loop to add passthrough devices in pc_init1 - Handle errors in read/write calls - Allow invocation without irq number for in-kernel irqchip Other than this, several small things were fixed according to review comments received last time.

Userspace patches for the pci-passthrough functionality. The major updates since the last post are: - Loop to add passthrough devices in pc_init1 - Handle errors in read/write calls - Allow invocation without irq number for in-kernel irqchip Other than this, several small things were fixed according to review comments received last time.

...to guest. + */ + if (dev->vendor_id == PCI_VENDOR_ID_INTEL && + dev->device_id == PCI_DEVICE_ID_INTEL_82599_VF) + return 1; + break; + } + + return 0; +} + /* initialize emulate register group */ static int pt_config_init(struct pt_dev *ptdev) { @@ -2424,6 +2443,9 @@ static int pt_config_init(struct pt_dev *ptdev) { if (pt_emu_reg_grp_tbl[i].grp_id != 0xFF) { + if (pt_hide_dev_cap(ptdev->pci_dev, pt_emu_reg_grp_tbl[i].grp_id)) + continue; + reg_grp_offset = (uint32...

Hi developers, I met some domU issues and the log suggests missing interrupt. Details from here: http://www.gossamer-threads.com/lists/xen/users/263938#263938 In summary, this is the suspicious log: (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 I''ve checked the code in question and found that mode 3 is an ''reserved_1'' mode. I want to trace down the source of this

...id, - pch_map_irq, "intel_bridge_1f"); + if (vid == PCI_VENDOR_ID_INTEL) { + pci_isa_bridge_init(bus, PCI_DEVFN(0x1f, 0), vid, did, rid, + pch_map_irq, "intel_bridge_1f"); + + } } uint32_t igd_read_opregion(struct pt_dev *pci_dev) -- 1.7.10.4

...tdev->dev.devfn >> 3) & 0x1f; - /* fix virtual interrupt pin to INTA# */ - e_intx = 0; + e_device = PCI_SLOT(ptdev->dev.devfn); + e_intx = pci_intx(ptdev); if (ptdev->msi_trans_en == 0 && ptdev->machine_irq) { @@ -4131,7 +4130,6 @@ static struct pt_dev * register_real_dev if (rc < 0 && machine_irq != 0) { e_device = PCI_SLOT(assigned_device->dev.devfn); - /* fix virtual interrupt pin to INTA# */ e_intx = pci_intx(assigned_device); rc = xc_domain_bind_pt_pci_irq(xc_handle, domid, machine_...

...t as pirq number for the following mapping request to Xen. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> diff --git a/hw/pt-msi.c b/hw/pt-msi.c index f0fb3e3..b01744e 100644 --- a/hw/pt-msi.c +++ b/hw/pt-msi.c @@ -300,6 +300,14 @@ static int pt_msix_update_one(struct pt_dev *dev, int entry_nr) if ( !entry->flags ) return 0; + if (!gvec) { + /* if gvec is 0, the guest is asking for a particular pirq that + * is passed as dest_id */ + pirq = ((gaddr >> 32) & 0xffffff00) | + (((gaddr & 0xffffffff) &g...

...well as the sometimes unnecessary access to the physical MSI-X table. Finally, adjust the wording of a few messages to be more precise and/or more useful. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/hw/pt-msi.c +++ b/hw/pt-msi.c @@ -431,8 +431,8 @@ int pt_msix_update_remap(struct pt_dev * static void pci_msix_invalid_write(void *opaque, target_phys_addr_t addr, uint32_t val) { - PT_LOG("Error: Invalid write to MSI-X table, \ - only dword access is allowed.\n"); + PT_LOG("Error: Invalid write to MSI-X table, addr...

...his extra page and complain about resource conflict. Signed-off-by: Timothy Guo <firemeteor@users.sourceforge.net> diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c index c6f8869..3f2b285 100644 --- a/hw/pt-graphics.c +++ b/hw/pt-graphics.c @@ -81,6 +81,7 @@ uint32_t igd_read_opregion(struct pt_dev *pci_dev) void igd_write_opregion(struct pt_dev *real_dev, uint32_t val) { uint32_t host_opregion = 0; + uint32_t map_size = 2; int ret; if ( igd_guest_opregion ) @@ -74,11 +93,13 @@ void igd_write_opregion(struct pt_dev *real_dev, uint32_t val) host_opregion = pt_pci_host...

On Xen-3.3.0, domain0 Megaraid SAS (SAS 1068 controller) driver is not loading correctly if vtd support in Xen is enabled. It fails at the point of initializing firmware. I wasn''t seeing this error with Xen-3.2.2-rc3 (Unstable version), though with vtd disabled in Xen-3.3.0, it is working. Looks like a degrade problem. Any clues? Thx, Venkat

This series contains all the fixes required to produce a working IGD passthrough box. All the changes are previously seen in the dev list but not yet accepted. Some of them are out-dated and need some reshape. Detailed description can be found later in each patch. . [PATCH 1/3] qemu-xen-trad/pt_msi_disable: do not clear all MSI flags . [PATCH 2/3] qemu-xen-trad: Correctly expose PCH ISA bridge

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 :)

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

First off, Apologies for the massive patch series... This series boots a 32-bit dom0 kernel to a command prompt on an ARMv8 (AArch64) model. The kernel is the same one as I am currently using with the 32 bit hypervisor I haven''t yet tried starting a guest or anything super advanced like that ;-). Also there is not real support for 64-bit domains at all, although in one or two places I

This round implements all of the review comments from V2 and all patches are now acked. Unless there are any objections I intend to apply later this morning. Ian.