Xen devel - Dec 2005 - Uses of &frame_table[xfn]

There are a number of explicit uses of &frame_table[...]
remaining in Xen common code (grant_table.c and memory.c).
Could these be cleaned up to use pfn_to_page(...)?  Eventually,
I''d imagine all uses in Xen/x86 should eventually be changed
as well, but this would be a good start.  (And, yes, there
are some in ia64-specific code that I''ll be changing too.)

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> There are a number of explicit uses of &frame_table[...] 
> remaining in Xen common code (grant_table.c and memory.c).
> Could these be cleaned up to use pfn_to_page(...)?  
Yes, this is highly desirable. We''ll need it for making the frame_table
virtually mapped to support discontig memory.
> Eventually, I''d imagine all uses in Xen/x86 should eventually 
> be changed as well, but this would be a good start.  (And, 
> yes, there are some in ia64-specific code that I''ll be changing
too.)
Please can someone *carefully* work up a patch and test it.

Ian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

I see that Keir fixed all of these.  Thanks!

The balloon driver in xenlinux was also fixed, but I think
this is a syntactic but not a semantic fix.  In balloon_init,
an assumption is made that all pages below xen_start_info->nr_pages
are valid RAM.  What if all pages of valid RAM are above
nr_pages?  Then (I think) the balloon driver will eat up
all the domain''s RAM.  (Unlikely, but you get the drift.)

Or perhaps this assumption is always true on xenlinux/x86
(including PAE and x86_64 and later with VIRTUAL_MEM_MAP)?

I''m still working out what this should be on ia64, but the
current code definitely won''t work.  Is it just trying to
allocate N pages where N = max_reservation - initial_reservation?
If so, why not just call alloc_page N times?  If this works,
it is probably shareable with ia64, else perhaps we will
need an arch_balloon_init() (and an asm/balloon.h) otherwise...

On a related note, I''m not clear on the relationship between
the "memory" variable in xmdefconfig and the two reservation
variables needed for ballooning (not sure what they are named,
but call them max_reservation and initial_reservation).  Which
of these latter correspond to "memory" in xmdefconfig and how
does the other get determined?

Thanks,
Dan

> -----Original Message-----
> From: Ian Pratt [mailto:m+Ian.Pratt@cl.cam.ac.uk] 
> Sent: Sunday, December 18, 2005 9:24 PM
> To: Magenheimer, Dan (HP Labs Fort Collins); Xen Mailing List
> Cc: ian.pratt@cl.cam.ac.uk
> Subject: RE: [Xen-devel] Uses of &frame_table[xfn]
> 
> > There are a number of explicit uses of &frame_table[...] 
> > remaining in Xen common code (grant_table.c and memory.c).
> > Could these be cleaned up to use pfn_to_page(...)?  
> 
> Yes, this is highly desirable. We''ll need it for making the 
> frame_table
> virtually mapped to support discontig memory.
> 
> > Eventually, I''d imagine all uses in Xen/x86 should eventually
> > be changed as well, but this would be a good start.  (And, 
> > yes, there are some in ia64-specific code that I''ll be 
> changing too.)
> 
> Please can someone *carefully* work up a patch and test it.
> 
> Ian
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, Dec 22, 2005 at 03:29:18PM -0800, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
> On a related note, I''m not clear on the relationship between
> the "memory" variable in xmdefconfig and the two reservation
> variables needed for ballooning (not sure what they are named,
> but call them max_reservation and initial_reservation).  Which
> of these latter correspond to "memory" in xmdefconfig and how
> does the other get determined?
For unprivileged guests, Xend sets both the maximum and current reservation to
the configured "memory" value, when a domain is created.  Subsequent
calls to
xm mem-set set the current reservation, and leave the maximum alone.  Calls to
xm mem-max set the maximum (and reducing the maximum without thought is a good
way to crash your guest).

For dom0, the initial values are set from the kernel command line, and the
current reservation is altered if memory is needed for domain creation,
migration, etc.

Ewan.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 22 Dec 2005, at 23:29, Magenheimer, Dan (HP Labs Fort Collins) wrote:
> The balloon driver in xenlinux was also fixed, but I think
> this is a syntactic but not a semantic fix.  In balloon_init,
> an assumption is made that all pages below xen_start_info->nr_pages
> are valid RAM.  What if all pages of valid RAM are above
> nr_pages?  Then (I think) the balloon driver will eat up
> all the domain''s RAM.  (Unlikely, but you get the drift.)
The assumption is that you are initially allocated contiguous RAM from 
pseudophys page frame 0 up to pseudophys page frame nr_pages-1.

A further assumption is that, if the max_pfn is larger than nr_pages, 
the physical space between nr_pages and max_pfn is not (yet) populated 
with RAM. Thus those pages properly belong to the balloon driver.

Are these assumptions not workable on ia64?

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > On a related note, I''m not clear on the relationship between
> > the "memory" variable in xmdefconfig and the two reservation
> > variables needed for ballooning (not sure what they are named,
> > but call them max_reservation and initial_reservation).  Which
> > of these latter correspond to "memory" in xmdefconfig and
how
> > does the other get determined?
> 
> For unprivileged guests, Xend sets both the maximum and 
> current reservation to
> the configured "memory" value, when a domain is created.  
> Subsequent calls to
> xm mem-set set the current reservation, and leave the maximum 
> alone.  Calls to
> xm mem-max set the maximum (and reducing the maximum without 
> thought is a good
> way to crash your guest).
> 
> For dom0, the initial values are set from the kernel command 
> line, and the
> current reservation is altered if memory is needed for domain 
> creation,
> migration, etc.
Thanks for the reply.  This is starting to make sense.

With the balloon driver still unimplemented, I have seen
messages (from xend?) that /proc/xen/balloon can''t be
opened.  This occurs when I try to create a domain such that
the sum of memory of all launched domains (including dom0)
exceeds the total machine memory on the machine.

So when I get this message, is xend trying to balloon memory
from dom0?  Or is this the point where xend(?) tries
to do the xm mem-set to balloon some memory away from a
domU (and, if so, how does it decide which one(s) to steal
memory from)?

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > The balloon driver in xenlinux was also fixed, but I think
> > this is a syntactic but not a semantic fix.  In balloon_init,
> > an assumption is made that all pages below xen_start_info->nr_pages
> > are valid RAM.  What if all pages of valid RAM are above
> > nr_pages?  Then (I think) the balloon driver will eat up
> > all the domain''s RAM.  (Unlikely, but you get the drift.)
> 
> The assumption is that you are initially allocated contiguous 
> RAM from 
> pseudophys page frame 0 up to pseudophys page frame nr_pages-1.
> A further assumption is that, if the max_pfn is larger than nr_pages, 
> the physical space between nr_pages and max_pfn is not (yet) 
> populated 
> with RAM. Thus those pages properly belong to the balloon driver.
> 
> Are these assumptions not workable on ia64?
Ah, I see.  For unprivileged domains, this assumption is also valid
on ia64 (though from Ewan''s reply, I gather this is is a no-op
for unprivileged domains because max_pfn==nr_pages at launch?).

Dom0 is different on ia64 because it is direct-mapped
(physical == machine).  The machine memory map
(aka EFI memory map) on ia64 machines may be sparse
and full of holes.  In particular, dom0 on ia64 currently
starts at machine memory 256M.  I''m fairly sure the
PageReserved check will avoid ballooning any of the holes,
but the assumption of linear counting from zero would result in
an incorrect total.  (On top of that, the plumbing for
start_info->nr_pages is currently broken on ia64 as it
is set to zero :-)
> the physical space between nr_pages and max_pfn is not (yet) 
> populated with RAM
How do you manage that? Does "not populated" mean there is no
struct page for them?  Will a get_free_page work on them?
We just tracked down a horrific problem involving missing
dom0 struct pages on Xen/ia64 so I want to make sure I understand
this and get it right.

If there is a struct page and the Linux allocator can handle
the pages, my previous suggestion of replacing the code with
alloc''ing N pages should work for both (x86 and ia64).  If not,
how do you feel about replacing that memory initialization
stanza with a call to arch_balloon_init (and creating a new
asm/balloon.h file)?

Thanks,
Dan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 23 Dec 2005, at 13:28, Magenheimer, Dan (HP Labs Fort Collins) wrote:
> Ah, I see.  For unprivileged domains, this assumption is also valid
> on ia64 (though from Ewan''s reply, I gather this is is a no-op
> for unprivileged domains because max_pfn==nr_pages at launch?).
Very early on in boot we increase max_pfn beyond nr_pages and allocate 
a suitably large mem_map so that there are struct page''s covering the 
whole space.
>> the physical space between nr_pages and max_pfn is not (yet)
>> populated with RAM
>
> How do you manage that? Does "not populated" mean there is no
> struct page for them?  Will a get_free_page work on them?
> We just tracked down a horrific problem involving missing
> dom0 struct pages on Xen/ia64 so I want to make sure I understand
> this and get it right.
Yeah, they have struct page, but there is no memory mapped at that 
kernel virtual address (the phys2mach entry points nowhere).
> If there is a struct page and the Linux allocator can handle
> the pages, my previous suggestion of replacing the code with
> alloc''ing N pages should work for both (x86 and ia64).  If not,
> how do you feel about replacing that memory initialization
> stanza with a call to arch_balloon_init (and creating a new
> asm/balloon.h file)?
Alloc''ing N pages would not guarantee to get exactly the pages we want 
(i.e., the ones with no RAM). The mem initialization as is does not 
look particularly x86 specific. Is the check for PageReserved a 
problem? If so, we can probably work around that -- it''s only used to 
skip over highmem pages in non-highmem i386 kernels.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, Dec 23, 2005 at 05:05:29AM -0800, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
> > > On a related note, I''m not clear on the relationship
between
> > > the "memory" variable in xmdefconfig and the two
reservation
> > > variables needed for ballooning (not sure what they are named,
> > > but call them max_reservation and initial_reservation).  Which
> > > of these latter correspond to "memory" in xmdefconfig
and how
> > > does the other get determined?
> > 
> > For unprivileged guests, Xend sets both the maximum and 
> > current reservation to
> > the configured "memory" value, when a domain is created.  
> > Subsequent calls to
> > xm mem-set set the current reservation, and leave the maximum 
> > alone.  Calls to
> > xm mem-max set the maximum (and reducing the maximum without 
> > thought is a good
> > way to crash your guest).
> > 
> > For dom0, the initial values are set from the kernel command 
> > line, and the
> > current reservation is altered if memory is needed for domain 
> > creation,
> > migration, etc.
> 
> Thanks for the reply.  This is starting to make sense.
> 
> With the balloon driver still unimplemented, I have seen
> messages (from xend?) that /proc/xen/balloon can''t be
> opened.  This occurs when I try to create a domain such that
> the sum of memory of all launched domains (including dom0)
> exceeds the total machine memory on the machine.
> 
> So when I get this message, is xend trying to balloon memory
> from dom0?  Or is this the point where xend(?) tries
> to do the xm mem-set to balloon some memory away from a
> domU (and, if so, how does it decide which one(s) to steal
> memory from)?
The first of those.  It will balloon dom0 down as far as is necessary, stopping 
at dom0-min-mem, as configured in /etc/xen/xend-config.sxp.  You should see
a message in /var/log/xend.log saying "Balloon: need X MB, free Y MB."
when it
does this, and it will try to balloon dom0 to release the difference.

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > Ah, I see.  For unprivileged domains, this assumption is also valid
> > on ia64 (though from Ewan''s reply, I gather this is is a
no-op
> > for unprivileged domains because max_pfn==nr_pages at launch?).
> 
> Very early on in boot we increase max_pfn beyond nr_pages and 
> allocate 
> a suitably large mem_map so that there are struct page''s covering
the
> whole space.
OK.  That is done on Xen/ia64 also but it is done in Xen
rather than by changing Xenlinux.  Where is the code in
Xenlinux/x86 that does this?  (It may be educational...)
 
> >> the physical space between nr_pages and max_pfn is not (yet)
> >> populated with RAM
> >
> > How do you manage that? Does "not populated" mean there is
no
> > struct page for them?  Will a get_free_page work on them?
> > We just tracked down a horrific problem involving missing
> > dom0 struct pages on Xen/ia64 so I want to make sure I understand
> > this and get it right.
> 
> Yeah, they have struct page, but there is no memory mapped at that 
> kernel virtual address (the phys2mach entry points nowhere).
Just to make sure I understand:  After domain0 starts and before
any other domains start, the balloon list contains the dom0 kernel
virtual address of all pages that _could_ be backed by RAM
in the future, but aren''t yet?  Then is the balloon list a
dom0-land representation of _all_ the pages in Xen''s domheap
or just a subset?  (I''m guessing the latter... Xen uses the
non-dom0 pages from the domheap to create new domains, but
if the domheap eventually runs dry, Xen sucks pages away from
dom0, correct?)
> > If there is a struct page and the Linux allocator can handle
> > the pages, my previous suggestion of replacing the code with
> > alloc''ing N pages should work for both (x86 and ia64).  If
not,
> > how do you feel about replacing that memory initialization
> > stanza with a call to arch_balloon_init (and creating a new
> > asm/balloon.h file)?
> 
> Alloc''ing N pages would not guarantee to get exactly the 
> pages we want 
> (i.e., the ones with no RAM). The mem initialization as is does not 
> look particularly x86 specific. Is the check for PageReserved a 
> problem? If so, we can probably work around that -- it''s only used
to
> skip over highmem pages in non-highmem i386 kernels.
No, I think PageReserved is also used in Linux/ia64 to mark pages
that are holes in the memmap, so that check is OK.  The problem
is that on ia64 it is NOT the case that all dom0 pages below
start_info->nr_pages "have RAM", e.g. some (perhaps most) of the
pages below nr_pages are PageReserved.  But some of them
may be PageReserved because they do not "have RAM" (meaning on
ia64 that there is a hole there) and some may be PageReserved
for other reasons (e.g. that''s where kernel text lives) so I
don''t think any kind of linear-page-walk algorithm
will work.

I expect that in the future you may not want to have this
linear-page-walk code in a driver anyway as it may become
subject to lots of CONFIG_WEIRD_MEMORY options on different
arch''s (maybe even x86-64?).

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>From: Magenheimer, Dan
>(HP Labs Fort Collins)
>Sent: 2005年12月24日 4:34
>>
>> Very early on in boot we increase max_pfn beyond nr_pages and
>> allocate
>> a suitably large mem_map so that there are struct page''s
covering the
>> whole space.
>
>OK.  That is done on Xen/ia64 also but it is done in Xen
>rather than by changing Xenlinux.  Where is the code in
>Xenlinux/x86 that does this?  (It may be educational...)
linux-2.6-xen-sparse/arch/xen/i386/kernel/setup.c for find_max_pfn, which
increases max_pfn to the point larger than machine frames allocated to domain
and thus reserve an area to balance requests from backend driver.
>>
>> Yeah, they have struct page, but there is no memory mapped at that
>> kernel virtual address (the phys2mach entry points nowhere).
>
>Just to make sure I understand:  After domain0 starts and before
>any other domains start, the balloon list contains the dom0 kernel
>virtual address of all pages that _could_ be backed by RAM
>in the future, but aren''t yet?  Then is the balloon list a
>dom0-land representation of _all_ the pages in Xen''s domheap
>or just a subset?  (I''m guessing the latter... Xen uses the
>non-dom0 pages from the domheap to create new domains, but
>if the domheap eventually runs dry, Xen sucks pages away from
>dom0, correct?)
Not exactly. In the start, the balloon list only contains the page structs of
frames between xen_start_info->nr_pages and max_pfn since they are nomap in
phys2mach table in the early init phase. Later balloon list will expand/shrink
based upon control panel request (if not enough free memory) and backend drivers
(free some driver pages), etc.

Further, it''s not Xen to suck pages directly from dom0, instead
it''s customer needing more machine frames to check and do the request.
>>
>> Alloc''ing N pages would not guarantee to get exactly the
>> pages we want
>> (i.e., the ones with no RAM). The mem initialization as is does not
>> look particularly x86 specific. Is the check for PageReserved a
>> problem? If so, we can probably work around that -- it''s only
used to
>> skip over highmem pages in non-highmem i386 kernels.
>
>No, I think PageReserved is also used in Linux/ia64 to mark pages
>that are holes in the memmap, so that check is OK.  The problem
>is that on ia64 it is NOT the case that all dom0 pages below
>start_info->nr_pages "have RAM", e.g. some (perhaps most) of
the
>pages below nr_pages are PageReserved.  But some of them
>may be PageReserved because they do not "have RAM" (meaning on
>ia64 that there is a hole there) and some may be PageReserved
>for other reasons (e.g. that''s where kernel text lives) so I
>don''t think any kind of linear-page-walk algorithm
>will work.
So one intuitive way is to borrow same phys2mach concept into ia64 xenlinux.
Though more times required in the start than simply workaround this balloon
specific problem, it can save much time to do more ugly hacks later when we want
share more code among architectures.

Actually I can''t come up easy way to do balloon for ia64 dom0, if
physical still EQUALS to machine by current model.

You may allocate N free pages from dom0''s free pool and append them to
balloon list. OK, now dom0 won''t use them anymore since
they''re allocated already. Next step immediately is to FREE them into
domain heap so that Xen can allocate them for new domain creation.

Then later all those N machine frames are allocated to new domain1, and thus
their ownership changed. Now problem comes out. When dom0 is under pressure for
memory, how can dom0 retrieves new machine frames back?

For current ia64 dom0, since it''s physical address is equal (thus
bound) to machine address, there''s no way for ia64 dom0 to ask those
ballooned frames back since they are still in use by domain1. Also it''s
difficult for ia64 dom0 to get new frames since new machine frames means new
physical frame which further means memory hotplug.

So we finally reach such a point, once balloon driver is on work upon current
model, ia64 dom0 can only see its free pages fewer and fewer, but no way (or
difficult) to get them back. Even when domain1 occupying those N machine frames
is destroyed later, we still need to change memory hypercall interface since
dom0 only wants exactly those N machine frames back instead of any other free
frames.

All such troubles come from no phys2mach mapping table within ia64 dom0! So Dan,
maybe it''s time to revise current ia64 xenlinux design to make life
easier. ;-)
>
>I expect that in the future you may not want to have this
>linear-page-walk code in a driver anyway as it may become
>subject to lots of CONFIG_WEIRD_MEMORY options on different
>arch''s (maybe even x86-64?).
>
>Thanks,
>Dan
>
X86-64 should be mostly same as x86 since they all have contiguous/linear
physical frames in xen world. Not sure whether larger memory will do any
difference there.

Thanks,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

So could you make the following changes (or would you accept
a patch) regarding sparse/.../balloon.c:

1) Replace the stanza in balloon.c:balloon_init() that
   "Initialise[s] the balloon with excess memory space"
   with a call to arch_balloon_init()
2) Create a new asm-xen/asm-{i386,x86_64}/balloon.h that
   #define''s arch_balloon_init() to the current code.

On a related note, what is the cleanest way from Linux to
determine if it is running as domain0 or not?

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Dec 28, 2005 at 02:16:21PM -0800, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
> On a related note, what is the cleanest way from Linux to
> determine if it is running as domain0 or not?
Various places check (xen_start_info->flags & SIF_INITDOMAIN).

Cheers,
Muli
-- 
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Thanks for your reply Kevin.   The explanation is helpful.
> All such troubles come from no phys2mach mapping table within 
> ia64 dom0! So Dan, maybe it''s time to revise current ia64 
> xenlinux design to make life easier. ;-)
This is an important question.  In my opinion, it may make
life easier to mimic the x86 memory management scheme.  But
I believe one of the roles of Xen/ia64 as the first non-x86
port is to identify code existing in Xen and Xenlinux that
is x86-specific and help to define a better architecture-
independent interface.  I think the whole concept of a
guest-visible phys2mach table is a necessary evil on x86
because the guest writes page tables that are walked by
hardware.  This is of questionable use on other architectures
(and even on x86 in full shadow mode?).

Since you raised the question, let''s pose it to the core
Xen team and other arch developers.  I''ll start a new thread...

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wednesday, December 28, 2005 2:24 PM,  Muli Ben-Yehuda <>
wrote:
> On Wed, Dec 28, 2005 at 02:16:21PM -0800, Magenheimer, Dan (HP Labs
> Fort Collins) wrote: 
> 
>> On a related note, what is the cleanest way from Linux to
>> determine if it is running as domain0 or not?
> 
> Various places check (xen_start_info->flags & SIF_INITDOMAIN).
You could also read your domid from xenstore or using libxenctrl.

But a better question, especially as we move forward with dom0
disagregation and privilege reduction, is what do you want to do based
on this information?

Joseph Cihula
(Linux) Software Security Architect
Open Source Technology Center
Intel Corp.

*** These opinions are not necessarily those of my employer ***

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> On Wednesday, December 28, 2005 2:24 PM,  Muli Ben-Yehuda <> wrote:
> > On Wed, Dec 28, 2005 at 02:16:21PM -0800, Magenheimer, Dan (HP Labs
> > Fort Collins) wrote: 
> > 
> >> On a related note, what is the cleanest way from Linux to
> >> determine if it is running as domain0 or not?
> > 
> > Various places check (xen_start_info->flags & SIF_INITDOMAIN).
Thanks Muli!
 
> You could also read your domid from xenstore or using libxenctrl.
> 
> But a better question, especially as we move forward with dom0
> disagregation and privilege reduction, is what do you want to do based
> on this information?
You are correct that I was asking the wrong question.
What I want to ask is:  How do I determine if this is
a domain that is running a backend driver and has access
to physical devices?  On Xen/ia64 right now, that is the
same question, but it will be different in the future.

Thanks,
Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, Dec 28, 2005 at 05:49:47PM -0800, Cihula, Joseph wrote:
> On Wednesday, December 28, 2005 2:24 PM,  Muli Ben-Yehuda <> wrote:
> > On Wed, Dec 28, 2005 at 02:16:21PM -0800, Magenheimer, Dan (HP Labs
> > Fort Collins) wrote: 
> > 
> >> On a related note, what is the cleanest way from Linux to
> >> determine if it is running as domain0 or not?
> > 
> > Various places check (xen_start_info->flags & SIF_INITDOMAIN).
> 
> You could also read your domid from xenstore or using libxenctrl.
As of Xen 3.0.0, there is a /proc/xen/capabilities node, that shows
"control_d" in domain 0, and nothing in an unprivileged guest.  This
is a
better solution for userspace than trying to read from the store.

In the future, this interface will no doubt be expanded to include appropriate
flags for driver domains, etc.  (For now, it is just using SIF_INITDOMAIN.)

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > But a better question, especially as we move forward with dom0
> > disagregation and privilege reduction, is what do you want to do based
> > on this information?
>
> You are correct that I was asking the wrong question.
> What I want to ask is:  How do I determine if this is
> a domain that is running a backend driver and has access
> to physical devices?  On Xen/ia64 right now, that is the
> same question, but it will be different in the future.
Well that''s an interesting question...

We used to also have SIF flags to tell domains if they were supposed to run a 
backend.  This was due to the way the control message protocol worked at the 
time, and is no longer necessary.  Now we just have SIF_INITDOMAIN
(you''re
dom0 - grab the console, etc!) and SIF_PRIVILEGED (you''re just
privileged).

In general, though, I''m not sure you''ll want / need to a flag
that says "this
is a driver domain".  Domains that have access to real physical devices
will
just see them on the bus when they probe - non driver domains just
won''t see
any physical devices.  Backend drivers, as always, will just plumb virtual 
devices through to other devices available in the system (which may just 
happen to be physical devices).

Basically, I''m saying that "driver domain" is not a special
capability from
the PoV of the guest.  Does this satisfy your query, or do you have something 
in mind that explicitly requires such a flag?

Cheers,
Mark

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel