Re: [Xen-staging] [xen-unstable] Clean up arch_get_xen_caps() to not use sprintf().

Re: [Xen-staging] [xen-unstable] Clean up arch_get_xen_caps() to not use sprintf().

[Alex Williamson]

On Tue, 2007-01-30 at 16:24 +0000, Xen staging patchbot-unstable wrote:
> diff -r bd69e83b65ea -r 9578ae319874 xen/arch/ia64/xen/xensetup.c
> --- a/xen/arch/ia64/xen/xensetup.c	Tue Jan 30 16:14:16 2007 +0000
> +++ b/xen/arch/ia64/xen/xensetup.c	Tue Jan 30 16:23:43 2007 +0000
> @@ -547,18 +547,19 @@ printk("num_online_cpus=%d, max_cpus=%d\
>  
>  void arch_get_xen_caps(xen_capabilities_info_t info)
>  {
> -    char *p=info;
>      int major = xen_major_version();
>      int minor = xen_minor_version();
> -
> -    p += snprintf(p,sizeof(info), "xen-%d.%d-ia64 ", major, minor);
> +    char s[32];
> +
> +    info[0] = '\0';
> +
> +    snprintf(s, sizeof(s), "xen-%d.%d-ia54 ", major, minor);
> +    safe_strcat(info, s);

   This doesn't work.  info is just a char* here, so the sizeof() in
safe_strcat() only cats the first 8 bytes (or 4 on x86_32 I suppose).
Thanks,

	Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.

Re: Re: [Xen-staging] [xen-unstable] Clean up arch_get_xen_caps() to not use sprintf().

[Alex Williamson]

On Tue, 2007-01-30 at 23:20 -0700, Alex Williamson wrote:
> On Tue, 2007-01-30 at 16:24 +0000, Xen staging patchbot-unstable wrote:
> > diff -r bd69e83b65ea -r 9578ae319874 xen/arch/ia64/xen/xensetup.c
> > --- a/xen/arch/ia64/xen/xensetup.c	Tue Jan 30 16:14:16 2007 +0000
> > +++ b/xen/arch/ia64/xen/xensetup.c	Tue Jan 30 16:23:43 2007 +0000
> > @@ -547,18 +547,19 @@ printk("num_online_cpus=%d, max_cpus=%d\
> >  
> >  void arch_get_xen_caps(xen_capabilities_info_t info)
> >  {
> > -    char *p=info;
> >      int major = xen_major_version();
> >      int minor = xen_minor_version();
> > -
> > -    p += snprintf(p,sizeof(info), "xen-%d.%d-ia64 ", major, minor);
> > +    char s[32];
> > +
> > +    info[0] = '\0';
> > +
> > +    snprintf(s, sizeof(s), "xen-%d.%d-ia54 ", major, minor);
> > +    safe_strcat(info, s);
> 
>    This doesn't work.  info is just a char* here, so the sizeof() in
> safe_strcat() only cats the first 8 bytes (or 4 on x86_32 I suppose).

   And there's a typo, ia64, not 54.  Thanks,

	Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.

about eventchannel

[tgh]

Hi
I try to understand the eventchannel part,
and I am confused by the differences of the physical IRQ line ,virtual
IRQ line and virtual IPI line

for a vm , what do the physical IRQ line and virtual IRQ line mean for?
Every vm has one or some vcpu ,then virtual IRQ line may be related with
one of these vcpu , then what is the physical IRQ line for?
I am really confused with it



could someone give me help
Thanks in advance

Re: Re: [Xen-staging] [xen-unstable] Clean up arch_get_xen_caps() to not use sprintf().

[Ian Campbell]

On Tue, 2007-01-30 at 23:31 -0700, Alex Williamson wrote:
> On Tue, 2007-01-30 at 23:20 -0700, Alex Williamson wrote:
> > On Tue, 2007-01-30 at 16:24 +0000, Xen staging patchbot-unstable wrote:
> > > diff -r bd69e83b65ea -r 9578ae319874 xen/arch/ia64/xen/xensetup.c
> > > --- a/xen/arch/ia64/xen/xensetup.c	Tue Jan 30 16:14:16 2007 +0000
> > > +++ b/xen/arch/ia64/xen/xensetup.c	Tue Jan 30 16:23:43 2007 +0000
> > > @@ -547,18 +547,19 @@ printk("num_online_cpus=%d, max_cpus=%d\
> > >  
> > >  void arch_get_xen_caps(xen_capabilities_info_t info)
> > >  {
> > > -    char *p=info;
> > >      int major = xen_major_version();
> > >      int minor = xen_minor_version();
> > > -
> > > -    p += snprintf(p,sizeof(info), "xen-%d.%d-ia64 ", major, minor);
> > > +    char s[32];
> > > +
> > > +    info[0] = '\0';
> > > +
> > > +    snprintf(s, sizeof(s), "xen-%d.%d-ia54 ", major, minor);
> > > +    safe_strcat(info, s);
> > 
> >    This doesn't work.  info is just a char* here, so the sizeof() in
> > safe_strcat() only cats the first 8 bytes (or 4 on x86_32 I suppose).
> 
>    And there's a typo, ia64, not 54.  Thanks,

Fixed both of these, thanks for the heads up.

Ian.

Re: about eventchannel

[Mark Williamson]

Hi,

> I try to understand the eventchannel part,
> and I am confused by the differences of the physical IRQ line ,virtual
> IRQ line and virtual IPI line

Physical IRQ lines correspond to actual IRQs from real hardware devices.  
Guests receive an event channel notification for a physical IRQ line if there 
is an interrupt generated by that device.

A virtual IRQ is something that is generated by Xen, e.g. the domain's timer 
interrupt.

The virtual IPI lines are interdomain event channels, allowing domains to 
notify each other (for instance to notify that there's data waiting for 
processing in a shared memory buffer).

Cheers,
Mark

> for a vm , what do the physical IRQ line and virtual IRQ line mean for?
> Every vm has one or some vcpu ,then virtual IRQ line may be related with
> one of these vcpu , then what is the physical IRQ line for?
> I am really confused with it
>
>
>
> could someone give me help
> Thanks in advance
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

RE: about eventchannel

[Tian, Kevin]

>From: Mark Williamson
>Sent: 2007年2月1日 4:48
>
>Hi,
>
>> I try to understand the eventchannel part,
>> and I am confused by the differences of the physical IRQ line ,virtual
>> IRQ line and virtual IPI line
>
>Physical IRQ lines correspond to actual IRQs from real hardware
>devices.
>Guests receive an event channel notification for a physical IRQ line if
>there
>is an interrupt generated by that device.
>
>A virtual IRQ is something that is generated by Xen, e.g. the domain's
>timer
>interrupt.
>
>The virtual IPI lines are interdomain event channels, allowing domains to
>notify each other (for instance to notify that there's data waiting for
>processing in a shared memory buffer).

I would say virtual IPI lines are inter-vcpu event channels within one 
domain, which just behaves like physical IPI. Then we can consider 
rest out of above 3 categories into inter-domain event ports. :-)

Thanks,
Kevin