Jeremy Fitzhardinge wrote:
> H. Peter Anvin wrote:
>> And you're absolutely right that the guest may end up picking and
>> choosing different parts of the interfaces. That's how it is supposed
>> to work.
>
> No, that would be a horrible, horrible mistake. There's no sane way to
> implement
H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
>>>
>>> The big difference here is that you could create a VM at runtime (by
>>> combining the existing interfaces) that did not exist before (or was
>>> not tested before). For example, a hypervisor could show hyper-v,
>>> osx-v (if any), linux
Jeremy Fitzhardinge wrote:
>>
>> The big difference here is that you could create a VM at runtime (by
>> combining the existing interfaces) that did not exist before (or was
>> not tested before). For example, a hypervisor could show hyper-v,
>> osx-v (if any), linux-v, etc., and a guest could c
H. Peter Anvin wrote:
> And you're absolutely right that the guest may end up picking and
> choosing different parts of the interfaces. That's how it is supposed
> to work.
No, that would be a horrible, horrible mistake. There's no sane way to
implement that; it would mean that the hyperviso
Nakajima, Jun wrote:
> On 10/3/2008 5:35:39 PM, H. Peter Anvin wrote:
>
>> Nakajima, Jun wrote:
>>
>>> What's the significance of supporting multiple interfaces to the
>>> same guest simultaneously, i.e. _runtime_? We don't want the guests
>>> to run on such a literarily Frankenstein machin
Nakajima, Jun wrote:
> On 10/3/2008 5:35:39 PM, H. Peter Anvin wrote:
>> Nakajima, Jun wrote:
>>> What's the significance of supporting multiple interfaces to the
>>> same guest simultaneously, i.e. _runtime_? We don't want the guests
>>> to run on such a literarily Frankenstein machine. And practi
On 10/3/2008 5:35:39 PM, H. Peter Anvin wrote:
> Nakajima, Jun wrote:
> >
> > What's the significance of supporting multiple interfaces to the
> > same guest simultaneously, i.e. _runtime_? We don't want the guests
> > to run on such a literarily Frankenstein machine. And practically,
> > such test
Nakajima, Jun wrote:
> What's the significance of supporting multiple interfaces to the same guest
> simultaneously, i.e. _runtime_? We don't want the guests to run on such a
> literarily Frankenstein machine. And practically, such testing/debugging
> would be good only for Halloween :-).
>
>
Nakajima, Jun wrote:
>
> What I mean is that a hypervisor (with a single vender id) can support
> multiple interfaces, exposing a single interface to each guest that would
> expect a specific interface at runtime.
>
Yes, and for the reasons outlined in a previous post in this thread,
this is
On 10/3/2008 4:30:29 PM, H. Peter Anvin wrote:
> Nakajima, Jun wrote:
> > What it means their hypervisor returns the interface signature (i.e.
> > "Hv#1"), and that defines the interface. If we use "Lv_1", for
> > example, we can define the interface 0x4002 through 0x40FF for
> > Linux.
>
Nakajima, Jun wrote:
> What it means their hypervisor returns the interface signature (i.e. "Hv#1"),
> and that defines the interface. If we use "Lv_1", for example, we can define
> the interface 0x4002 through 0x40FF for Linux. Since leaf 0x4000
> and 0x4001 are separate, we can
On 10/1/2008 6:24:26 PM, H. Peter Anvin wrote:
> Nakajima, Jun wrote:
> > >
> > > All I have seen out of Microsoft only covers CPUID levels
> > > 0x4000 as an vendor identification leaf and 0x4001 as a
> > > "hypervisor identification leaf", but you might have access to other
> > > informa
H. Peter Anvin wrote:
>
> Ah, if it was only that simple. Transmeta actually did this, but it's
> not as useful as you think.
>
For what it's worth, Transmeta's implementation used CPUID leaf
0x80860001.ECX to give the TSC frequency rounded to the nearest MHz.
The caveat of spread-spectrum m
Chris Wright wrote:
> * Anthony Liguori ([EMAIL PROTECTED]) wrote:
>
>> And arguably, storing TSC frequency in CPUID is a terrible interface
>> because the TSC frequency can change any time a guest is entered. It
>>
>
> True for older hardware, newer hardware should fix this. I guess
Nakajima, Jun wrote:
>>
>> All I have seen out of Microsoft only covers CPUID levels 0x4000
>> as an vendor identification leaf and 0x4001 as a "hypervisor
>> identification leaf", but you might have access to other information.
>
> No, it says "Leaf 0x4001 as hypervisor vendor-neutral
Zachary Amsden wrote:
>
> I'm not suggesting using the nominal value. I'm suggesting the
> measurement be done in the one and only place where there is perfect
> control of the system, the processor boot-strapping in the BIOS.
>
> Only the platform designers themselves know the speed of the osci
On Wed, 2008-10-01 at 17:39 -0700, H. Peter Anvin wrote:
> third, which is subject to spread-spectrum modulation due to RFI
> concerns. Therefore, relying on the *nominal* frequency of this clock
I'm not suggesting using the nominal value. I'm suggesting the
measurement be done in the one and on
On 10/1/2008 3:46:45 PM, H. Peter Anvin wrote:
> Alok Kataria wrote:
> > > No, that's always a terrible idea. Sure, its necessary to deal
> > > with some backward-compatibility issues, but we should even
> > > consider a new interface which assumes this kind of thing. We
> > > want properly enume
Zachary Amsden wrote:
>
> Jun, you work at Intel. Can you ask for a new architecturally defined
> MSR that returns the TSC frequency? Not a virtualization specific MSR.
> A real MSR that would exist on physical processors. The TSC started as
> an MSR anyway. There should be another MSR that te
Zachary Amsden wrote:
> On Wed, 2008-10-01 at 14:34 -0700, Anthony Liguori wrote:
>
>> Jeremy Fitzhardinge wrote:
>>
>>> Alok Kataria wrote:
>>>
>>> I guess, but the bulk of the uses of this stuff are going to be
>>> hypervisor-specific. You're hard-pressed to come up with any other
>>> ge
On Wed, 2008-10-01 at 14:34 -0700, Anthony Liguori wrote:
> Jeremy Fitzhardinge wrote:
> > Alok Kataria wrote:
> >
> > I guess, but the bulk of the uses of this stuff are going to be
> > hypervisor-specific. You're hard-pressed to come up with any other
> > generic uses beyond tsc.
>
> And arguab
Alok Kataria wrote:
>> No, that's always a terrible idea. Sure, its necessary to deal with
>> some backward-compatibility issues, but we should even consider a new
>> interface which assumes this kind of thing. We want properly enumerable
>> interfaces.
>
> The reason we still have to do this is
Chris Wright wrote:
> * Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
>> "What hypervisor is this?" isn't a very interesting question; if you're
>> even asking it then it suggests that something has gone wrong.
>
> It's essentially already happening. Everyone wants to be a better
> hyperv than
* Anthony Liguori ([EMAIL PROTECTED]) wrote:
> And arguably, storing TSC frequency in CPUID is a terrible interface
> because the TSC frequency can change any time a guest is entered. It
True for older hardware, newer hardware should fix this. I guess the
point is, the are numbers that are e
Jeremy Fitzhardinge wrote:
> Alok Kataria wrote:
>
> I guess, but the bulk of the uses of this stuff are going to be
> hypervisor-specific. You're hard-pressed to come up with any other
> generic uses beyond tsc.
And arguably, storing TSC frequency in CPUID is a terrible interface
because the
Chris Wright wrote:
> * Anthony Liguori ([EMAIL PROTECTED]) wrote:
>
>> We've already gone down the road of trying to make standard paravirtual
>> interfaces (via virtio). No one was sufficiently interested in
>> collaborating. I don't see why other paravirtualizations are going to
>> be
Alok Kataria wrote:
> Your explanation below answers the question you raised, the problem
> being we need to have support for each of these different hypercall
> mechanisms in the kernel.
> I understand that this was the correct thing to do at that moment.
> But do we want to go the same way agai
Alok Kataria wrote:
> 1. Kernel complexity : Just thinking about the complexity that this will
> put in the kernel to handle these multiple ABI signatures and scanning
> all of these leaf block's is difficult to digest.
>
The scanning for the signatures is trivial; it's not a significant
amoun
On Wed, 2008-10-01 at 14:08 -0700, Anthony Liguori wrote:
> Alok Kataria wrote:
> > On Wed, 2008-10-01 at 11:04 -0700, Jeremy Fitzhardinge wrote:
> >
> > 2. Divergence in the interface provided by the hypervisors :
> > The reason we brought up a flat hierarchy is because we think we
> > sho
* Anthony Liguori ([EMAIL PROTECTED]) wrote:
> We've already gone down the road of trying to make standard paravirtual
> interfaces (via virtio). No one was sufficiently interested in
> collaborating. I don't see why other paravirtualizations are going to
> be much different.
The point is
Alok Kataria wrote:
> On Wed, 2008-10-01 at 11:04 -0700, Jeremy Fitzhardinge wrote:
>
> 2. Divergence in the interface provided by the hypervisors :
> The reason we brought up a flat hierarchy is because we think we should
> be moving towards a approach where the guest code doesn't diver
On Wed, 2008-10-01 at 11:06 -0700, Jeremy Fitzhardinge wrote:
> Alok Kataria wrote:
> > Its not a user who has to do anything special here.
> > There are *intelligent* VM developers out there who can export a
> > different CPUid interface depending on the guest OS type. And this is
> > what most of
On Wed, 2008-10-01 at 11:04 -0700, Jeremy Fitzhardinge wrote:
> No, we're not getting anywhere. This is an outright broken idea. The
> space is too small to be able to chop up in this way, and the number of
> vendors too large to be able to do it without having a central oversight.
>
> The only
Jeremy Fitzhardinge wrote:
> Anthony Liguori wrote:
>> Mmm, cpuid bikeshedding :-)
>
> My shade of blue is better.
>
>>> The space 0x4000-0x40ff is reserved for hypervisor usage.
>>>
>>> This region is divided into 16 16-leaf blocks. Each block has the
>>> structure:
>>>
>>> 0x40x0:
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> "What hypervisor is this?" isn't a very interesting question; if you're
> even asking it then it suggests that something has gone wrong.
It's essentially already happening. Everyone wants to be a better
hyperv than hyperv ;-)
__
Anthony Liguori wrote:
> Mmm, cpuid bikeshedding :-)
My shade of blue is better.
>> The space 0x4000-0x40ff is reserved for hypervisor usage.
>>
>> This region is divided into 16 16-leaf blocks. Each block has the
>> structure:
>>
>> 0x40x0:
>> eax: max used leaf within the leaf
Jeremy Fitzhardinge wrote:
> Alok Kataria wrote:
>
> No, we're not getting anywhere. This is an outright broken idea. The
> space is too small to be able to chop up in this way, and the number of
> vendors too large to be able to do it without having a central oversight.
>
> The only way this
H. Peter Anvin wrote:
> What you'd want, at least, is a standard CPUID identification and
> range leaf at the top. 256 leaves is a *lot*, though; I'm not saying
> one couldn't run out, but it'd be hard. Keep in mind that for large
> objects there are "counting" CPUID levels, as much as I perso
Jeremy Fitzhardinge wrote:
> H. Peter Anvin wrote:
>> With a sufficiently large block, we could use fixed points, e.g. by
>> having each vendor create interfaces in the 0x40XX range, where
>> is the PCI ID they use for PCI devices.
>
> Sure, you could do that, but you'd still want to ha
H. Peter Anvin wrote:
> With a sufficiently large block, we could use fixed points, e.g. by
> having each vendor create interfaces in the 0x40XX range, where
> is the PCI ID they use for PCI devices.
Sure, you could do that, but you'd still want to have a signature in
0x4000 to pos
Jeremy Fitzhardinge wrote:
>
> No, we're not getting anywhere. This is an outright broken idea. The
> space is too small to be able to chop up in this way, and the number of
> vendors too large to be able to do it without having a central oversight.
>
I suspect we can get a larger number spa
Jeremy Fitzhardinge wrote:
>>
>> I suspect we can get a larger number space if we ask Intel & AMD. In
>> fact, I think we should request that the entire 0x40xx numberspace
>> is assigned to virtualization *anyway*.
>
> Yes, that would be good. In that case I'd revise my proposal to back
>
Alok Kataria wrote:
> Its not a user who has to do anything special here.
> There are *intelligent* VM developers out there who can export a
> different CPUid interface depending on the guest OS type. And this is
> what most of the hypervisors do (not necessarily for CPUID, but for
> other things r
H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
>>
>> No, we're not getting anywhere. This is an outright broken idea.
>> The space is too small to be able to chop up in this way, and the
>> number of vendors too large to be able to do it without having a
>> central oversight.
>>
>
> I susp
Alok Kataria wrote:
> Hi,
>
> Please find below the proposal for the generic use of cpuid space
> allotted for hypervisors. Apart from this cpuid space another thing
> worth noting would be that, Intel & AMD reserve the MSRs from 0x4000
> - 0x40FF for software use. Though the proposal doesn
Alok Kataria wrote:
>
> Hypervisor CPUID Interface Proposal
> ---
>
> Intel & AMD have reserved cpuid levels 0x4000 - 0x40FF for
> software use. Hypervisors can use these levels to provide an interface
> to pass information from the hypervisor to the guest
Alok Kataria wrote:
>
> Hi Peter,
>
> Its not a user who has to do anything special here.
> There are *intelligent* VM developers out there who can export a
> different CPUid interface depending on the guest OS type. And this is
> what most of the hypervisors do (not necessarily for CPUID, but f
On Wed, 2008-10-01 at 10:21 -0700, H. Peter Anvin wrote:
> Alok Kataria wrote:
> >
> > (This proposal may be adopted by other guest OSes. However, that is not
> > a requirement because a hypervisor can expose a different CPUID
> > interface depending on the guest OS type that is specified by the V
Alok Kataria wrote:
>
> (This proposal may be adopted by other guest OSes. However, that is not
> a requirement because a hypervisor can expose a different CPUID
> interface depending on the guest OS type that is specified by the VM
> configuration.)
>
Excuse me, but that is blatantly idiotic.
Hi,
Please find below the proposal for the generic use of cpuid space
allotted for hypervisors. Apart from this cpuid space another thing
worth noting would be that, Intel & AMD reserve the MSRs from 0x4000
- 0x40FF for software use. Though the proposal doesn't talk about
MSR's right now,
50 matches
Mail list logo
