Hi Andy,
On Fri, 2014-09-19 at 11:20 -0700, Andy Lutomirski wrote:
> [cc: Alok Kataria at VMware]
>
> On Fri, Sep 19, 2014 at 11:12 AM, Gleb Natapov wrote:
> > On Fri, Sep 19, 2014 at 11:02:38AM -0700, Andy Lutomirski wrote:
> >> On Fri, Sep 19, 2014 at 10:49 AM, Gleb N
On 07/10/2014 05:57 PM, Paolo Bonzini wrote:> Il 10/07/2014 10:55, Jan Kiszka
ha scritto:
+ /*
+ * SVM spec doesn't require the platform to track the G bit for all
+ * segments, so similar to CS, let's synthesize this bit for all
+ * segments.
>> Either I misunderstand t
Thanks Jan and Paolo for looking at the change, I have added a comment
in svm_get_segment. Joerg, please consider this for the next merge.
--
From: Jim Mattson
We have noticed that qemu-kvm hangs early in the BIOS when runnning nested
under some versions of VMware ESXi.
The problem we believe
From: Jim Mattson
We have noticed that qemu-kvm hangs early in the BIOS when runnning nested
under some versions of VMware ESXi.
The problem we believe is because KVM assumes that the platform preserves
the 'G' but for any segment register. The SVM specification itemizes the
segment attribute bi
On Thu, 2009-11-19 at 18:08 -0800, Jeremy Fitzhardinge wrote:
> On 11/20/09 09:59, Alexander Graf wrote:
> >
> > On 20.11.2009, at 02:54, Jeremy Fitzhardinge wrote:
> >
> >> On 11/20/09 07:58, Alexander Graf wrote:
> >>>
> >>> Am 19.11.2009 um 23:55 schrieb Jeremy Fitzhardinge :
> >>>
> On 11
I am all for it.
Just one nit, below.
>
> +char * __cpuinit hypervisor_str(struct cpuinfo_x86 *c)
> +{
> + if (c->x86_hyper_vendor == X86_HYPER_VENDOR_VMWARE)
> + return "VMWare";
Better to have "VMware" string instead.
Thanks,
Alok
--
To unsubscribe from this list: send the
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 hiera
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
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
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 ty
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,
11 matches
Mail list logo
