On 22/01/2018 11:36, Kang, Luwei wrote:
>>> On Thu, Jan 18, 2018 at 03:44:49PM +0100, Paolo Bonzini wrote:
On 18/01/2018 15:37, Eduardo Habkost wrote:
> On Thu, Jan 18, 2018 at 02:39:57PM +0100, Paolo Bonzini wrote:
>> On 18/01/2018 14:24, Eduardo Habkost wrote:
>>> However, if the
> > On 18/01/2018 14:24, Eduardo Habkost wrote:
> > > However, if there's a simple way to make it possible to migrate
> > > between hosts with different CPUID[14h] data, it would be even
> > > better. With the current KVM intel-pt implementation, what happens
> > > if the CPUID[14h] data seen by t
> > On Thu, Jan 18, 2018 at 03:44:49PM +0100, Paolo Bonzini wrote:
> >> On 18/01/2018 15:37, Eduardo Habkost wrote:
> >>> On Thu, Jan 18, 2018 at 02:39:57PM +0100, Paolo Bonzini wrote:
> On 18/01/2018 14:24, Eduardo Habkost wrote:
> > However, if there's a simple way to make it possible to
On 18/01/2018 17:52, Eduardo Habkost wrote:
> On Thu, Jan 18, 2018 at 03:44:49PM +0100, Paolo Bonzini wrote:
>> On 18/01/2018 15:37, Eduardo Habkost wrote:
>>> On Thu, Jan 18, 2018 at 02:39:57PM +0100, Paolo Bonzini wrote:
On 18/01/2018 14:24, Eduardo Habkost wrote:
> However, if there's a
On Thu, Jan 18, 2018 at 03:44:49PM +0100, Paolo Bonzini wrote:
> On 18/01/2018 15:37, Eduardo Habkost wrote:
> > On Thu, Jan 18, 2018 at 02:39:57PM +0100, Paolo Bonzini wrote:
> >> On 18/01/2018 14:24, Eduardo Habkost wrote:
> >>> However, if there's a simple way to make it possible to migrate
> >>
On 18/01/2018 15:37, Eduardo Habkost wrote:
> On Thu, Jan 18, 2018 at 02:39:57PM +0100, Paolo Bonzini wrote:
>> On 18/01/2018 14:24, Eduardo Habkost wrote:
>>> However, if there's a simple way to make it possible to migrate
>>> between hosts with different CPUID[14h] data, it would be even
>>> bett
On Thu, Jan 18, 2018 at 02:39:57PM +0100, Paolo Bonzini wrote:
> On 18/01/2018 14:24, Eduardo Habkost wrote:
> > However, if there's a simple way to make it possible to migrate
> > between hosts with different CPUID[14h] data, it would be even
> > better. With the current KVM intel-pt implementati
On 18/01/2018 14:24, Eduardo Habkost wrote:
> However, if there's a simple way to make it possible to migrate
> between hosts with different CPUID[14h] data, it would be even
> better. With the current KVM intel-pt implementation, what
> happens if the CPUID[14h] data seen by the guest doesn't mat
On Thu, Jan 18, 2018 at 05:33:53AM +, Kang, Luwei wrote:
> > > > > > > On Mon, Jan 15, 2018 at 12:04:55 -0200, Eduardo Habkost wrote:
> > > > > > > > CCing libvirt developers.
> > > > > > > ...
> > > > > > > > This case is slightly more problematic, however: the new
> > > > > > > > feature is a
> > > > > > On Mon, Jan 15, 2018 at 12:04:55 -0200, Eduardo Habkost wrote:
> > > > > > > CCing libvirt developers.
> > > > > > ...
> > > > > > > This case is slightly more problematic, however: the new
> > > > > > > feature is actually migratable (under very controlled
> > > > > > > circumstances)
On Wed, Jan 17, 2018 at 10:32:56AM +, Kang, Luwei wrote:
> > > > > On Mon, Jan 15, 2018 at 12:04:55 -0200, Eduardo Habkost wrote:
> > > > > > CCing libvirt developers.
> > > > > ...
> > > > > > This case is slightly more problematic, however: the new feature
> > > > > > is actually migratable (
> > > > On Mon, Jan 15, 2018 at 12:04:55 -0200, Eduardo Habkost wrote:
> > > > > CCing libvirt developers.
> > > > ...
> > > > > This case is slightly more problematic, however: the new feature
> > > > > is actually migratable (under very controlled circumstances)
> > > > > because of patch 2/2, bu
On Tue, Jan 16, 2018 at 06:10:17AM +, Kang, Luwei wrote:
> > > On Mon, Jan 15, 2018 at 12:04:55 -0200, Eduardo Habkost wrote:
> > > > CCing libvirt developers.
> > > ...
> > > > This case is slightly more problematic, however: the new feature is
> > > > actually migratable (under very controlle
> > On Mon, Jan 15, 2018 at 12:04:55 -0200, Eduardo Habkost wrote:
> > > CCing libvirt developers.
> > ...
> > > This case is slightly more problematic, however: the new feature is
> > > actually migratable (under very controlled circumstances) because of
> > > patch 2/2, but it is not migration-sa
On Mon, Jan 15, 2018 at 03:25:18PM +0100, Jiri Denemark wrote:
> On Mon, Jan 15, 2018 at 12:04:55 -0200, Eduardo Habkost wrote:
> > CCing libvirt developers.
> ...
> > This case is slightly more problematic, however: the new feature
> > is actually migratable (under very controlled circumstances)
>
On Mon, Jan 15, 2018 at 12:04:55 -0200, Eduardo Habkost wrote:
> CCing libvirt developers.
...
> This case is slightly more problematic, however: the new feature
> is actually migratable (under very controlled circumstances)
> because of patch 2/2, but it is not migration-safe[1]. This
> means lib
CCing libvirt developers.
On Mon, Jan 15, 2018 at 10:33:35AM +0100, Paolo Bonzini wrote:
> On 15/01/2018 08:19, Kang, Luwei wrote:
> >> If you are forwarding host info directly to the guest, the feature
> >> is not migration-safe. The new feature needs to be added to
> >> feature_word_info[FEAT_
On 15/01/2018 08:19, Kang, Luwei wrote:
>> If you are forwarding host info directly to the guest, the feature
>> is not migration-safe. The new feature needs to be added to
>> feature_word_info[FEAT_7_0_EBX].unmigratable_flags.
>>
> Hi, Thanks for you review. I want to support Intel PT live migr
> > From: Chao Peng
> >
> > Expose Intel Processor Trace feature to guest.
> >
> > Signed-off-by: Chao Peng
> > Signed-off-by: Luwei Kang
> > ---
> > target/i386/cpu.c | 19 ++- target/i386/cpu.h | 1 +
> > target/i386/kvm.c | 23 +++
> > 3 files changed, 42
On Tue, Jan 09, 2018 at 04:36:36AM +0800, Luwei Kang wrote:
> From: Chao Peng
>
> Expose Intel Processor Trace feature to guest.
>
> Signed-off-by: Chao Peng
> Signed-off-by: Luwei Kang
> ---
> target/i386/cpu.c | 19 ++-
> target/i386/cpu.h | 1 +
> target/i386/kvm.c | 23 ++
From: Chao Peng
Expose Intel Processor Trace feature to guest.
Signed-off-by: Chao Peng
Signed-off-by: Luwei Kang
---
target/i386/cpu.c | 19 ++-
target/i386/cpu.h | 1 +
target/i386/kvm.c | 23 +++
3 files changed, 42 insertions(+), 1 deletion(-)
diff --
21 matches
Mail list logo
