On Sat, Sep 14, 2013 at 12:12:43AM -0500, Alexander Graf wrote:
>
>
> Am 13.09.2013 um 21:21 schrieb Paul Mackerras :
>
> > In hardware there is in fact an LPCR per hardware CPU thread, though
> > the architecture says that on threaded processors many of the fields
> > have to be the same on eac
On Thu, Sep 12, 2013 at 06:01:37PM -0500, Alexander Graf wrote:
>
> On 05.08.2013, at 23:27, Paul Mackerras wrote:
>
> > Currently we request write access to all pages that get mapped into the
> > guest, even if the guest is only loading from the page. This reduces
> > the effectiveness of KSM b
Am 13.09.2013 um 21:21 schrieb Paul Mackerras :
> On Fri, Sep 13, 2013 at 01:36:25PM -0500, Alexander Graf wrote:
>>
>> On 05.09.2013, at 22:21, Paul Mackerras wrote:
>>
>>> This adds the ability for userspace to read and write the LPCR
>>> (Logical Partitioning Control Register) value relatin
On Fri, Sep 13, 2013 at 02:58:43PM -0500, Alexander Graf wrote:
>
> How long does writing to PCR take? Is it faster than a load+branch to see
> whether we actually need it? I would assume the normal fast path is going to
> be guest cpu == host.
Seems to be about 30 cycles to write PCR, so a com
On Fri, Sep 13, 2013 at 04:51:40PM -0500, Alexander Graf wrote:
>
> I don't like how this is available for book3s, but not for booke. In the long
> run it might make sense to create a generic one_reg handler for shared
> fields. But in the meantime, could you please just add handling for booke a
On Fri, Sep 13, 2013 at 01:36:25PM -0500, Alexander Graf wrote:
>
> On 05.09.2013, at 22:21, Paul Mackerras wrote:
>
> > This adds the ability for userspace to read and write the LPCR
> > (Logical Partitioning Control Register) value relating to a guest
> > via the GET/SET_ONE_REG interface. The
On 05.09.2013, at 22:17, Paul Mackerras wrote:
> This allows guests to have a different timebase origin from the host.
> This is needed for migration, where a guest can migrate from one host
> to another and the two hosts might have a different timebase origin.
> However, the timebase seen by the
On 05.09.2013, at 22:18, Paul Mackerras wrote:
> The VRSAVE register value for a vcpu is accessible through the
> GET/SET_SREGS interface for Book E processors, but not for Book 3S
> processors. In order to make this accessible for Book 3S processors,
> this adds a new register identifier for GE
On 05.09.2013, at 22:22, Paul Mackerras wrote:
> POWER7 and later IBM server processors have a register called the
> Program Priority Register (PPR), which controls the priority of
> each hardware CPU SMT thread, and affects how fast it runs compared
> to other SMT threads. This priority can be
On 05.09.2013, at 22:23, Paul Mackerras wrote:
> The H_CONFER hypercall is used when a guest vcpu is spinning on a lock
> held by another vcpu which has been preempted, and the spinning vcpu
> wishes to give its timeslice to the lock holder. We implement this
> in the straightforward way using k
On 05.09.2013, at 22:23, Paul Mackerras wrote:
> We have two paths into and out of the low-level guest entry and exit
> code: from a vcpu task via kvmppc_hv_entry_trampoline, and from the
> system reset vector for an offline secondary thread on POWER7 via
> kvm_start_guest. Currently both just b
On 05.09.2013, at 22:11, Paul Mackerras wrote:
> Currently we are not saving and restoring the SIAR and SDAR registers in
> the PMU (performance monitor unit) on guest entry and exit. The result
> is that performance monitoring tools in the guest could get false
> information about where a progr
On 05.09.2013, at 22:24, Paul Mackerras wrote:
> The yield count in the VPA is supposed to be incremented every time
> we enter the guest, and every time we exit the guest, so that its
> value is even when the vcpu is running in the guest and odd when it
> isn't. However, it's currently possible
On 05.09.2013, at 22:24, Paul Mackerras wrote:
> This moves the code in book3s_hv_rmhandlers.S that reads any pending
> interrupt from the XICS interrupt controller, and works out whether
> it is an IPI for the guest, an IPI for the host, or a device interrupt,
> into a new function called kvmppc
On 05.09.2013, at 22:25, Paul Mackerras wrote:
> From: Michael Ellerman
>
> This means that if we do happen to get a trap that we don't know
> about, we abort the guest rather than crashing the host kernel.
>
> Signed-off-by: Michael Ellerman
> Signed-off-by: Paul Mackerras
> ---
> arch/powe
On 05.09.2013, at 22:22, Paul Mackerras wrote:
> This enables us to use the Processor Compatibility Register (PCR) on
> POWER7 to put the processor into architecture 2.05 compatibility mode
> when running a guest. In this mode the new instructions and registers
> that were introduced on POWER7 a
Hello Alex and kvm list,
I haven't managed any progress since my last e-mail, but wanted to
note that I temporarily have access to another machine that is
somewhat similar, but may be different enough to conduct tests that
might be useful. The motherboard is an ASUS F2A55-M LK2, the CPU is an
AMD
On 05.09.2013, at 22:21, Paul Mackerras wrote:
> This adds the ability for userspace to read and write the LPCR
> (Logical Partitioning Control Register) value relating to a guest
> via the GET/SET_ONE_REG interface. There is only one LPCR value
> for the guest, which can be accessed through any
Il 06/09/2013 04:04, Arthur Chunqi Li ha scritto:
> This patch contains the following two changes:
> 1. Fix the bug in nested preemption timer support. If vmexit L2->L0
> with some reasons not emulated by L1, preemption timer value should
> be save in such exits.
> 2. Add support of "Save VMX-preem
On Fri, 2013-09-13 at 18:49 +1000, Alexey Kardashevskiy wrote:
> On 09/13/2013 07:23 AM, Alex Williamson wrote:
> > So far we've succeeded at making KVM and VFIO mostly unaware of each
> > other, but there's any important point where that breaks down. Intel
> > VT-d hardware may or may not support
On Fri, 2013-09-13 at 17:52 +0300, Michael S. Tsirkin wrote:
> On Fri, Sep 13, 2013 at 08:13:40AM -0600, Alex Williamson wrote:
> > On Fri, 2013-09-13 at 15:39 +0300, Michael S. Tsirkin wrote:
> > > On Thu, Sep 12, 2013 at 03:23:15PM -0600, Alex Williamson wrote:
> > > > So far we've succeeded at m
On Fri, Sep 13, 2013 at 08:13:40AM -0600, Alex Williamson wrote:
> On Fri, 2013-09-13 at 15:39 +0300, Michael S. Tsirkin wrote:
> > On Thu, Sep 12, 2013 at 03:23:15PM -0600, Alex Williamson wrote:
> > > So far we've succeeded at making KVM and VFIO mostly unaware of each
> > > other, but there's an
On Fri, 2013-09-13 at 15:39 +0300, Michael S. Tsirkin wrote:
> On Thu, Sep 12, 2013 at 03:23:15PM -0600, Alex Williamson wrote:
> > So far we've succeeded at making KVM and VFIO mostly unaware of each
> > other, but there's any important point where that breaks down. Intel
> > VT-d hardware may or
The data in leaf 0Dh depends on information from other feature bits.
Instead of passing it blindly from the host, compute it based on
whether these feature bits are enabled.
Signed-off-by: Paolo Bonzini
---
target-i386/cpu.c | 63 +++-
1 file chang
On KVM, the KVM_SET_XSAVE would be executed with a 0 xstate_bv,
and not restore anything.
Since FP and SSE data are always valid, set them in xstate_bv at reset
time. In fact, that value is the same that KVM_GET_XSAVE returns on
pre-XSAVE hosts.
Signed-off-by: Paolo Bonzini
---
target-i386/cpu
This series fixes two migration bugs concerning KVM's XSAVE ioctls.
The second right now is only a theoretical problem, since the only
XSAVE-specific state is AVX and all machines with XSAVE also have AVX.
In the future, this will ensure that machines with MPX or AVX-512
do not expose those XSAVE s
On Thu, Sep 12, 2013 at 03:23:15PM -0600, Alex Williamson wrote:
> So far we've succeeded at making KVM and VFIO mostly unaware of each
> other, but there's any important point where that breaks down. Intel
> VT-d hardware may or may not support snoop control. When snoop
> control is available, i
Il 05/09/2013 11:24, Zhang, Yang Z ha scritto:
> > Here I have such consideration: this logic is wrong if CPU support
> > PIN_BASED_VMX_PREEMPTION_TIMER but doesn't support
> > VM_EXIT_SAVE_VMX_PREEMPTION_TIMER, though I don't know if this does
> > occurs. So the codes above reads the MSR and reser
On 09/13/2013 07:23 AM, Alex Williamson wrote:
> So far we've succeeded at making KVM and VFIO mostly unaware of each
> other, but there's any important point where that breaks down. Intel
> VT-d hardware may or may not support snoop control. When snoop
> control is available, intel-iommu promote
29 matches
Mail list logo
