From: Gerd Knorr <kraxel@suse.de>
To: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com, Scott Parish <srparish@us.ibm.com>
Subject: Re: Xen 3.0 Status update
Date: Fri, 29 Jul 2005 14:58:07 +0200 [thread overview]
Message-ID: <20050729125807.GA4327@bytesex> (raw)
In-Reply-To: <A95E2296287EAD4EB592B5DEEFCE0E9D282845@liverpoolst.ad.cl.cam.ac.uk>
> However, for the long-lived control regions used by some devices (e.g.
> for descriptor rings etc) it probably makes sense to try and allocate
> them in memory they can access directly. Some of these have daft
> restrictions, such as the aacraid device only being able to use memory
> below 2GB for its control program.
> Most of these regions are bigger than a page so have to be created with
> dma_alloc_coherent, hence we have an opportunity to allocate them in a
> region they can directly access.
Yep, for the control structures it should be easy to sort as
dma_alloc_coherent() must be used for them
(Documentation/DMA-mapping.txt is pretty clear here) and so we
have a opportunity to hook in and make sure it's DMA-able
memory.
Linux device drivers can pass a address mask telling the kernel
which range the device in question can handle
(pci_set_dma_mask), it's probably a good idea to pass that down
to xen. That should catch corner cases like the 2G limit on
some raid controller mentioned here recently without extra work
I think.
Gerd
--
panic("it works"); /* avoid being flooded with debug messages */
next prev parent reply other threads:[~2005-07-29 12:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-29 11:16 Xen 3.0 Status update Ian Pratt
2005-07-29 12:58 ` Gerd Knorr [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-07-28 23:31 Ian Pratt
2005-07-28 23:05 Ian Pratt
2005-07-28 21:59 ` Scott Parish
2005-07-29 9:06 ` Gerd Knorr
2005-07-29 10:17 ` Keir Fraser
2005-07-28 22:39 Ian Pratt
2005-07-28 21:43 ` Scott Parish
2005-07-28 22:57 ` Mark Williamson
2005-07-28 21:55 ` Scott Parish
2005-07-28 21:35 Ian Pratt
2005-07-28 20:30 ` Scott Parish
2005-07-28 21:15 Ian Pratt
2005-07-28 20:09 ` Scott Parish
2005-07-28 21:01 Walker, Bruce J (HP-Labs)
2005-07-28 11:52 Ian Pratt
2005-07-29 2:30 ` aq
2005-07-27 23:34 Ian Pratt
2005-07-28 4:28 ` aq
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=20050729125807.GA4327@bytesex \
--to=kraxel@suse.de \
--cc=m+Ian.Pratt@cl.cam.ac.uk \
--cc=srparish@us.ibm.com \
--cc=xen-devel@lists.xensource.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.