On Tue, Feb 28, 2012 at 5:15 PM, Martin Mailand mar...@tuxadero.com wrote:
Hi Stefan,
I was bisecting qemu-kvm.git.
qemu-kvm.git regularly merges from qemu.git. The history of the
qemu-kvm.git repository is not linear because of these periodic merges
from the qemu.git tree. I think what
On 02/29/2012 09:49 AM, Takuya Yoshikawa wrote:
Avi Kivity a...@redhat.com wrote:
The key part of the implementation is the use of xchg() operation for
clearing dirty bits atomically. Since this allows us to update only
BITS_PER_LONG pages at once, we need to iterate over the dirty
On 02/28/2012 11:47 PM, Jan Kiszka wrote:
Looks like isa-pit has zero gpio pins, so it fails when crashing. I
must have mismerged it, but where is the gpio pin count set?
In pit_initfn. Does -no-kvm-irqchip work fine? It's a bit tricky to
discuss this without seeing your code.
pushed
On Tue, Feb 28, 2012 at 12:28:29PM +, Stefano Stabellini wrote:
On Tue, 28 Feb 2012, Ian Campbell wrote:
On Tue, 2012-02-28 at 10:20 +, Dave Martin wrote:
On Mon, Feb 27, 2012 at 07:33:39PM +, Ian Campbell wrote:
On Mon, 2012-02-27 at 18:03 +, Dave Martin wrote:
On Wed, Feb 29, 2012 at 09:08:52AM +0800, Wen Congyang wrote:
At 02/28/2012 06:45 PM, Gleb Natapov Wrote:
On Tue, Feb 28, 2012 at 11:19:47AM +0100, Jan Kiszka wrote:
On 2012-02-28 10:42, Wen Congyang wrote:
At 02/28/2012 05:34 PM, Jan Kiszka Wrote:
On 2012-02-28 09:23, Wen Congyang wrote:
On 02/29/2012 03:29 AM, Wen Congyang wrote:
At 02/28/2012 07:23 PM, Avi Kivity Wrote:
On 02/27/2012 05:01 AM, Wen Congyang wrote:
We can know the guest is paniced when the guest runs on xen.
But we do not have such feature on kvm. This patch implemnts
this feature, and the implementation
On Wed, Feb 29, 2012 at 11:49:58AM +0200, Avi Kivity wrote:
On 02/29/2012 03:29 AM, Wen Congyang wrote:
At 02/28/2012 07:23 PM, Avi Kivity Wrote:
On 02/27/2012 05:01 AM, Wen Congyang wrote:
We can know the guest is paniced when the guest runs on xen.
But we do not have such feature on
On Wed, 2012-02-29 at 09:34 +, Dave Martin wrote:
On Tue, Feb 28, 2012 at 12:28:29PM +, Stefano Stabellini wrote:
I don't have a very strong opinion on which register we should use, but
I would like to avoid r7 if it is already actively used by gcc.
But there is no framepointer
On Wed, Feb 29, 2012 at 11:49:58AM +0200, Avi Kivity wrote:
On 02/29/2012 03:29 AM, Wen Congyang wrote:
At 02/28/2012 07:23 PM, Avi Kivity Wrote:
On 02/27/2012 05:01 AM, Wen Congyang wrote:
We can know the guest is paniced when the guest runs on xen.
But we do not have such feature on
On 02/29/2012 11:55 AM, Gleb Natapov wrote:
How about using a virtio-serial channel for this? You can transfer any
amount of information (including the dump itself).
Isn't it unreliable after the guest panicked?
So is calling hypercalls, or dumping, or writing to the screen. Of
On 02/29/2012 11:58 AM, Daniel P. Berrange wrote:
How about using a virtio-serial channel for this? You can transfer any
amount of information (including the dump itself).
When the guest OS has crashed, any dumps will be done from the host
OS using libvirt's core dump mechanism. The
On Wed, Feb 29, 2012 at 12:00:41PM +0200, Avi Kivity wrote:
On 02/29/2012 11:55 AM, Gleb Natapov wrote:
How about using a virtio-serial channel for this? You can transfer any
amount of information (including the dump itself).
Isn't it unreliable after the guest panicked?
On 02/29/2012 12:05 PM, Gleb Natapov wrote:
On Wed, Feb 29, 2012 at 12:00:41PM +0200, Avi Kivity wrote:
On 02/29/2012 11:55 AM, Gleb Natapov wrote:
How about using a virtio-serial channel for this? You can transfer any
amount of information (including the dump itself).
Avi Kivity a...@redhat.com wrote:
Okay. But note you don't need the alignment check; simply allocate the
array aligned, and a multiple of 16 bytes, in the first place.
OKay, then we can do something like:
for each (x = bitmap[i], y = bitmap[i+1])
if (!x !y)
At 02/29/2012 05:36 PM, Gleb Natapov Wrote:
On Wed, Feb 29, 2012 at 09:08:52AM +0800, Wen Congyang wrote:
At 02/28/2012 06:45 PM, Gleb Natapov Wrote:
On Tue, Feb 28, 2012 at 11:19:47AM +0100, Jan Kiszka wrote:
On 2012-02-28 10:42, Wen Congyang wrote:
At 02/28/2012 05:34 PM, Jan Kiszka Wrote:
Am 28.02.2012 17:07, schrieb Eric Blake:
On 02/28/2012 07:58 AM, Stefan Hajnoczi wrote:
On Tue, Feb 28, 2012 at 2:47 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 28/02/2012 15:39, Stefan Hajnoczi ha scritto:
I'm not a fan of transactions or freeze/thaw (if used to atomically
perform other
On 2012-02-29 10:29, Avi Kivity wrote:
On 02/28/2012 11:47 PM, Jan Kiszka wrote:
Looks like isa-pit has zero gpio pins, so it fails when crashing. I
must have mismerged it, but where is the gpio pin count set?
In pit_initfn. Does -no-kvm-irqchip work fine? It's a bit tricky to
discuss this
At 02/29/2012 06:08 PM, Avi Kivity Wrote:
On 02/29/2012 12:05 PM, Gleb Natapov wrote:
On Wed, Feb 29, 2012 at 12:00:41PM +0200, Avi Kivity wrote:
On 02/29/2012 11:55 AM, Gleb Natapov wrote:
How about using a virtio-serial channel for this? You can transfer any
amount of information
On Wed, Feb 29, 2012 at 12:05:32PM +0200, Avi Kivity wrote:
On 02/29/2012 11:58 AM, Daniel P. Berrange wrote:
How about using a virtio-serial channel for this? You can transfer any
amount of information (including the dump itself).
When the guest OS has crashed, any dumps will be
At 02/29/2012 06:05 PM, Avi Kivity Wrote:
On 02/29/2012 11:58 AM, Daniel P. Berrange wrote:
How about using a virtio-serial channel for this? You can transfer any
amount of information (including the dump itself).
When the guest OS has crashed, any dumps will be done from the host
OS using
On 02/29/2012 12:17 PM, Wen Congyang wrote:
Yes, crash can be so severe that it is not even detected by a kernel
itself, so not OOPS message even printed. But in most cases if kernel is
functional enough to print OOPS it is functional enough to call single
hypercall instruction.
Why
On 02/29/2012 12:19 PM, Daniel P. Berrange wrote:
On Wed, Feb 29, 2012 at 12:05:32PM +0200, Avi Kivity wrote:
On 02/29/2012 11:58 AM, Daniel P. Berrange wrote:
How about using a virtio-serial channel for this? You can transfer any
amount of information (including the dump itself).
On Wed, Feb 29, 2012 at 12:08:19PM +0200, Avi Kivity wrote:
On 02/29/2012 12:05 PM, Gleb Natapov wrote:
On Wed, Feb 29, 2012 at 12:00:41PM +0200, Avi Kivity wrote:
On 02/29/2012 11:55 AM, Gleb Natapov wrote:
How about using a virtio-serial channel for this? You can transfer
On 02/29/2012 12:31 PM, Wen Congyang wrote:
At 02/29/2012 06:05 PM, Avi Kivity Wrote:
On 02/29/2012 11:58 AM, Daniel P. Berrange wrote:
How about using a virtio-serial channel for this? You can transfer any
amount of information (including the dump itself).
When the guest OS has
On 02/29/2012 12:44 PM, Gleb Natapov wrote:
Yes, crash can be so severe that it is not even detected by a kernel
itself, so not OOPS message even printed. But in most cases if kernel is
functional enough to print OOPS it is functional enough to call single
hypercall instruction.
On Wed, Feb 29, 2012 at 12:48:57PM +0200, Avi Kivity wrote:
On 02/29/2012 12:44 PM, Gleb Natapov wrote:
Yes, crash can be so severe that it is not even detected by a kernel
itself, so not OOPS message even printed. But in most cases if kernel is
functional enough to print OOPS
diff --git a/src/ssdt-pcihp.dsl b/src/ssdt-pcihp.dsl
index 442e7a8..3f50169 100644
--- a/src/ssdt-pcihp.dsl
+++ b/src/ssdt-pcihp.dsl
@@ -24,6 +24,7 @@ DefinitionBlock (ssdt-pcihp.aml, SSDT, 0x01, BXPC,
BXSSDTPCIHP, 0x1)
ACPI_EXTRACT_METHOD_STRING aml_ej0_name \
On Wed, Feb 29, 2012 at 09:56:02AM +, Ian Campbell wrote:
On Wed, 2012-02-29 at 09:34 +, Dave Martin wrote:
On Tue, Feb 28, 2012 at 12:28:29PM +, Stefano Stabellini wrote:
I don't have a very strong opinion on which register we should use, but
I would like to avoid r7 if it
On 02/29/2012 12:16 PM, Takuya Yoshikawa wrote:
We may see partial display updates if we do not hold the mmu_lock during
xchg loop: it is possible that pages near the end of the framebuffer alone
gets updated sometimes - I noticed this problem when I fixed the TLB flush
issue.
I
On Wed, Feb 29, 2012 at 09:56:02AM +, Ian Campbell wrote:
On Wed, 2012-02-29 at 09:34 +, Dave Martin wrote:
On Tue, Feb 28, 2012 at 12:28:29PM +, Stefano Stabellini wrote:
I don't have a very strong opinion on which register we should use, but
I would like to avoid r7 if it
Hi Stefan,
you are right, the performance for the commits 0b9b128530b and
4fefc55ab04d are both good.
What is the best approach to stay in the qemu-kvm.git history?
-martin
On 29.02.2012 09:38, Stefan Hajnoczi wrote:
I suggest testing both of the qemu-kvm.git merge commits, 0b9b128530b
and
On Tue, Feb 28, 2012 at 07:38:34PM +0200, Avi Kivity wrote:
On 02/28/2012 07:36 PM, David Ahern wrote:
I was to suggest the reverse: since this patch addesses an AMD bug,
why not push those functions into perf_event_amd.c and make them
dependent on CONFIG_CPU_SUP_AMD as well.
It depends
kvm_io_bus devices are used for ioevent, pit, pic, ioapic,
coalesced_mmio.
Currently Qemu only emulates one PCI bus, it contains 32 slots,
one slot contains 8 functions, maximum of supported PCI devices:
1 * 32 * 8 = 256. The maximum of coalesced mmio zone is 100,
each zone has an iobus devices.
On 02/29/2012 12:14 PM, Jan Kiszka wrote:
On 2012-02-29 10:29, Avi Kivity wrote:
On 02/28/2012 11:47 PM, Jan Kiszka wrote:
Looks like isa-pit has zero gpio pins, so it fails when crashing. I
must have mismerged it, but where is the gpio pin count set?
In pit_initfn. Does
On Wed, Feb 29, 2012 at 1:12 PM, Martin Mailand mar...@tuxadero.com wrote:
Hi Stefan,
you are right, the performance for the commits 0b9b128530b and 4fefc55ab04d
are both good.
What is the best approach to stay in the qemu-kvm.git history?
I didn't know the answer so I asked on #git on
On Wed, Feb 29, 2012 at 1:44 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Wed, Feb 29, 2012 at 1:12 PM, Martin Mailand mar...@tuxadero.com wrote:
Hi Stefan,
you are right, the performance for the commits 0b9b128530b and 4fefc55ab04d
are both good.
What is the best approach to stay in the
On Tue, 2012-02-28 at 20:40 -0800, John Fastabend wrote:
OK back to this. The last piece is where to put these messages...
we could take PF_ROUTE:RTM_*NEIGH
PF_ROUTE:RTM_NEWNEIGH - Add a new FDB entry to an offloaded
switch.
PF_ROUTE:RTM_DELNEIGH -
On Tue, 2012-02-28 at 21:14 -0800, John Fastabend wrote:
Just checked looks like the DSA infrastructure has commands to enable
STP so guess it is doing learning.
IIRC, Lennert built some of this stuff tied to the kernel.
cheers,
jamal
--
To unsubscribe from this list: send the line
It turned out that a performance counter on AMD does not
count at all when the GO or HO bit is set in the control
register and SVM is disabled in EFER.
This patch works around this issue by masking out the HO bit
in the performance counter control register when SVM is not
enabled.
The GO bit is
Avi Kivity a...@redhat.com wrote:
We cannot get a complete snapshot without mmu_lock; if the guest faults on
the Nth page during xchg'ing i = 1, 2, ... then the i = N alone will
become newer.
Ah, so there is no data corruption (missed dirty bits), just the display
is updated
On 2012-02-29 14:30, Amos Kong wrote:
kvm_io_bus devices are used for ioevent, pit, pic, ioapic,
coalesced_mmio.
Currently Qemu only emulates one PCI bus, it contains 32 slots,
one slot contains 8 functions, maximum of supported PCI devices:
1 * 32 * 8 = 256. The maximum of coalesced mmio
On 2012-02-29 14:45, Avi Kivity wrote:
On 02/29/2012 12:14 PM, Jan Kiszka wrote:
On 2012-02-29 10:29, Avi Kivity wrote:
On 02/28/2012 11:47 PM, Jan Kiszka wrote:
Looks like isa-pit has zero gpio pins, so it fails when crashing. I
must have mismerged it, but where is the gpio pin count set?
On 02/29/2012 04:24 PM, Jan Kiszka wrote:
On 2012-02-29 14:45, Avi Kivity wrote:
On 02/29/2012 12:14 PM, Jan Kiszka wrote:
On 2012-02-29 10:29, Avi Kivity wrote:
On 02/28/2012 11:47 PM, Jan Kiszka wrote:
Looks like isa-pit has zero gpio pins, so it fails when crashing. I
must have
On Wed, 2012-02-29 at 12:58 +, Dave Martin wrote:
On Wed, Feb 29, 2012 at 09:56:02AM +, Ian Campbell wrote:
On Wed, 2012-02-29 at 09:34 +, Dave Martin wrote:
On Tue, Feb 28, 2012 at 12:28:29PM +, Stefano Stabellini wrote:
I don't have a very strong opinion on which
On Wed, 29 Feb 2012, Dave Martin wrote:
On Wed, Feb 29, 2012 at 09:56:02AM +, Ian Campbell wrote:
On Wed, 2012-02-29 at 09:34 +, Dave Martin wrote:
On Tue, Feb 28, 2012 at 12:28:29PM +, Stefano Stabellini wrote:
I don't have a very strong opinion on which register we
On Tue, 2012-02-28 at 14:19 +0100, Jan Kiszka wrote:
PCI 2.3 allows to generically disable IRQ sources at device level. This
enables us to share legacy IRQs of such devices with other host devices
when passing them to a guest.
The new IRQ sharing feature introduced here is optional, user
- Original Message -
On 2012-02-29 14:30, Amos Kong wrote:
kvm_io_bus devices are used for ioevent, pit, pic, ioapic,
coalesced_mmio.
Currently Qemu only emulates one PCI bus, it contains 32 slots,
one slot contains 8 functions, maximum of supported PCI devices:
1 * 32 * 8 =
On 2012-02-29 16:22, Amos Kong wrote:
- Original Message -
On 2012-02-29 14:30, Amos Kong wrote:
kvm_io_bus devices are used for ioevent, pit, pic, ioapic,
coalesced_mmio.
Currently Qemu only emulates one PCI bus, it contains 32 slots,
one slot contains 8 functions, maximum of
On 2012-02-29 16:22, Alex Williamson wrote:
On Tue, 2012-02-28 at 14:19 +0100, Jan Kiszka wrote:
PCI 2.3 allows to generically disable IRQ sources at device level. This
enables us to share legacy IRQs of such devices with other host devices
when passing them to a guest.
The new IRQ sharing
valgrind warns about padding fields which are passed
to vcpu ioctls uninitialized.
This is not an error in practice because kvm ignored padding.
Since the ioctls in question are off data path and
the cost is zero anyway, initialize padding to 0
to suppress these errors.
Signed-off-by: Michael S.
On Wed, 2012-02-29 at 16:38 +0100, Jan Kiszka wrote:
On 2012-02-29 16:22, Alex Williamson wrote:
On Tue, 2012-02-28 at 14:19 +0100, Jan Kiszka wrote:
PCI 2.3 allows to generically disable IRQ sources at device level. This
enables us to share legacy IRQs of such devices with other host
- Original Message -
On 2012-02-29 16:22, Amos Kong wrote:
- Original Message -
On 2012-02-29 14:30, Amos Kong wrote:
kvm_io_bus devices are used for ioevent, pit, pic, ioapic,
coalesced_mmio.
Currently Qemu only emulates one PCI bus, it contains 32 slots,
one slot
On 02/29/2012 03:57 PM, Joerg Roedel wrote:
It turned out that a performance counter on AMD does not
count at all when the GO or HO bit is set in the control
register and SVM is disabled in EFER.
This patch works around this issue by masking out the HO bit
in the performance counter control
On Wed, Feb 29, 2012 at 07:00:09PM +0200, Avi Kivity wrote:
On 02/29/2012 03:57 PM, Joerg Roedel wrote:
It turned out that a performance counter on AMD does not
count at all when the GO or HO bit is set in the control
register and SVM is disabled in EFER.
This patch works around this
On Wed, Feb 29, 2012 at 07:00:09PM +0200, Avi Kivity wrote:
On 02/29/2012 03:57 PM, Joerg Roedel wrote:
It turned out that a performance counter on AMD does not
count at all when the GO or HO bit is set in the control
register and SVM is disabled in EFER.
This patch works around this
On 02/29/2012 07:05 PM, Joerg Roedel wrote:
On Wed, Feb 29, 2012 at 07:00:09PM +0200, Avi Kivity wrote:
On 02/29/2012 03:57 PM, Joerg Roedel wrote:
It turned out that a performance counter on AMD does not
count at all when the GO or HO bit is set in the control
register and SVM is
On Wed, 2012-02-29 at 18:05 +0100, Joerg Roedel wrote:
Once northbridge counters are implemented for Fam15h this check can go
away again.
Nope, northbridge on fam15 is completely disjoint from the regular pmu
and should thus be a separate driver.
The only reason the old amd driver has them
On 2/29/2012 5:56 AM, Jamal Hadi Salim wrote:
On Tue, 2012-02-28 at 20:40 -0800, John Fastabend wrote:
OK back to this. The last piece is where to put these messages...
we could take PF_ROUTE:RTM_*NEIGH
PF_ROUTE:RTM_NEWNEIGH - Add a new FDB entry to an offloaded
On Wed, 2012-02-29 at 14:57 +0100, Joerg Roedel wrote:
diff --git a/arch/x86/kernel/cpu/perf_event.h
b/arch/x86/kernel/cpu/perf_event.h
index 8944062..2c581b9 100644
--- a/arch/x86/kernel/cpu/perf_event.h
+++ b/arch/x86/kernel/cpu/perf_event.h
@@ -148,6 +148,8 @@ struct cpu_hw_events {
On 02/28/2012 08:16 PM, Alexander Graf wrote:
When we know that we're running inside of a KVM guest, we don't have to
worry about synchronizing timebases between different CPUs, since the
host already took care of that.
This fixes CPU overcommit scenarios where vCPUs could hang forever
On Wed, 29 Feb 2012 09:25:56 -0800
John Fastabend john.r.fastab...@intel.com wrote:
On 2/29/2012 5:56 AM, Jamal Hadi Salim wrote:
On Tue, 2012-02-28 at 20:40 -0800, John Fastabend wrote:
OK back to this. The last piece is where to put these messages...
we could take PF_ROUTE:RTM_*NEIGH
On 2/29/2012 9:52 AM, Stephen Hemminger wrote:
On Wed, 29 Feb 2012 09:25:56 -0800
John Fastabend john.r.fastab...@intel.com wrote:
On 2/29/2012 5:56 AM, Jamal Hadi Salim wrote:
On Tue, 2012-02-28 at 20:40 -0800, John Fastabend wrote:
OK back to this. The last piece is where to put these
On 29.02.2012, at 18:50, Scott Wood scottw...@freescale.com wrote:
On 02/28/2012 08:16 PM, Alexander Graf wrote:
When we know that we're running inside of a KVM guest, we don't have to
worry about synchronizing timebases between different CPUs, since the
host already took care of that.
On Wed, 29 Feb 2012 03:11:24 +
Hao, Xudong xudong@intel.com wrote:
For IvyBridge Mobile platform, a system hang may occur if a
FLR(Function Level Reset) is asserted to internal graphics.
This quirk patch is workaround for the IVB FLR errata issue.
We are disabling the FLR reset
On 02/29/2012 12:28 PM, Alexander Graf wrote:
On 29.02.2012, at 18:50, Scott Wood scottw...@freescale.com wrote:
On 02/28/2012 08:16 PM, Alexander Graf wrote:
When we know that we're running inside of a KVM guest, we don't have to
worry about synchronizing timebases between different
On Thu, 2012-02-02 at 12:24 +1100, David Gibson wrote:
On Wed, Feb 01, 2012 at 01:08:39PM -0700, Alex Williamson wrote:
On Wed, 2012-02-01 at 15:46 +1100, David Gibson wrote:
This patch series introduces a new infrastructure to the driver core
for representing device isolation groups.
-Original Message-
From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
Sent: Thursday, March 01, 2012 2:32 AM
To: Hao, Xudong
Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org;
kvm@vger.kernel.org; Kay, Allen M; Zhang, Xiantao
Subject: Re: [PATCH V2] Quirk for IVB
From: Liu Yu yu@freescale.com
So that we can call it when improving SPE switch like book3e did for fp switch.
Signed-off-by: Liu Yu yu@freescale.com
Signed-off-by: Olivia Yin hong-hua@freescale.com
---
v2: add Signed-off-by
arch/powerpc/kernel/head_fsl_booke.S | 23
From: Liu Yu yu@freescale.com
Like book3s did for fp switch,
instead of switch SPE between host and guest,
the patch switch SPE state between qemu and guest.
In this way, we can simulate a host loadup SPE when load guest SPE state,
and let host to decide when to giveup SPE state.
Therefor it
At 02/29/2012 06:39 PM, Avi Kivity Wrote:
On 02/29/2012 12:17 PM, Wen Congyang wrote:
Yes, crash can be so severe that it is not even detected by a kernel
itself, so not OOPS message even printed. But in most cases if kernel is
functional enough to print OOPS it is functional enough to call
For IvyBridge Mobile platform, a system hang may occur if a FLR(Function Level
Reset) is asserted to internal graphics.
This quirk patch is workaround for the IVB FLR errata issue.
We are disabling the FLR reset handshake between the PCH and CPU display, then
manually powering down the panel
On 01/03/12 00:34, Amos Kong wrote:
- Original Message -
On 2012-02-29 16:22, Amos Kong wrote:
- Original Message -
On 2012-02-29 14:30, Amos Kong wrote:
kvm_io_bus devices are used for ioevent, pit, pic, ioapic,
coalesced_mmio.
Currently Qemu only emulates one PCI bus, it
At 02/29/2012 06:39 PM, Avi Kivity Wrote:
On 02/29/2012 12:17 PM, Wen Congyang wrote:
Yes, crash can be so severe that it is not even detected by a kernel
itself, so not OOPS message even printed. But in most cases if kernel is
functional enough to print OOPS it is functional enough to call
kvm_io_bus devices are used for ioevent, pit, pic, ioapic,
coalesced_mmio.
Currently Qemu only emulates one PCI bus, it contains 32 slots,
one slot contains 8 functions, maximum of supported PCI devices:
1 * 32 * 8 = 256. One virtio-blk takes one iobus device,
one virtio-net(vhost=on) takes two
On 02/28/2012 08:16 PM, Alexander Graf wrote:
When we know that we're running inside of a KVM guest, we don't have to
worry about synchronizing timebases between different CPUs, since the
host already took care of that.
This fixes CPU overcommit scenarios where vCPUs could hang forever
On 29.02.2012, at 18:50, Scott Wood scottw...@freescale.com wrote:
On 02/28/2012 08:16 PM, Alexander Graf wrote:
When we know that we're running inside of a KVM guest, we don't have to
worry about synchronizing timebases between different CPUs, since the
host already took care of that.
On 02/29/2012 12:28 PM, Alexander Graf wrote:
On 29.02.2012, at 18:50, Scott Wood scottw...@freescale.com wrote:
On 02/28/2012 08:16 PM, Alexander Graf wrote:
When we know that we're running inside of a KVM guest, we don't have to
worry about synchronizing timebases between different
From: Liu Yu yu@freescale.com
So that we can call it when improving SPE switch like book3e did for fp switch.
Signed-off-by: Liu Yu yu@freescale.com
Signed-off-by: Olivia Yin hong-hua@freescale.com
---
v2: add Signed-off-by
arch/powerpc/kernel/head_fsl_booke.S | 23
From: Liu Yu yu@freescale.com
Like book3s did for fp switch,
instead of switch SPE between host and guest,
the patch switch SPE state between qemu and guest.
In this way, we can simulate a host loadup SPE when load guest SPE state,
and let host to decide when to giveup SPE state.
Therefor it
79 matches
Mail list logo
