search for: pt_log

...r 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 %016"PRIx64";" + " only dword access is allowed\n", addr); } static void pci_msix_writel(void *opaque,...

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

...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_RDWR); if ( fd < 0 ) { PT_LOG("Error: %s can't open file %s: %s: 0x%x:0x%x.0x%x\n", __func__, PCI_IOMUL_DEV_PATH, strerror(errno), r_bus, r_dev, r_func); fd = PCI_IOMUL_INVALID_FD; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.or...

ioemu-remote: Enable pci pass-through by default. -- Jean Guyader _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

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

...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) >> MSI_TARGET_CPU_SHIFT) & 0xff); + PT_LOG("pt_msix_update_one requested pirq = %d\n", pirq); + } + /* Check if this entry is already mapped */ if ( entry->pirq == -1 ) { _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

vtd: Fix for irq bind failure after PCI attaching 32 times Originally when detaching a PCI device, pirq_to_emuirq and pirq_to_irq are freed via hypercall do_physdev_op. Now in function pt_irq_destroy_bind_vtd, duplicated logic is added to free pirq_to_emuirq, but not pirq_to_irq. This causes do_physdev_op fail to free both emuirq and irq. After attaching a PCI device for 32 times, irq resources

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

...= 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_read(real_dev->pci_dev, PCI_INTEL_OPREGION, 4); igd_guest_opregion = (val & ~0xfff) | (host_opregion & 0xfff); PT_LOG("Map OpRegion: %x -> %x\n", host_opregion, igd_guest_opregion); + //If the opregion is not page-aligned, map one more page to fit the entire region. + map_size += (host_opregion & 0xfff) != 0; ret = xc_domain_memory_mapping(xc_handle, domid, igd_guest_opreg...

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

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