On Tue, Sep 22, 2009 at 05:51:02PM +0200, Jiri Denemark wrote:
> > > I'm not 100% sure we should represent CPU features as
> > > NAME
> > > especially because some features are currently advertised as .
> > > However,
> > > extending XML schema every time a new feature is introduced doesn't look
> > I'm not 100% sure we should represent CPU features as
> > NAME
> > especially because some features are currently advertised as .
> > However,
> > extending XML schema every time a new feature is introduced doesn't look
> > like
> > a good idea at all. The problem is we can't get rid of -sty
On Tue, Sep 22, 2009 at 03:01:18PM +0100, Daniel P. Berrange wrote:
> On Tue, Sep 22, 2009 at 03:52:08PM +0200, Daniel Veillard wrote:
> > On Tue, Sep 22, 2009 at 02:25:54PM +0100, Daniel P. Berrange wrote:
> > > No, we should't rely on /proc/cpuinfo because that is Linux specific.
> > > For Xen an
On Tue, Sep 22, 2009 at 03:52:08PM +0200, Daniel Veillard wrote:
> On Tue, Sep 22, 2009 at 02:25:54PM +0100, Daniel P. Berrange wrote:
> > No, we should't rely on /proc/cpuinfo because that is Linux specific.
> > For Xen and VMWare drivers we want a naming scheme for flags that is
> > OS agnostic,
On Tue, Sep 22, 2009 at 02:25:54PM +0100, Daniel P. Berrange wrote:
> On Tue, Sep 22, 2009 at 02:41:08PM +0200, Daniel Veillard wrote:
> > IMHO the worst is that the definition of the names.
> > First there is gonna be a bunch of them and second their name if you
> > rely just on the procinfo out
On Tue, Sep 22, 2009 at 02:41:08PM +0200, Daniel Veillard wrote:
> > I'm not 100% sure we should represent CPU features as
> > NAME
> > especially because some features are currently advertised as .
> > However,
> > extending XML schema every time a new feature is introduced doesn't look
> > lik
[ Sending again as my mail from yesterday seems to not have gone out :-( ]
On Fri, Sep 04, 2009 at 04:58:25PM +0200, Jiri Denemark wrote:
> Hi,
>
> This is an attempt to provide similar flexibility to CPU ID masking without
> being x86-specific and unfriendly to users. As suggested by Dan, we nee
On Fri, Sep 04, 2009 at 04:58:25PM +0200, Jiri Denemark wrote:
> Firstly, CPU topology and all (actually all that libvirt knows about) CPU
> features have to be advertised in host capabilities:
>
>
>
> ...
>
> NAME
>
>
> > I'm not sure how to deal with named CPUs suggested by Dan. Either we need
> > to come up with global set of named CPUs and document what they mean or
> > let drivers specify their own named CPUs and advertise them through guest
> > capabilities:
> >
> > ...
> >
> >
> From: libvir-list-boun...@redhat.com [mailto:libvir-list-
> Hi,
>
> This is an attempt to provide similar flexibility to CPU ID masking
> without
> being x86-specific and unfriendly to users. As suggested by Dan, we need
a
> way
> to specify both CPU flags and topology to achieve this goal.
>
>
10 matches
Mail list logo