search for: virt_addr

Hi, I have allocated few order=9 pages in Xen memory space using alloc_domheap_pages(NULL,9,0) during boot time just before domain is created (dom0 = domain_create(0, DOMCRF_s3_integrity, DOM0_SSIDREF) in xen/arch/x86/setup.c). I got the following virtual addresses in xen log message- (XEN) a2k2: Virt_addr:ffff83011cc00000 MFN:11cc00 (XEN) a2k2: Virt_addr:ffff83011ca00000 MFN:11ca00 (XEN) a2k2: Virt_addr:ffff83011c800000 MFN:11c800 (XEN) a2k2: Virt_addr:ffff83011c600000 MFN:11c600 (XEN) a2k2: Virt_addr:ffff83011c400000 MFN:11c400 (XEN) a2k2: Virt_addr:ffff83011c200000 MFN:11c200 (XEN) a2k...

...n successfully detached from an address space, its ID can be reused by the driver for another address space. NOENT: device not found. INVAL: device wasn't attached to any address space. 3. Map region ------------- struct virtio_iommu_req_map { le32 address_space; le64 phys_addr; le64 virt_addr; le64 size; le32 flags; }; VIRTIO_IOMMU_MAP_F_READ 0x1 VIRTIO_IOMMU_MAP_F_WRITE 0x2 VIRTIO_IOMMU_MAP_F_EXEC 0x4 Map a range of virtually-contiguous addresses to a range of physically-contiguous addresses. Size must always be a multiple of the page granularity negotiated during initialization....

...main; @@ -550,13 +558,7 @@ static int viommu_map(struct iommu_domain *domain, unsigned long iova, { int ret; struct viommu_domain *vdomain = to_viommu_domain(domain); - struct virtio_iommu_req_map req = { - .head.type = VIRTIO_IOMMU_T_MAP, - .address_space = cpu_to_le32(vdomain->id), - .virt_addr = cpu_to_le64(iova), - .phys_addr = cpu_to_le64(paddr), - .size = cpu_to_le64(size), - }; + struct virtio_iommu_req_map *req; pr_debug("map %llu 0x%lx -> 0x%llx (%zu)\n", vdomain->id, iova, paddr, size); @@ -564,17 +566,30 @@ static int viommu_map(struct iommu_domain *doma...

This is version 0.5 of the virtio-iommu specification, the paravirtualized IOMMU. This version addresses feedback from v0.4 and adds an event virtqueue. Please find the specification, LaTeX sources and pdf, at: git://linux-arm.org/virtio-iommu.git viommu/v0.5 http://linux-arm.org/git?p=virtio-iommu.git;a=blob;f=dist/v0.5/virtio-iommu-v0.5.pdf A detailed changelog since v0.4 follows. You can find

This is version 0.5 of the virtio-iommu specification, the paravirtualized IOMMU. This version addresses feedback from v0.4 and adds an event virtqueue. Please find the specification, LaTeX sources and pdf, at: git://linux-arm.org/virtio-iommu.git viommu/v0.5 http://linux-arm.org/git?p=virtio-iommu.git;a=blob;f=dist/v0.5/virtio-iommu-v0.5.pdf A detailed changelog since v0.4 follows. You can find

This is the initial proposal for a paravirtualized IOMMU device using virtio transport. It contains a description of the device, a Linux driver, and a toy implementation in kvmtool. With this prototype, you can translate DMA to guest memory from emulated (virtio), or passed-through (VFIO) devices. In its simplest form, implemented here, the device handles map/unmap requests from the guest. Future

This is the initial proposal for a paravirtualized IOMMU device using virtio transport. It contains a description of the device, a Linux driver, and a toy implementation in kvmtool. With this prototype, you can translate DMA to guest memory from emulated (virtio), or passed-through (VFIO) devices. In its simplest form, implemented here, the device handles map/unmap requests from the guest. Future

...the physical IOMMU to observe the mappings without any additional request. When changing or removing a mapping, however, the driver must send an invalidate request. VIRTIO_IOMMU_T_INVALIDATE struct virtio_iommu_req_invalidate { le32 address_space; le32 context; le32 flags; le64 virt_addr; le64 range_size; u8 opaque[64]; }; 'flags' may be: VIRTIO_IOMMU_INVALIDATE_T_VADDR: invalidate a single VA range from 'context' (context is 0 when !F_INDIRECT). And with context tables only (explained below): VIRTIO_IOMMU_INVALIDATE_T_SINGLE: invali...

.../arch/x86/mm.c --- a/extras/mini-os/arch/x86/mm.c Fri Jan 18 15:55:13 2008 +0000 +++ b/extras/mini-os/arch/x86/mm.c Fri Jan 18 16:02:32 2008 +0000 @@ -50,6 +50,7 @@ #endif unsigned long *phys_to_machine_mapping; +unsigned long mfn_zero; extern char stack[]; extern void page_walk(unsigned long virt_addr); @@ -492,10 +493,13 @@ static void clear_bootstrap(void) static void clear_bootstrap(void) { struct xen_memory_reservation reservation; - xen_pfn_t mfns[] = { virt_to_mfn(0), virt_to_mfn(&shared_info) }; + xen_pfn_t mfns[] = { virt_to_mfn(&shared_info) }; int n = sizeof...

...ed long iova, > + phys_addr_t paddr, size_t size, int prot) { > + int ret; > + struct viommu_domain *vdomain = to_viommu_domain(domain); > + struct virtio_iommu_req_map req = { > + .head.type = VIRTIO_IOMMU_T_MAP, > + .address_space = cpu_to_le32(vdomain->id), > + .virt_addr = cpu_to_le64(iova), > + .phys_addr = cpu_to_le64(paddr), > + .size = cpu_to_le64(size), > + }; > + > + pr_debug("map %llu 0x%lx -> 0x%llx (%zu)\n", vdomain->id, iova, > + paddr, size); A query, when I am tracing above prints I see same physical address is ma...

...ed long iova, > + phys_addr_t paddr, size_t size, int prot) { > + int ret; > + struct viommu_domain *vdomain = to_viommu_domain(domain); > + struct virtio_iommu_req_map req = { > + .head.type = VIRTIO_IOMMU_T_MAP, > + .address_space = cpu_to_le32(vdomain->id), > + .virt_addr = cpu_to_le64(iova), > + .phys_addr = cpu_to_le64(paddr), > + .size = cpu_to_le64(size), > + }; > + > + pr_debug("map %llu 0x%lx -> 0x%llx (%zu)\n", vdomain->id, iova, > + paddr, size); A query, when I am tracing above prints I see same physical address is ma...

...truct iommu_domain *domain, unsigned long iova, + phys_addr_t paddr, size_t size, int prot) +{ + int ret; + struct viommu_domain *vdomain = to_viommu_domain(domain); + struct virtio_iommu_req_map req = { + .head.type = VIRTIO_IOMMU_T_MAP, + .address_space = cpu_to_le32(vdomain->id), + .virt_addr = cpu_to_le64(iova), + .phys_addr = cpu_to_le64(paddr), + .size = cpu_to_le64(size), + }; + + pr_debug("map %llu 0x%lx -> 0x%llx (%zu)\n", vdomain->id, iova, + paddr, size); + + if (!vdomain->attached) + return -ENODEV; + + if (prot & IOMMU_READ) + req.flags |= cpu_to_...

...(!mapping) + return -ENOMEM; + + flags = (prot & IOMMU_READ ? VIRTIO_IOMMU_MAP_F_READ : 0) | + (prot & IOMMU_WRITE ? VIRTIO_IOMMU_MAP_F_WRITE : 0); + + mapping->req.map = (struct virtio_iommu_req_map) { + .head.type = VIRTIO_IOMMU_T_MAP, + .domain = cpu_to_le32(vdomain->id), + .virt_addr = cpu_to_le64(iova), + .phys_addr = cpu_to_le64(paddr), + .size = cpu_to_le64(size), + .flags = cpu_to_le32(flags), + }; + + if (!refcount_read(&vdomain->endpoints)) + return 0; + + ret = viommu_send_req_sync(vdomain->viommu, &mapping->req); + if (ret) + viommu_del_mappings(...

This is the continuation of my proposal for virtio-iommu, the para- virtualized IOMMU. Here is a summary of the changes since last time [1]: * The virtio-iommu document now resembles an actual specification. It is split into a formal description of the virtio device, and implementation notes. Please find sources and binaries at [2]. * Added a probe request to describe to the guest different

This is the continuation of my proposal for virtio-iommu, the para- virtualized IOMMU. Here is a summary of the changes since last time [1]: * The virtio-iommu document now resembles an actual specification. It is split into a formal description of the virtio device, and implementation notes. Please find sources and binaries at [2]. * Added a probe request to describe to the guest different

>>That boot_params.hdr.code32_start field is probably either invalid (bad reloc or something else causing the bootloader to >>calculate the wrong address) or valid but the thing it thinks it is pointing to wasn't loaded (missing PT_LOAD etc.). >boot_params.hdr.code32_start field is valid :) It is 0x100000, like expected > >Then I suspect that that segment isn't being

...t; + flags = (prot & IOMMU_READ ? VIRTIO_IOMMU_MAP_F_READ : 0) | > + (prot & IOMMU_WRITE ? VIRTIO_IOMMU_MAP_F_WRITE : 0); > + > + mapping->req.map = (struct virtio_iommu_req_map) { > + .head.type = VIRTIO_IOMMU_T_MAP, > + .domain = cpu_to_le32(vdomain->id), > + .virt_addr = cpu_to_le64(iova), > + .phys_addr = cpu_to_le64(paddr), > + .size = cpu_to_le64(size), > + .flags = cpu_to_le32(flags), > + }; > + > + if (!refcount_read(&vdomain->endpoints)) > + return 0; > + > + ret = viommu_send_req_sync(vdomain->viommu, &mapping...

.../x86/boot/compressed/misc.h index 2e5f82acc122..a37e7d4b00e4 100644 --- a/arch/x86/boot/compressed/misc.h +++ b/arch/x86/boot/compressed/misc.h @@ -85,8 +85,6 @@ void choose_random_location(unsigned long input, unsigned long *output, unsigned long output_size, unsigned long *virt_addr); -/* cpuflags.c */ -bool has_cpuflag(int flag); #else static inline void choose_random_location(unsigned long input, unsigned long input_size, @@ -97,6 +95,9 @@ static inline void choose_random_location(unsigned long input, } #endif +/* cpuflags.c */ +bool has_cpuflag(int flag); + #...

...oot/compressed/Makefile seems like it has the details; Yeah, what I mean, it not just decompresses it, it also applies relocations to the decompressed output: __decompress(input_data, input_len, NULL, NULL, output, output_len, NULL, error); parse_elf(output); handle_relocations(output, output_len, virt_addr); My idea of quick dumping was based on a some experience for one of FreeBSD loaders I fixed earlier. It was very short (512 bytes if I am not mistaken) and just quick look on LLD and bfd linked hex views revealed the reason instantly. LLD linked binary was like corrupted with 4 bytes holes. All o...

Implement the virtio-iommu driver following version 0.5 of the specification [1]. Previous version of this code was sent back in April [2], implementing the first public RFC. Since then there has been lots of progress and discussion on the specification side, and I think the driver is in a good shape now. The reason patches 1-3 are only RFC is that I'm waiting on feedback from the Virtio TC