[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] RE: Xen-devel Digest, Vol 25, Issue 217

I want to get mailing list submissions

-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
Sent: Monday, March 26, 2007 2:27 PM
To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Xen-devel Digest, Vol 25, Issue 217

Send Xen-devel mailing list submissions to

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to

You can reach the person managing the list at

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Xen-devel digest..."

Today's Topics:

   1. Re: [PATCH] [PATCH] Remove tabs from xm/main.py (Masaki Kanno)
   2. [PATCH] Remove tabs from xensec_gen/main.py (Masaki Kanno)
   3. Re: out of dma-memory when using usblp-module in  driverdomain
      (Jan Beulich)
   4. Re: PCI DMA Limitations (Jan Beulich)
   5. Re: question about reboot VM (Ewan Mellor)


Message: 1
Date: Mon, 26 Mar 2007 16:12:49 +0900
From: Masaki Kanno <kanno.masaki@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] [PATCH] Remove tabs from xm/main.py
To: Tom Wilkie <tw275@xxxxxxxxx>
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Ewan Mellor <ewan@xxxxxxxxxxxxx>
Message-ID: <E4C76F7629762Fkanno.masaki@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii

Hi Tom,

Thanks for your reply.  I'm going to remove tabs from xensec_gen/main.py


Best regards,

>All the SV stuff is heavily deprecated.  I think it should disappear
>On 23 Mar 2007, at 14:25, Masaki Kanno wrote:
>>> On Thu, Mar 22, 2007 at 11:01:18AM +0900, Masaki Kanno wrote:
>>> Content-Description: Mail message body
>>>> Hi,
>>>> I checked other python codes too. Because I found that many tabs
>>>> are included in some python codes, I send patches more.
>>>> Signed-off-by: Masaki Kanno <kanno.masaki@xxxxxxxxxxxxxx>
>>> Thanks for these.  I haven't taken the patch to the logging module, 
>>> because
>>> that's pristine upstream code, I believe.  I've applied all the rest

>>> though.
>> Hi Ewan,
>> Thanks for your reply.  I understood it about the logging module.
>> BTW, I know that many tabs are still included in the following files.
>> I am making patches to remove tabs from those files.  Are the files
>> which I should not fix included?
>>   tools/python/xen/sv/Main.py
>>   tools/python/xen/sv/Dominfo.py
>>   tools/python/xen/sv/CreateDomain.py
>>   tools/python/xen/sv/util.py
>>   tools/python/xen/sv/GenTabbed.py
>>   tools/python/xen/sv/NodeInfo.py
>>   tools/python/xen/sv/Wizard.py
>>   tools/security/python/xensec_gen/main.py
>> Best regards,
>>  Kan
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>Xen-devel mailing list


Message: 2
Date: Mon, 26 Mar 2007 16:20:31 +0900
From: Masaki Kanno <kanno.masaki@xxxxxxxxxxxxxx>
Subject: [Xen-devel] [PATCH] Remove tabs from xensec_gen/main.py
To: xen-devel@xxxxxxxxxxxxxxxxxxx
Message-ID: <E5C76F773CF4C9kanno.masaki@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-2022-jp"


This patch replaces tab with 4 whitespaces in xensec_gen/main.py.

Signed-off-by: Masaki Kanno <kanno.masaki@xxxxxxxxxxxxxx>

Best regards,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: remove_tabs_from_xensec_gen.patch
Type: application/octet-stream
Size: 9149 bytes
Desc: not available
Url :


Message: 3
Date: Mon, 26 Mar 2007 08:23:22 +0100
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] out of dma-memory when using usblp-module in
To: "Patrick Scharrenberg" <pittipatti@xxxxxx>
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Message-ID: <4607910A.76E4.0078.0@xxxxxxxxxx>
Content-Type: text/plain; charset=US-ASCII

>>> Patrick Scharrenberg <pittipatti@xxxxxx> 25.03.07 16:29 >>>
>I tried attaching an usb-printer to an usb-port of a driver-domain.
>On loading the module usblp I get the following error:
>    out of memory for write buf
>    usblp: probe of 2-1:1.0 failed with error -5
>I figured out, that reducing USBLP_BUF_SIZE (usb/class/usblp.c) form
>8192 to some smaller value, e.g. 4096 it works fine, but that's just a
>USBLP_BUF_SIZE is used to "usb_buffer_alloc" (usb/core/usb.c) dma
>>From usb.c:
>     usb_buffer_alloc - allocate dma-consistent buffer for
>but here I'm out..

Probably you're just suffering from domains without any I/O memory
assigned not being permitted to have multi-page contiguous memory ranges
assigned? If not, do you force swiotlb on in the domain? And what
does the USB HC require?



Message: 4
Date: Mon, 26 Mar 2007 08:42:34 +0100
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] PCI DMA Limitations
To: "Stephen Donnelly" <sfdonnelly@xxxxxxxxx>
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Message-ID: <4607958A.76E4.0078.0@xxxxxxxxxx>
Content-Type: text/plain; charset=US-ASCII

>>> "Stephen Donnelly" <sfdonnelly@xxxxxxxxx> 26.03.07 05:35 >>>
>I've been reading the XenLinux code from 3.0.4 and would appreciate
>clarification of the limitations on PCI DMA under Xen. I'm considering
>to deal with a peripheral that requires large DMA buffers.
>All 'normal Linux' PCI DMA from Driver Domains (e.g. dom0) occurs via
>SWIOTLB code via a restricted window. e.g. when booting:
>Software IO TLB enabled:
> Aperture:     64 megabytes
> Kernel range: 0xffff880006ea2000 - 0xffff88000aea2000
> Address size: 30 bits
>PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
>The size of the aperture is configurable when the XenLinux kernel
boots. The
>maximum streaming DMA allocation (via dma_map_single) is is limited by
>IO_TLB_SIZE to 128 slabs  * 4k = 512kB. Synchronisation is explicit via
>dma_sync_single and involves the CPU copying pages via these 'bounce
>buffers'. Is this correct?


>If the kernel is modified by increasing IO_TLB_SIZE, will this allow
>mappings, or is there a matching limitation in the hypervisor?

Not a siginficant one in the hypervisor: 4Gb chunks/2**20 pages (and of
course being bound to available memory in the requested range). But the
setup here is also going through xen_create_contiguous_region(), so the
2Mb limitation there would also apply.

>Coherent mappings via dma_alloc_coherent exchange VM pages for
>low hypervisor pages. The allocation size is limited by
>in xen_create_contiguous_region to 2^9 * 4k = 2MB?

Yes, though for very special cases (AGP aperture) extending this limit
being considered, though not likely by just bumping MAX_CONTIG_ORDER
(due to the effect this would have on static variables' sizes).

>Is it possible to increase MAX_CONTIG_ORDER in a guest OS unilaterally,
>is there a matching limitation in the hypervisor? I didn't see any
>to Xen to configure the amount of memory reserved for coherent DMA

Again, Xen doesn't limit the order significantly, and statically bumping
MAX_CONTIG_ORDER doesn't seem like too good an idea.
Xen can reserve memory for DMA purposes via the dma_emergency_pool
command line option.

>Is there a simpler/more direct way to provide DMA access to large
buffers in
>guest VMs? I was curious about how RDMA cards (e.g. Infiniband) are
>supported, are they required to use DAC and scatter-gather in some way?

Yes, s/g is certainly very much preferable here, due to the possibly
amounts of data otherwise needing copying. Also, RDMA is (hopefully) not
restricted to 32-bit machine addresses, as that would be another reason
to force it though the swiotlb.



Message: 5
Date: Mon, 26 Mar 2007 09:43:26 +0100
From: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] question about reboot VM
To: tgh <tianguanhua@xxxxxxxxxx>
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Message-ID: <20070326084326.GA24877@xxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii

On Mon, Mar 26, 2007 at 02:12:33PM +0800, tgh wrote:

> hi
> I try to understand the"xm reboot" for vm, but confused about the
> code
> I could not find which function or code in C language is called by the
> python when rebooting

At the client (xm) the code is in xen/xm/shutdown.py.  This just sends
messages to Xend (the server).  In Xend there is some marshalling, but
eventually the call pops out in xen/xend/XendDomainInfo.py:shutdown,
with the
reason set to "reboot".  This makes a request to the domain to shut
down, and the shutdown the proceeds asynchronously.

When the domain finally shuts down, a watch is fired which comes into
XendDomainInfo.refreshShutdown, and Xend handles the cleanup and reboot

There is no C code explicitly about rebooting -- this is handled by Xend
as a
cleanup of one domain, and creation of a new one in its place.




Xen-devel mailing list

End of Xen-devel Digest, Vol 25, Issue 217

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.