All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Yaozu (Eddie) Dong" <eddie.dong@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"ddutile@redhat.com" <ddutile@redhat.com>,
	"sheng@linux.intel.com" <sheng@linux.intel.com>
Subject: Re: [Xen-devel] [PATCH 02/12] early PV on HVM
Date: Tue, 8 Jun 2010 15:05:05 -0400	[thread overview]
Message-ID: <20100608190505.GA8560@phenom.dumpdata.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1006081714460.3401@kaball-desktop>

On Tue, Jun 08, 2010 at 05:25:52PM +0100, Stefano Stabellini wrote:
> On Tue, 8 Jun 2010, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jun 08, 2010 at 04:55:33PM +0100, Stefano Stabellini wrote:
> > > On Tue, 8 Jun 2010, Konrad Rzeszutek Wilk wrote:
> > > > > > > +	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
> > > > > > > +
> > > > > > > +	/* Don't do the full vcpu_info placement stuff until we have a
> > > > > > > +	   possible map and a non-dummy shared_info. */
> > > > > > 
> > > > > > Might want to mention where the full vpcu placement is done.
> > > > > 
> > > > > The comment is not accurate, we actually don't do any vcpu_info
> > > > > placement on hvm because it is not very useful there.
> > > > > Better just to remove the comment (I have done so in my tree).
> > > > > 
> > > > > > > +	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> > > > > > 
> > > > So.. what is the purpose of the per_cpu(xen_vcpu, 0) then?
> > > > 
> > > 
> > > the vcpu info placement memory area is stored in per_cpu(xen_vcpu_info, cpu);
> > > per_cpu(xen_vcpu, cpu) is just a pointer to that area if it is
> > > available, otherwise it points to the vcpu_info struct in the shared
> > > info page.
> > 
> > I was just wondering why are we doing this when you say:
> > " don't do any vcpu_info placement on hvm because it is not very useful there."
> > 
> > So if it is not useful, why do it?
> > 
> 
> I think Jeremy replied to your question better than me: we still need
> the vcpu_info stuff for the timer and event channels, but we don't need
> it to be at a specific address in kernel memory.

Ok, can you add that comment for the usage of the per_cpu(xen_vcpu,0)
and mention that this is bootstrap code - hence only starting at CPU 0.

WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Yaozu (Eddie) Dong" <eddie.dong@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"ddutile@redhat.com" <ddutile@redhat.com>,
	"sheng@linux.intel.com" <sheng@linux.intel.com>
Subject: Re: [PATCH 02/12] early PV on HVM
Date: Tue, 8 Jun 2010 15:05:05 -0400	[thread overview]
Message-ID: <20100608190505.GA8560@phenom.dumpdata.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1006081714460.3401@kaball-desktop>

On Tue, Jun 08, 2010 at 05:25:52PM +0100, Stefano Stabellini wrote:
> On Tue, 8 Jun 2010, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jun 08, 2010 at 04:55:33PM +0100, Stefano Stabellini wrote:
> > > On Tue, 8 Jun 2010, Konrad Rzeszutek Wilk wrote:
> > > > > > > +	HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
> > > > > > > +
> > > > > > > +	/* Don't do the full vcpu_info placement stuff until we have a
> > > > > > > +	   possible map and a non-dummy shared_info. */
> > > > > > 
> > > > > > Might want to mention where the full vpcu placement is done.
> > > > > 
> > > > > The comment is not accurate, we actually don't do any vcpu_info
> > > > > placement on hvm because it is not very useful there.
> > > > > Better just to remove the comment (I have done so in my tree).
> > > > > 
> > > > > > > +	per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
> > > > > > 
> > > > So.. what is the purpose of the per_cpu(xen_vcpu, 0) then?
> > > > 
> > > 
> > > the vcpu info placement memory area is stored in per_cpu(xen_vcpu_info, cpu);
> > > per_cpu(xen_vcpu, cpu) is just a pointer to that area if it is
> > > available, otherwise it points to the vcpu_info struct in the shared
> > > info page.
> > 
> > I was just wondering why are we doing this when you say:
> > " don't do any vcpu_info placement on hvm because it is not very useful there."
> > 
> > So if it is not useful, why do it?
> > 
> 
> I think Jeremy replied to your question better than me: we still need
> the vcpu_info stuff for the timer and event channels, but we don't need
> it to be at a specific address in kernel memory.

Ok, can you add that comment for the usage of the per_cpu(xen_vcpu,0)
and mention that this is bootstrap code - hence only starting at CPU 0.

  reply	other threads:[~2010-06-08 19:05 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-03 13:10 [PATCH 01/12] Add support for hvm_op stefano.stabellini
2010-06-03 13:10 ` stefano.stabellini
2010-06-03 13:10 ` [PATCH 02/12] early PV on HVM stefano.stabellini
2010-06-04 20:20   ` [Xen-devel] " Konrad Rzeszutek Wilk
2010-06-07 14:38     ` Stefano Stabellini
2010-06-08 13:46       ` Konrad Rzeszutek Wilk
2010-06-08 13:46         ` Konrad Rzeszutek Wilk
2010-06-08 15:55         ` [Xen-devel] " Stefano Stabellini
2010-06-08 16:12           ` Konrad Rzeszutek Wilk
2010-06-08 16:25             ` Stefano Stabellini
2010-06-08 16:25               ` Stefano Stabellini
2010-06-08 19:05               ` Konrad Rzeszutek Wilk [this message]
2010-06-08 19:05                 ` Konrad Rzeszutek Wilk
2010-06-10 13:36                 ` [Xen-devel] " Stefano Stabellini
2010-06-10 13:36                   ` Stefano Stabellini
2010-06-08 16:09         ` [Xen-devel] " Jeremy Fitzhardinge
2010-06-04 20:23   ` Konrad Rzeszutek Wilk
2010-06-07 14:39     ` Stefano Stabellini
2010-06-03 13:10 ` [PATCH 03/12] evtchn delivery " stefano.stabellini
2010-06-14 21:20   ` [Xen-devel] " Konrad Rzeszutek Wilk
2010-06-17 15:41     ` Stefano Stabellini
2010-06-17 17:38       ` Konrad Rzeszutek Wilk
2010-06-17 17:38         ` Konrad Rzeszutek Wilk
2010-06-17 17:40         ` [Xen-devel] " Stefano Stabellini
2010-06-03 13:10 ` [PATCH 04/12] Xen PCI platform device driver stefano.stabellini
2010-06-03 13:10 ` [PATCH 05/12] Add suspend\resume support for PV on HVM guests stefano.stabellini
2010-06-14 21:20   ` [Xen-devel] " Konrad Rzeszutek Wilk
2010-06-17 15:42     ` Stefano Stabellini
2010-06-03 13:10 ` [PATCH 06/12] Allow xen platform pci device to be compiled as a module stefano.stabellini
2010-06-14 21:20   ` [Xen-devel] " Konrad Rzeszutek Wilk
2010-06-14 21:20     ` Konrad Rzeszutek Wilk
2010-06-15 16:22     ` [Xen-devel] " Jeremy Fitzhardinge
2010-06-15 16:22       ` Jeremy Fitzhardinge
2010-06-17 15:42       ` [Xen-devel] " Stefano Stabellini
2010-06-03 13:10 ` [PATCH 07/12] Fix find_unbound_irq in presence of ioapic irqs stefano.stabellini
2010-06-03 13:10 ` [PATCH 08/12] Fix possible NULL pointer dereference in print_IO_APIC stefano.stabellini
2010-06-03 13:10 ` [PATCH 09/12] __setup_vector_irq: handle NULL chip_data stefano.stabellini
2010-06-03 13:10 ` [PATCH 10/12] Do not try to disable hpet if it hasn't been initialized before stefano.stabellini
2010-06-03 13:10 ` [PATCH 11/12] Use xen_vcpuop_clockevent, xen_clocksource and xen wallclock stefano.stabellini
2010-06-03 13:10 ` [PATCH 12/12] Unplug emulated disks and nics stefano.stabellini
2010-06-14 21:20   ` [Xen-devel] " Konrad Rzeszutek Wilk
2010-06-17 15:42     ` Stefano Stabellini
2010-06-17 17:46       ` Konrad Rzeszutek Wilk
2010-06-17 17:46         ` Konrad Rzeszutek Wilk
2010-06-17 18:00         ` [Xen-devel] " Stefano Stabellini
2010-06-17 23:35       ` Jeremy Fitzhardinge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100608190505.GA8560@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=ddutile@redhat.com \
    --cc=eddie.dong@intel.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sheng@linux.intel.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.