Re: [Xen-devel] Consuming PCI device in PV kernel

[Simon Martin <furryfuttock@xxxxxxxxx>]

Hello Ian,

Thanks for the response.

>> I     have     tried     calling    HYPERCALL_update_va_mapping    and
>> HYPERCALL_mmu_update  and  they both fail. HYPERCALL_update_va_mapping
>> gives me the following in xl dmesg:
>> 
>> (XEN) mm.c:1700:d292v0 Bad L1 flags 400000
>> 
>> Looking at the code I can't see where bit 22 is being set!

> Without seeing you code I've no idea about this (even if I could see it,
> I dunno...)

Bit 22 is being set in Xen code. This is what I am doing:

void *micropv_remap_page(uint64_t physical_address, uint64_t machine_address, 
int readonly)
{
    // Update the mapping. I have had problems using a readonly mapping, 
however I'm not sure whether that was to do with
    // this call, or the page that was being mapped.
    int rc = HYPERVISOR_update_va_mapping(physical_address, 
__pte(machine_address | (readonly ? L1_PROT_RO : L1_PROT)), UVMF_INVLPG);
    if (rc)
    {
        PRINTK("HYPERVISOR_update_va_mapping returns %i", rc);
        return NULL;
    }
    else
    {
        PRINTK("Machine Address %lx mapped to Physical Address %lx", 
machine_address, physical_address);
        return (void*)physical_address;
    }
}

This is the call when I try to map the PCI BAR.

        ptr = micropv_remap_page((uint64_t)buffer, 
pci_device.bar[0].memory.address << 4, 0);
        if (!ptr)
        {
                PRINTK("Error mapping PCI MMIO");
                goto fail;
        }

Where buffer is a page (4096) aligned buffer, one page long and
pci_device.bar.memory.address  is  the  top  28  bits  of  the PCI BAR
register (hence it is left shifted to give the correct address).


-- 
Best regards,
 Simon                            mailto:furryfuttock@xxxxxxxxx


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel