search for: virt_to_phy

...@ -363,7 +363,7 @@ static void virtio_ccw_drop_indicator(struct virtio_ccw_device *vcdev, thinint_area->isc = VIRTIO_AIRQ_ISC; ccw->cmd_code = CCW_CMD_SET_IND_ADAPTER; ccw->count = sizeof(*thinint_area); - ccw->cda = (__u32)(unsigned long) thinint_area; + ccw->cda = (__u32)virt_to_phys(thinint_area); } else { /* payload is the address of the indicators */ indicatorp = ccw_device_dma_zalloc(vcdev->cdev, @@ -373,7 +373,7 @@ static void virtio_ccw_drop_indicator(struct virtio_ccw_device *vcdev, *indicatorp = 0; ccw->cmd_code = CCW_CMD_SET_IND; ccw->count =...

...@ -363,7 +363,7 @@ static void virtio_ccw_drop_indicator(struct virtio_ccw_device *vcdev, thinint_area->isc = VIRTIO_AIRQ_ISC; ccw->cmd_code = CCW_CMD_SET_IND_ADAPTER; ccw->count = sizeof(*thinint_area); - ccw->cda = (__u32)(unsigned long) thinint_area; + ccw->cda = (__u32)virt_to_phys(thinint_area); } else { /* payload is the address of the indicators */ indicatorp = ccw_device_dma_zalloc(vcdev->cdev, @@ -373,7 +373,7 @@ static void virtio_ccw_drop_indicator(struct virtio_ccw_device *vcdev, *indicatorp = 0; ccw->cmd_code = CCW_CMD_SET_IND; ccw->count =...

...> writes: > When using a virtio transport, the 9p net device allocates pages to back > the descriptors inserted into the virtqueue. These allocations may be > performed from atomic context (under the channel lock) and can therefore > return high mappings which aren't suitable for virt_to_phys. I had not appreciated that subtlety about GFP_ATOMIC :( This isn't just 9p, the console, block, scsi and net devices also use GFP_ATOMIC. > @@ -165,7 +166,8 @@ static int vring_add_indirect(struct vring_virtqueue *vq, > /* Use a single buffer which doesn't continue */ > he...

...> writes: > When using a virtio transport, the 9p net device allocates pages to back > the descriptors inserted into the virtqueue. These allocations may be > performed from atomic context (under the channel lock) and can therefore > return high mappings which aren't suitable for virt_to_phys. I had not appreciated that subtlety about GFP_ATOMIC :( This isn't just 9p, the console, block, scsi and net devices also use GFP_ATOMIC. > @@ -165,7 +166,8 @@ static int vring_add_indirect(struct vring_virtqueue *vq, > /* Use a single buffer which doesn't continue */ > he...

...46,6 @@ static struct virtqueue *vm_setup_vq(struct virtio_device *vdev, unsigned index, info->num /= 2; } - /* Activate the queue */ - writel(info->num, vm_dev->base + VIRTIO_MMIO_QUEUE_NUM); - writel(VIRTIO_MMIO_VRING_ALIGN, - vm_dev->base + VIRTIO_MMIO_QUEUE_ALIGN); - writel(virt_to_phys(info->queue) >> PAGE_SHIFT, - vm_dev->base + VIRTIO_MMIO_QUEUE_PFN); - /* Create the vring */ vq = vring_new_virtqueue(index, info->num, VIRTIO_MMIO_VRING_ALIGN, vdev, true, info->queue, vm_notify, callback, name); @@ -371,6 +354,33 @@ static struct virtqueue *vm_setu...

...46,6 @@ static struct virtqueue *vm_setup_vq(struct virtio_device *vdev, unsigned index, info->num /= 2; } - /* Activate the queue */ - writel(info->num, vm_dev->base + VIRTIO_MMIO_QUEUE_NUM); - writel(VIRTIO_MMIO_VRING_ALIGN, - vm_dev->base + VIRTIO_MMIO_QUEUE_ALIGN); - writel(virt_to_phys(info->queue) >> PAGE_SHIFT, - vm_dev->base + VIRTIO_MMIO_QUEUE_PFN); - /* Create the vring */ vq = vring_new_virtqueue(index, info->num, VIRTIO_MMIO_VRING_ALIGN, vdev, true, info->queue, vm_notify, callback, name); @@ -371,6 +354,33 @@ static struct virtqueue *vm_setu...

We can't just do virt_to_phys() on memory that we pass to the device and expect it to work in presence of a virtual IOMMU. We need to add IOMMU mappings for such DMAs to work correctly. Fix that with pci_alloc_consistent() where possible, or pci_map_single() where the mapping is short-lived or we don't control the alloca...

We can't just do virt_to_phys() on memory that we pass to the device and expect it to work in presence of a virtual IOMMU. We need to add IOMMU mappings for such DMAs to work correctly. Fix that with pci_alloc_consistent() where possible, or pci_map_single() where the mapping is short-lived or we don't control the alloca...

...p_vq(struct virtio_device *vdev, unsigned index, > info->num /= 2; > } > > - /* Activate the queue */ > - writel(info->num, vm_dev->base + VIRTIO_MMIO_QUEUE_NUM); > - writel(VIRTIO_MMIO_VRING_ALIGN, > - vm_dev->base + VIRTIO_MMIO_QUEUE_ALIGN); > - writel(virt_to_phys(info->queue) >> PAGE_SHIFT, > - vm_dev->base + VIRTIO_MMIO_QUEUE_PFN); > - > /* Create the vring */ > vq = vring_new_virtqueue(index, info->num, VIRTIO_MMIO_VRING_ALIGN, vdev, > true, info->queue, vm_notify, callback, name); > @@ -371,6 +354,33 @@ st...

Hi all, this patch series introduces support for running Linux on top of Xen inside a virtual machine with virtio devices (nested virt scenario). The problem is that Linux virtio drivers use virt_to_phys to get the guest pseudo-physical addresses to pass to the backend, which doesn't work as expected on Xen. Switching the virtio drivers to the dma APIs (dma_alloc_coherent, dma_map/unmap_single and dma_map/unmap_sg) would solve the problem, as Xen support in Linux provides an implementation of...

Hi all, this patch series introduces support for running Linux on top of Xen inside a virtual machine with virtio devices (nested virt scenario). The problem is that Linux virtio drivers use virt_to_phys to get the guest pseudo-physical addresses to pass to the backend, which doesn't work as expected on Xen. Switching the virtio drivers to the dma APIs (dma_alloc_coherent, dma_map/unmap_single and dma_map/unmap_sg) would solve the problem, as Xen support in Linux provides an implementation of...

Hello, I have been hunting a memory-leak warning in vring_add_indirect: unreferenced object 0xffff88003d467e20 (size 32): comm "softirq", pid 0, jiffies 4295197765 (age 6.364s) hex dump (first 32 bytes): 28 19 bf 3d 00 00 00 00 0c 00 00 00 01 00 01 00 (..=............ 02 dc 51 3c 00 00 00 00 56 00 00 00 00 00 00 00 ..Q<....V....... backtrace:

Hello, I have been hunting a memory-leak warning in vring_add_indirect: unreferenced object 0xffff88003d467e20 (size 32): comm "softirq", pid 0, jiffies 4295197765 (age 6.364s) hex dump (first 32 bytes): 28 19 bf 3d 00 00 00 00 0c 00 00 00 01 00 01 00 (..=............ 02 dc 51 3c 00 00 00 00 56 00 00 00 00 00 00 00 ..Q<....V....... backtrace:

...; - /* We're about to use a buffer */ > > - vq->vq.num_free--; > > - > > /* Use a single buffer which doesn't continue */ > > head = vq->free_head; > > - vq->vring.desc[head].flags = VRING_DESC_F_INDIRECT; > > - vq->vring.desc[head].addr = virt_to_phys(desc); > > + vq->vring.desc[head].flags = > > + cpu_to_virtio16(vq->vq.vdev, VRING_DESC_F_INDIRECT); > > + vq->vring.desc[head].addr = > > + cpu_to_virtio64(vq->vq.vdev, virt_to_phys(desc)); > > /* kmemleak gives a false positive, as it's hidden by...

...; - /* We're about to use a buffer */ > > - vq->vq.num_free--; > > - > > /* Use a single buffer which doesn't continue */ > > head = vq->free_head; > > - vq->vring.desc[head].flags = VRING_DESC_F_INDIRECT; > > - vq->vring.desc[head].addr = virt_to_phys(desc); > > + vq->vring.desc[head].flags = > > + cpu_to_virtio16(vq->vq.vdev, VRING_DESC_F_INDIRECT); > > + vq->vring.desc[head].addr = > > + cpu_to_virtio64(vq->vq.vdev, virt_to_phys(desc)); > > /* kmemleak gives a false positive, as it's hidden by...

...ude <asm/proto.h> #include <asm/cacheflush.h> #include <asm/kdebug.h> +#include <asm-xen/xen-public/memory.h> dma_addr_t bad_dma_address; @@ -39,6 +40,11 @@ u32 *iommu_gatt_base; /* Remapping table */ +/* gart remapping */ +#define virt_to_gart(x) (phys_to_gart(virt_to_phys(x))) +#define gart_to_virt(x) (phys_to_virt(gart_to_phys(x))) +#include <asm-xen/asm-i386/agp.h> + int no_iommu; static int no_agp; #ifdef CONFIG_IOMMU_DEBUG @@ -416,7 +422,7 @@ if (!dev) dev = &fallback_dev; - phys_mem = virt_to_phys(addr); + phys_mem = virt_to_bus(addr);...

...tal_sg, gfp); > + else > + desc = NULL; > + > + if (desc) { > + /* Use a single buffer which doesn't continue */ > + vq->vring.desc[head].flags = VRING_DESC_F_INDIRECT; > + vq->vring.desc[head].addr = virt_to_phys(desc); > + /* avoid kmemleak false positive (hidden by virt_to_phys) */ > + kmemleak_ignore(desc); > + vq->vring.desc[head].len = total_sg * sizeof(struct vring_desc); > + > + /* Set up rest to use this indirect table. */ &g...

...tal_sg, gfp); > + else > + desc = NULL; > + > + if (desc) { > + /* Use a single buffer which doesn't continue */ > + vq->vring.desc[head].flags = VRING_DESC_F_INDIRECT; > + vq->vring.desc[head].addr = virt_to_phys(desc); > + /* avoid kmemleak false positive (hidden by virt_to_phys) */ > + kmemleak_ignore(desc); > + vq->vring.desc[head].len = total_sg * sizeof(struct vring_desc); > + > + /* Set up rest to use this indirect table. */ &g...

These patch update Windows generation ID support on ACPI. First patch mainly update to new specifications while second one introduce again the device in ACPI table. Frediano Ziglio (2): genid: Update Windows generation ID genid: Introduce again Windows generation ID device docs/misc/xenstore-paths.markdown | 6 ++++ tools/firmware/hvmloader/acpi/build.c | 49

The spec is very clear on this: 4.1.3.1 Driver Requirements: PCI Device Layout The driver MUST access each field using the ?natural? access method, i.e. 32-bit accesses for 32-bit fields, 16-bit accesses for 16-bit fields and 8-bit accesses for 8-bit fields. Add type-safe wrappers to prevent access with incorrect width. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> ---