-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/28/2014 04:16 PM, Konrad Rzeszutek Wilk wrote:
>> At least 4.8 and probably older compilers compile this as
>> intended. The point is that the standard does not guarantee the
>> indented behavior, i.e. the code is wrong.
>
> Perhaps I misunderst
On 01/24/2014 07:08 PM, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 16, 2014 at 03:13:44PM +0100, Julian Stecklina wrote:
>> The paravirtualized clock used in KVM and Xen uses a version field to
>> allow the guest to see when the shared data structure is inconsistent.
>> The c
On 01/17/2014 10:41 AM, Jan Beulich wrote:
> The half about converting local variable accesses
> back to memory reads (i.e. eliding the local variable), however,
> is only a theoretical issue afaict: If a compiler really did this, I
> think there'd be far more places where this would hurt.
It happ
On 01/16/2014 04:04 PM, Jan Beulich wrote:
> I don't think so - this would only be an issue if the conditions used
> | instead of ||. || implies a sequence point between evaluating the
> left and right sides, and the standard says: "The presence of a
> sequence point between the evaluation of expre
data!
AFAICS the compiler is allowed to optimize the given code this way.
Signed-off-by: Julian Stecklina
---
arch/x86/kernel/pvclock.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
index 42eb330..f62b41c 10
Thus spake Gleb Natapov :
>> -ret = fx_init(&vmx->vcpu);
>> -if (ret != 0)
>> -goto out;
>> -
> Label "out" is now unused. Compiler complains.
5th time's the charm. ;) Patch is updated.
Julian
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a
VMX behaves now as SVM wrt to FPU initialization. Code has been moved to
generic code path. General-purpose registers are now cleared on reset and
INIT. SVM code properly initializes EDX.
Signed-off-by: Julian Stecklina
---
arch/x86/kvm/cpuid.c | 1 +
arch/x86/kvm/svm.c | 14
VMX behaves now as SVM wrt to FPU initialization. Code has been moved to
generic code path. General-purpose registers are now cleared on reset and
INIT. SVM code properly initializes EDX.
Signed-off-by: Julian Stecklina
---
arch/x86/kvm/cpuid.c | 1 +
arch/x86/kvm/svm.c | 14
VMX behaves now as SVM wrt to FPU initialization. Code has been moved to
generic code path. General-purpose registers are now cleared on reset and
INIT. SVM code properly initializes EDX.
Signed-off-by: Julian Stecklina
---
arch/x86/kvm/cpuid.c | 1 +
arch/x86/kvm/svm.c | 14
Thus spake Gleb Natapov :
> It should, so why not move the fix to kvm_vcpu_reset() so it will work
> for both. Also what about R8-R15? Intel SDM says nothing about them in
> the section you mention, but in Volume 1 section 3.4.1.1 is says:
[...]
> I take it that they are undefined on the first tra
Floating point initialization is moved to kvm_arch_vcpu_init. Added general
purpose
register clearing to the same function. SVM code now properly initializes
EDX.
Signed-off-by: Julian Stecklina
---
arch/x86/kvm/cpuid.c | 1 +
arch/x86/kvm/svm.c | 7 +--
arch/x86/kvm/vmx.c | 7
Thus spake Gleb Natapov :
> On Thu, Nov 29, 2012 at 03:07:38PM +0100, Julian Stecklina wrote:
>> Hello,
>>
>> we have noticed that at least on 3.6.8 with VMX after a VCPU has been
>> reset via the INIT-SIPI-SIPI sequence its register state violates
>> Intel&#x
Thus spake David Mohr :
> On 2012-11-29 07:48, Julian Stecklina wrote:
>> Thus spake David Mohr :
>>
>>> * vm->vm (same host)22k
>>
>> This number is in the same ballpark as what I am seeing on pretty
>> much
>> the same hardware.
>>
&g
Signed-off-by: Julian Stecklina
---
arch/x86/kvm/vmx.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index ff66a3b..ec5a3b3 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3948,7 +3948,6 @@ static int
Signed-off-by: Julian Stecklina
---
arch/x86/kvm/vmx.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index ff66a3b..ec5a3b3 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3948,7 +3948,6 @@ static int
Thus spake David Mohr :
> * vm->vm (same host)22k
This number is in the same ballpark as what I am seeing on pretty much
the same hardware.
AFAICS, there is little you can do to the current virtio->virtio code
path that would make this substantially faster.
Julian
--
To unsubscribe from th
Hello,
we have noticed that at least on 3.6.8 with VMX after a VCPU has been
reset via the INIT-SIPI-SIPI sequence its register state violates
Intel's specification.
Specifically for our case we see at the end of vmx_vcpu_reset the
following vcpu state:
regs_avail=ffef regs_dirty=00010010
EI
Am Dienstag, den 06.03.2012, 17:47 +0200 schrieb Nadav Har'El:
> On Tue, Mar 06, 2012, Avi Kivity wrote about "Re: [PATCH] KVM: Enable
> VMX-related bits in MSR_IA32_FEATURE_CONTROL.":
> > > case MSR_IA32_FEATURE_CONTROL:
> > > - *pdata = 0;
> > > +/*
> > > +
Thus spake Avi Kivity :
> On 03/06/2012 05:02 PM, Julian Stecklina wrote:
>> The spec (Vol 3C, Chapter 34.1) regarding the IA32_FEATURE_CONTROL MSR says
>> "Therefore the lock bit must be set after configuring support for Intel
>> Virtualization Technology and prior
VMX for system executive that
do not require SMX."
Signed-off-by: Julian Stecklina
---
arch/x86/kvm/vmx.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4ea7678..aef1e5b 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/
Am Freitag, den 13.01.2012, 08:52 -0200 schrieb Marcelo Tosatti:
> On Thu, Jan 12, 2012 at 06:07:51PM +0100, Julian Stecklina wrote:
> > Am Freitag, den 23.12.2011, 08:40 -0200 schrieb Marcelo Tosatti:
> > > On Mon, Dec 19, 2011 at 02:14:27AM +0100, Julian Stecklina wrote:
&g
Am Freitag, den 23.12.2011, 08:40 -0200 schrieb Marcelo Tosatti:
> On Mon, Dec 19, 2011 at 02:14:27AM +0100, Julian Stecklina wrote:
> > If the guest programs an IPI with level=0 (de-assert) and trig_mode=0
> > (edge),
> > it is erroneously treated as INIT de-assert and igno
On Fr, 2011-12-23 at 08:40 -0200, Marcelo Tosatti wrote:
> On Mon, Dec 19, 2011 at 02:14:27AM +0100, Julian Stecklina wrote:
> > If the guest programs an IPI with level=0 (de-assert) and trig_mode=0
> > (edge),
> > it is erroneously treated as INIT de-assert and ignored, but
If the guest programs an IPI with level=0 (de-assert) and trig_mode=0 (edge),
it is erroneously treated as INIT de-assert and ignored, but to quote the
spec: "For this delivery mode [INIT de-assert], the level flag must be set to
0 and trigger mode flag to 1."
Signed-off-by: Julian
This fixes byte accesses to IOAPIC_REG_SELECT as mandated by at least the
ICH10 and Intel Series 5 chipset specs. It also makes ioapic_mmio_write
consistent with ioapic_mmio_read, which also allows byte and word accesses.
Signed-off-by: Julian Stecklina
---
virt/kvm/ioapic.c | 15
On Mi, 2011-11-23 at 12:47 +0200, Avi Kivity wrote:
> On 11/22/2011 06:09 PM, Julian Stecklina wrote:
> > This fixes byte accesses to IOAPIC_REG_SELECT as mandated by at least the
> > ICH10 and Intel Series 5 chipset specs. It also makes ioapic_mmio_write
> > consistent
This fixes byte accesses to IOAPIC_REG_SELECT as mandated by at least the
ICH10 and Intel Series 5 chipset specs. It also makes ioapic_mmio_write
consistent with ioapic_mmio_read, which also allows byte and word accesses.
Signed-off-by: Julian Stecklina
---
virt/kvm/ioapic.c | 17
Hello,
Avi Kivity wrote:
> Care to post a patch instead?
Sure. Never hacked KVM, though. Is there a particular reason why the
void *val argument to ioapic_mmio_read/_write is only dereferenced when
ioapic->lock is not held?
Regards, Julian
--
To unsubscribe from this list: send the line "unsubs
Hello,
KVM emulates an IOAPIC that doesn't handle byte writes to its
IOAPIC_REG_SELECT register, although for example the ICH10 spec[1]
clearly states that this is an 8-bit register. See
http://www.intel.com/content/dam/doc/datasheet/io-controller-hub-10-family-datasheet.pdf
Table 13-4 on page 43
>>>>
>>>>
>>> Yes.
>>>
>>>
>>
>> Then the guest deserves whatever it gets...
>>
> I suspect windows may do this since it uses NMI for task switching.
Could you elaborate on that? How/why does it use NMIs for task
switching?
Julian Stecklina writes:
> "Kohl, Bernhard (NSN - DE/Munich)" writes:
>
>> Jan Kiszka Wrote:
> [...]
>> OK, after the discussion has finished, I will submit separate patches.
>
> Is there any progress on this? I've been using this patch for several
>
>> https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2681442&group_id=180599
>>
> Works for me.
Then the patches should be fine (at least for me *g*).
Regards,
--
Julian Stecklina
The day Microsoft makes something that doesn't suck is probably the
2681442 for me:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2681442&group_id=180599
Regards,
--
Julian Stecklina
The day Microsoft makes something that doesn't suck is probably the day
they start making vacuum cleaners - Ernst Jan Plugge
--
To unsubscribe from this list:
33 matches
Mail list logo
