I want to get mailing list submissions
Santosh
-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
xen-devel-request@xxxxxxxxxxxxxxxxxxx
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
xen-devel@xxxxxxxxxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel
or, via email, send a message with subject or body 'help' to
xen-devel-request@xxxxxxxxxxxxxxxxxxx
You can reach the person managing the list at
xen-devel-owner@xxxxxxxxxxxxxxxxxxx
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
only.
Best regards,
Kan
>All the SV stuff is heavily deprecated. I think it should disappear
soon.
>
>Cheers
>
>Tom
>
>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
>Xen-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel
------------------------------
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"
Hi,
This patch replaces tab with 4 whitespaces in xensec_gen/main.py.
Signed-off-by: Masaki Kanno <kanno.masaki@xxxxxxxxxxxxxx>
Best regards,
Kan
-------------- 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 :
http://lists.xensource.com/archives/html/xen-devel/attachments/20070326/
28cabd7a/remove_tabs_from_xensec_gen.obj
------------------------------
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
driverdomain
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:
>
>
/usr/src/xen/xen-unstable.hg/linux-2.6.18-xen/drivers/usb/class/usblp.c:
> 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
>workaround.
>
>USBLP_BUF_SIZE is used to "usb_buffer_alloc" (usb/core/usb.c) dma
memory:
>
>>From usb.c:
> usb_buffer_alloc - allocate dma-consistent buffer for
>URB_NO_xxx_DMA_MAP
>
>but here I'm out..
Probably you're just suffering from domains without any I/O memory
ranges
assigned not being permitted to have multi-page contiguous memory ranges
assigned? If not, do you force swiotlb on in the domain? And what
resources
does the USB HC require?
Jan
------------------------------
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
how
>to deal with a peripheral that requires large DMA buffers.
>
>All 'normal Linux' PCI DMA from Driver Domains (e.g. dom0) occurs via
the
>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?
Yes.
>If the kernel is modified by increasing IO_TLB_SIZE, will this allow
larger
>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
contiguous
>low hypervisor pages. The allocation size is limited by
MAX_CONTIG_ORDER = 9
>in xen_create_contiguous_region to 2^9 * 4k = 2MB?
Yes, though for very special cases (AGP aperture) extending this limit
is
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,
or
>is there a matching limitation in the hypervisor? I didn't see any
options
>to Xen to configure the amount of memory reserved for coherent DMA
mappings.
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
huge
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.
Jan
------------------------------
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
python
> 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
simple
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
itself
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
from
there.
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.
HTH,
Ewan.
------------------------------
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
End of Xen-devel Digest, Vol 25, Issue 217
******************************************
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home