Re: [zones-discuss] Q: is there a way to get a zoneid from kernel (not in user context)?

2010-05-28 Thread Frank Batschulat (Home)
On Fri, 28 May 2010 07:31:27 +0200, eiji@oracle.com wrote:

 I'm wondering if there is a way to get a zoneid from kernel even though
 it's not in user context. If it's possible, this is useful for us to
 activate an HCA port in the exclusive-IP zone at boot time.

 Here's the background info.

 Currently the IP path info is gotten when the driver is attached, then
 an HCA port can be ready for RDSv3, but this way is for the global zone,
 and it doesn't work well for the exclusive-IP zone because the driver cannot
 get the zoneid when it's attached (so far). After all, we have to wait until
 customers run a command for RDSv3 in the zone, but the port should be ready
 at boot time w/o any customers' actions. It'd be better off getting it
 in the driver attach, but I don't know if it's possible.

 If it's not possible to get a zoneid from kernel if it's not in user context,
 then is there any recommended method to get it at boot time? I'm thinking
 maybe by using SMF, we can invoke an appropriate command (like ifconfig) at
 boot time to activate HCAs in the exclusive-IP zones, but if there is a proper
 way for this kind of purpose, that'd be better.

for kernel consumers use:

#include sys/zone.h

473 extern zoneid_t getzoneid(void);

cheers

---
frankB

___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] Q: is there a way to get a zoneid from kernel (not in user context)?

2010-05-28 Thread eiji . ota
Hi Frank,

getzoneid() can return a correct value even if it's called in a taskq thread
(kernel context) and/or in an interrupt handler (interrupt context)?

Thanks,

-Eiji


  I'm wondering if there is a way to get a zoneid from kernel even though
  it's not in user context. If it's possible, this is useful for us to
  activate an HCA port in the exclusive-IP zone at boot time.
 
  Here's the background info.
 
  Currently the IP path info is gotten when the driver is attached, then
  an HCA port can be ready for RDSv3, but this way is for the global zone,
  and it doesn't work well for the exclusive-IP zone because the driver cannot
  get the zoneid when it's attached (so far). After all, we have to wait until
  customers run a command for RDSv3 in the zone, but the port should be ready
  at boot time w/o any customers' actions. It'd be better off getting it
  in the driver attach, but I don't know if it's possible.
 
  If it's not possible to get a zoneid from kernel if it's not in user 
  context,
  then is there any recommended method to get it at boot time? I'm thinking
  maybe by using SMF, we can invoke an appropriate command (like ifconfig) at
  boot time to activate HCAs in the exclusive-IP zones, but if there is a 
  proper
  way for this kind of purpose, that'd be better.
 
 for kernel consumers use:
 
 #include sys/zone.h
 
 473 extern zoneid_t getzoneid(void);
 
 cheers
 
 ---
 frankB
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] Q: is there a way to get a zoneid from kernel (not in user context)?

2010-05-28 Thread Frank Batschulat (Home)
On Fri, 28 May 2010 10:43:22 +0200, eiji@oracle.com wrote:

 Hi Frank,

 getzoneid() can return a correct value even if it's called in a taskq thread
 (kernel context) and/or in an interrupt handler (interrupt context)?

I suppose so, look its not doing anything earth shattering:

   2496 getzoneid(void)
   2497 {
   2498 return (curproc-p_zone-zone_id);
   2499 }

no locking involved, no allocations done, nothing considered
harmfull in an interrupt context or taskq thread.

only question is to what proc your taskq/interrupt thread will bind to.

p0 or zsched ? p0 will always deliver the GLOBAL_ZONEID (zone0)

 Thanks,

 -Eiji


  I'm wondering if there is a way to get a zoneid from kernel even though
  it's not in user context. If it's possible, this is useful for us to
  activate an HCA port in the exclusive-IP zone at boot time.
 
  Here's the background info.
 
  Currently the IP path info is gotten when the driver is attached, then
  an HCA port can be ready for RDSv3, but this way is for the global zone,
  and it doesn't work well for the exclusive-IP zone because the driver 
  cannot
  get the zoneid when it's attached (so far). After all, we have to wait 
  until
  customers run a command for RDSv3 in the zone, but the port should be ready
  at boot time w/o any customers' actions. It'd be better off getting it
  in the driver attach, but I don't know if it's possible.
 
  If it's not possible to get a zoneid from kernel if it's not in user 
  context,
  then is there any recommended method to get it at boot time? I'm thinking
  maybe by using SMF, we can invoke an appropriate command (like ifconfig) at
  boot time to activate HCAs in the exclusive-IP zones, but if there is a 
  proper
  way for this kind of purpose, that'd be better.

 for kernel consumers use:

 #include sys/zone.h

 473 extern zoneid_t getzoneid(void);

 cheers

 ---
 frankB
 



-- 
frankB

It is always possible to agglutinate multiple separate problems
into a single complex interdependent solution.
In most cases this is a bad idea.
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] Q: is there a way to get a zoneid from kernel (not in user context)?

2010-05-28 Thread James Carlson
On 05/28/10 04:57, Frank Batschulat (Home) wrote:
 On Fri, 28 May 2010 10:43:22 +0200, eiji@oracle.com wrote:
 
 Hi Frank,

 getzoneid() can return a correct value even if it's called in a taskq thread
 (kernel context) and/or in an interrupt handler (interrupt context)?
 
 I suppose so, look its not doing anything earth shattering:
 
2496 getzoneid(void)
2497 {
2498   return (curproc-p_zone-zone_id);
2499 }
 
 no locking involved, no allocations done, nothing considered
 harmfull in an interrupt context or taskq thread.
 
 only question is to what proc your taskq/interrupt thread will bind to.

It sounds like we might need more information about what the original
poster is attempting to do.

Interrupts themselves aren't features of non-global zones, so they're
not normally attributed to any particular zone.  In theory, if there
were devices dedicated to individual zones, you could use the device's
state structure to find the zoneid associated.

If you just use getzoneid() in that context, you'll get the zoneid of
the zone whose thread happens to be pinned down by the interrupt.  In
other words, it's an arbitrary and almost certainly wrong answer.

I think something's amiss if you're asking about zoneid outside the
context of direct system call processing.  The answers there vary quite
a bit.  For example, with STREAMS, the correct answer is to fetch the
cred_t attached to the dblk_t, and get the zoneid from the cred_t.

It's not unusual at all for interrupts and taskqs to do work on behalf
of many different zones, and for them to need to track this information
separately.

-- 
James Carlson 42.703N 71.076W carls...@workingcode.com
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] Q: is there a way to get a zoneid from kernel (not in user context)?

2010-05-28 Thread Frank Batschulat (Home)
On Fri, 28 May 2010 13:35:07 +0200, James Carlson carls...@workingcode.com 
wrote:

 On 05/28/10 04:57, Frank Batschulat (Home) wrote:
 On Fri, 28 May 2010 10:43:22 +0200, eiji@oracle.com wrote:

 getzoneid() can return a correct value even if it's called in a taskq thread
 (kernel context) and/or in an interrupt handler (interrupt context)?

 I suppose so, look its not doing anything earth shattering:

2496 getzoneid(void)
2497 {
2498  return (curproc-p_zone-zone_id);
2499 }

 no locking involved, no allocations done, nothing considered
 harmfull in an interrupt context or taskq thread.

 only question is to what proc your taskq/interrupt thread will bind to.

 It sounds like we might need more information about what the original
 poster is attempting to do.

 Interrupts themselves aren't features of non-global zones, so they're
 not normally attributed to any particular zone.  In theory, if there
 were devices dedicated to individual zones, you could use the device's
 state structure to find the zoneid associated.

 If you just use getzoneid() in that context, you'll get the zoneid of
 the zone whose thread happens to be pinned down by the interrupt.  In
 other words, it's an arbitrary and almost certainly wrong answer.

 I think something's amiss if you're asking about zoneid outside the
 context of direct system call processing.  The answers there vary quite
 a bit.  For example, with STREAMS, the correct answer is to fetch the
 cred_t attached to the dblk_t, and get the zoneid from the cred_t.

 It's not unusual at all for interrupts and taskqs to do work on behalf
 of many different zones, and for them to need to track this information
 separately.

yepp, my bad ! and of course interrupt threads are always bound to p0 when they
are created (- thread_create_intr())

---
frankB
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] Q: is there a way to get a zoneid from kernel (not in user context)?

2010-05-28 Thread Frank Batschulat (Home)
On Fri, 28 May 2010 13:35:07 +0200, James Carlson carls...@workingcode.com 
wrote:

 On 05/28/10 04:57, Frank Batschulat (Home) wrote:
 On Fri, 28 May 2010 10:43:22 +0200, eiji@oracle.com wrote:

 getzoneid() can return a correct value even if it's called in a taskq thread
 (kernel context) and/or in an interrupt handler (interrupt context)?

 I suppose so, look its not doing anything earth shattering:

2496 getzoneid(void)
2497 {
2498  return (curproc-p_zone-zone_id);
2499 }

 no locking involved, no allocations done, nothing considered
 harmfull in an interrupt context or taskq thread.

 only question is to what proc your taskq/interrupt thread will bind to.

and not only are interrupt threads bound to p0, taskq threads
created using taskq_create() are also bound to p0.

so for taskq that'd be only valid if you'd use taskq_create_proc()
with something not being p0.

---
frankB

___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] Q: is there a way to get a zoneid from kernel (not in user context)?

2010-05-28 Thread Edward Pilatowicz
more information is needed about your architecture and what your trying
to do.

first off, as has been pointed out, if your not in user context
getzoneid() isn't really that useful.

second, below you keep mentioning at boot time.  are you talking about
system boot time?  or zone boot time?  at system boot time, there are
never any zones on the system and the kernel has no knowledge about any
future zones.  adding an SMF service to tell IB about zones at this
point doesn't make any sense since that information could always change
when someone runs zonecfg(1m).  so your device should be able to attach
and initialize itself without any knowledge of what zone is going to be
using it.

the first time the kernel learns about a zone is when that zone is
brought into the ready state.  this is also the point at which a zoneid
is actually allocated for a zone.  once this is done, device and
resource allocation can happen for the zone.  so if there's special
setup that need to be done to associate IB devices with zones, this is
the point at which it should happen.  userland can tell the kernel which
IB devices should be bound to a zone, and those devices can do whatever
re-configuration is necessary.

ed

On Thu, May 27, 2010 at 10:31:27PM -0700, eiji@oracle.com wrote:
 Hi,

 I'm wondering if there is a way to get a zoneid from kernel even though
 it's not in user context. If it's possible, this is useful for us to
 activate an HCA port in the exclusive-IP zone at boot time.

 Here's the background info.

 Currently the IP path info is gotten when the driver is attached, then
 an HCA port can be ready for RDSv3, but this way is for the global zone,
 and it doesn't work well for the exclusive-IP zone because the driver cannot
 get the zoneid when it's attached (so far). After all, we have to wait until
 customers run a command for RDSv3 in the zone, but the port should be ready
 at boot time w/o any customers' actions. It'd be better off getting it
 in the driver attach, but I don't know if it's possible.

 If it's not possible to get a zoneid from kernel if it's not in user context,
 then is there any recommended method to get it at boot time? I'm thinking
 maybe by using SMF, we can invoke an appropriate command (like ifconfig) at
 boot time to activate HCAs in the exclusive-IP zones, but if there is a proper
 way for this kind of purpose, that'd be better.

 Thanks,

 -Eiji
 ___
 zones-discuss mailing list
 zones-discuss@opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] Q: is there a way to get a zoneid from kernel (not in user context)?

2010-05-28 Thread eiji . ota
Hi Ed,

Yes, I meant the system boot time since it'd be ideal the setup is complete
 w/o any customers' actions.

Sounds I should go back to the project w/ the info and talk about how to
deal with our issue. We might want to discuss it more with you offline then.

Thanks,

-Eiji


 more information is needed about your architecture and what your trying
 to do.
 
 first off, as has been pointed out, if your not in user context
 getzoneid() isn't really that useful.
 
 second, below you keep mentioning at boot time.  are you talking about
 system boot time?  or zone boot time?  at system boot time, there are
 never any zones on the system and the kernel has no knowledge about any
 future zones.  adding an SMF service to tell IB about zones at this
 point doesn't make any sense since that information could always change
 when someone runs zonecfg(1m).  so your device should be able to attach
 and initialize itself without any knowledge of what zone is going to be
 using it.
 
 the first time the kernel learns about a zone is when that zone is
 brought into the ready state.  this is also the point at which a zoneid
 is actually allocated for a zone.  once this is done, device and
 resource allocation can happen for the zone.  so if there's special
 setup that need to be done to associate IB devices with zones, this is
 the point at which it should happen.  userland can tell the kernel which
 IB devices should be bound to a zone, and those devices can do whatever
 re-configuration is necessary.
 
 ed
 
 On Thu, May 27, 2010 at 10:31:27PM -0700, eiji@oracle.com wrote:
  Hi,
 
  I'm wondering if there is a way to get a zoneid from kernel even though
  it's not in user context. If it's possible, this is useful for us to
  activate an HCA port in the exclusive-IP zone at boot time.
 
  Here's the background info.
 
  Currently the IP path info is gotten when the driver is attached, then
  an HCA port can be ready for RDSv3, but this way is for the global zone,
  and it doesn't work well for the exclusive-IP zone because the driver cannot
  get the zoneid when it's attached (so far). After all, we have to wait until
  customers run a command for RDSv3 in the zone, but the port should be ready
  at boot time w/o any customers' actions. It'd be better off getting it
  in the driver attach, but I don't know if it's possible.
 
  If it's not possible to get a zoneid from kernel if it's not in user 
  context,
  then is there any recommended method to get it at boot time? I'm thinking
  maybe by using SMF, we can invoke an appropriate command (like ifconfig) at
  boot time to activate HCAs in the exclusive-IP zones, but if there is a 
  proper
  way for this kind of purpose, that'd be better.
 
  Thanks,
 
  -Eiji
  ___
  zones-discuss mailing list
  zones-discuss@opensolaris.org
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] Q: is there a way to get a zoneid from kernel (not in user context)?

2010-05-28 Thread eiji . ota
Hi Frank,

Yes, it seems we might not get a correct zoneid in kernel or interrupt context
as you pointed out here. In our project, the listener should be initialized
at boot time hopefully before the userland processes start, but in practice
it seems hard according to others' e-mails including yours. Then we'd like to
consider a solution further anyway.

Thanks for answering my question.

-Eiji

  getzoneid() can return a correct value even if it's called in a taskq 
  thread
  (kernel context) and/or in an interrupt handler (interrupt context)?
 
  I suppose so, look its not doing anything earth shattering:
 
 2496 getzoneid(void)
 2497 {
 2498return (curproc-p_zone-zone_id);
 2499 }
 
  no locking involved, no allocations done, nothing considered
  harmfull in an interrupt context or taskq thread.
 
  only question is to what proc your taskq/interrupt thread will bind to.
 
 and not only are interrupt threads bound to p0, taskq threads
 created using taskq_create() are also bound to p0.
 
 so for taskq that'd be only valid if you'd use taskq_create_proc()
 with something not being p0.
 
 ---
 frankB
___
zones-discuss mailing list
zones-discuss@opensolaris.org