From: Simon Martin <furryfuttock@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: Consuming PCI device in PV kernel
Date: Fri, 25 Jul 2014 15:28:17 +0100 [thread overview]
Message-ID: <1103494739.20140725152817@gmail.com> (raw)
In-Reply-To: <1406295478.24842.15.camel@kazak.uk.xensource.com>
Hello Ian,
>> 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);
> The first argument should be the virtual address, I think. But maybe you
> have a 1:1 mapping so this doesn't matter?
I don't think so. I inverted the parameter order and it failed
during the memory address validation. Also this is the same call as I
use for mapping the shared_info at start of day.
>>
>> ptr = micropv_remap_page((uint64_t)buffer, pci_device.bar[0].memory.address << 4, 0);
> Are you sure about that BAR decode? Don't you need to at least mask the
> bottom 4 bits?
Yes I am sure on this. The decoded addresses look correct. I removed
it and get this output from xl dmesg
(XEN) mm.c:828:d304v0 pg_owner 304 l1e_owner 304, but real_pg_owner 0
(XEN) mm.c:899:d304v0 Error getting mfn f7d0 (pfn d2bd) from L1 entry 000000000f7d0027 for l1e_owner=304, pg_owner=304
> You might also need to mask it to a page boundary, depending on what the
> address is...
The BAR is page aligned the value is f7d00000
--
Best regards,
Simon mailto:furryfuttock@gmail.com
prev parent reply other threads:[~2014-07-25 14:28 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-03 11:13 Consuming PCI device in PV kernel Simon Martin
2014-07-03 18:09 ` Konrad Rzeszutek Wilk
2014-07-07 8:21 ` Simon Martin
2014-07-07 11:22 ` Simon Martin
2014-07-07 12:21 ` Realtime access to PCI NIC Simon Martin
2014-07-08 14:46 ` Ian Campbell
2014-07-10 7:47 ` Simon Martin
2014-07-08 15:01 ` Consuming PCI device in PV kernel Konrad Rzeszutek Wilk
2014-07-10 7:54 ` Simon Martin
2014-07-11 16:47 ` Dario Faggioli
2014-07-15 8:37 ` Simon Martin
2014-07-15 14:56 ` Konrad Rzeszutek Wilk
2014-07-18 14:37 ` Simon Martin
2014-07-18 19:09 ` Konrad Rzeszutek Wilk
2014-07-21 10:13 ` Simon Martin
2014-07-21 10:53 ` Ian Campbell
2014-07-25 12:56 ` Simon Martin
2014-07-25 13:10 ` Ian Campbell
2014-07-25 13:21 ` Simon Martin
2014-07-25 13:37 ` Ian Campbell
2014-07-25 13:50 ` Andrew Cooper
2014-07-25 14:20 ` Simon Martin
2014-07-25 14:25 ` Andrew Cooper
2014-07-25 14:30 ` Simon Martin
2014-07-25 14:33 ` Ian Campbell
2014-07-25 14:36 ` Simon Martin
2014-07-25 14:28 ` Simon Martin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1103494739.20140725152817@gmail.com \
--to=furryfuttock@gmail.com \
--cc=Ian.Campbell@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).