On 04/02/2013 06:47 AM, Scott Wood wrote:
Currently, devices that are emulated inside KVM are configured in a
hardcoded manner based on an assumption that any given architecture
only has one way to do it. If there's any need to access device state,
it is done through inflexible one-purpose-only
On 29.03.2013, at 07:04, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Thursday, March 28, 2013 10:06 PM
To: Bhushan Bharat-R65777
Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; Wood Scott-B07421; Bhushan
Bharat-R65777
On 29.03.2013, at 04:08, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Friday, March 29, 2013 7:26 AM
To: Bhushan Bharat-R65777
Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; Wood Scott-B07421; Bhushan
Bharat-R65777
Hi Tomoki
I tried your smart patch cpu isolation and direct interrupt delivery,
http://article.gmane.org/gmane.linux.kernel/1353803
got output when I run qemu
kvm_set_slave_cpu: Invalid argument
So I wonder
* Did I misuse your patches?
* How is the offlined CPU assigned? or
Hi list,
I've just started doing some research into VM memory allocation, and
I've got a few questions about how KVM performs memory translations
from guest to host, using Intel-VT extensions. My questions relate to
the implementation of Intel EPTs.
I've put in a few printk statements within
Giridhar Maruthy wrote:
Exynos5440 has GIC which has virtualization support
in them. These are used by KVM.
Signed-off-by: Giridhar Maruthy giridha...@samsung.com
---
arch/arm/boot/dts/exynos5440.dtsi |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
Alexander Graf wrote:
When running on an exynos 5250 SoC, we don't initialize the architected
timers. The chip however supports architected timers.
Yes, exynos5250 can support, mct(multi core timer) is used though.
When we don't initialize them, KVM will try to access them and run into
On 04/02/2013 12:44 PM, Kukjin Kim wrote:
Alexander Graf wrote:
When running on an exynos 5250 SoC, we don't initialize the architected
timers. The chip however supports architected timers.
Yes, exynos5250 can support, mct(multi core timer) is used though.
When we don't initialize them, KVM
On Mon, Mar 25, 2013 at 02:14:20PM -0700, Kevin Hilman wrote:
Gleb Natapov g...@redhat.com writes:
On Sun, Mar 24, 2013 at 02:44:26PM +0100, Frederic Weisbecker wrote:
2013/3/21 Gleb Natapov g...@redhat.com:
Isn't is simpler for kernel/context_tracking.c to define empty
On Mon, Apr 01, 2013 at 12:42:33AM +, Zhang, Yang Z wrote:
Zhang, Yang Z wrote on 2013-03-21:
From: Yang Zhang yang.z.zh...@intel.com
For a given vcpu, kvm_apic_match_dest() will tell you whether
the vcpu in the destination list quickly. Drop kvm_calculate_eoi_exitmap()
and use
On Mon, Apr 01, 2013 at 11:58:21PM +, Nicholas A. Bellinger wrote:
From: Nicholas Bellinger n...@linux-iscsi.org
Hi folks,
This series adds a virtio_queue_valid() for use by virtio-pci code in
order to prevent opreations upon uninitialized VQs, which is currently
expected to occur
On Mon, Apr 01, 2013 at 10:13:47AM +0800, Asias He wrote:
On Sun, Mar 31, 2013 at 11:20:24AM +0300, Michael S. Tsirkin wrote:
On Fri, Mar 29, 2013 at 02:22:52PM +0800, Asias He wrote:
On Thu, Mar 28, 2013 at 11:18:22AM +0200, Michael S. Tsirkin wrote:
On Thu, Mar 28, 2013 at 04:10:02PM
On Fri, Mar 29, 2013 at 03:25:16AM +, Zhang, Yang Z wrote:
Paolo Bonzini wrote on 2013-03-26:
Il 22/03/2013 06:24, Yang Zhang ha scritto:
+static void rtc_irq_ack_eoi(struct kvm_vcpu *vcpu,
+ struct rtc_status *rtc_status, int irq)
+{
+ if (irq != RTC_GSI)
+
On Tue, Apr 02, 2013 at 09:27:57AM +1030, Rusty Russell wrote:
Michael S. Tsirkin m...@redhat.com writes:
Rusty's currently doing some reorgs of -net let's delay
cleanups there to avoid stepping on each other's toys.
Let's focus on scsi here.
E.g. any chance framing assumptions can be
On Mon, Mar 25, 2013 at 05:22:47PM +0100, Cornelia Huck wrote:
Hi,
here are some kvm/s390 patches that have accumulated in our queue.
Changes include fixes in the lpsw(e) and stsi handlers, proper
handling of interrupt injection failures and a gmap optimization.
Also included are
Juan Quintela quint...@redhat.com wrote:
Hi
Please send in any agenda topics you are interested in.
As there are no items, today call is cancelled.
Happy hacking.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More
The current code for creating HYP mapping doesn't like to wrap
around zero, which prevents from mapping anything into the last
page of the virtual address space.
It doesn't take much effort to remove this limitation, making
the code more consistent with the rest of the kernel in the process.
Our HYP init code suffers from two major design issues:
- it cannot support CPU hotplug, as we tear down the idmap very early
- it cannot perform a TLB invalidation when switching from init to
runtime mappings, as pages are manipulated from PL1 exclusively
The hotplug problem mandates that we
The way we populate HYP mappings is a bit convoluted, to say the least.
Passing a pointer around to keep track of the current PFN is quite
odd, and we end-up having two different PTE accessors for no good
reason.
Simplify the whole thing by unifying the two PTE accessors, passing
a pgprot_t
Now that we have the necessary infrastructure to boot a hotplugged CPU
at any point in time, wire a CPU notifier that will perform the HYP
init for the incoming CPU.
Note that this depends on the platform code and/or firmware to boot the
incoming CPU with HYP mode enabled and return to the kernel
Over the past few weeks, I've gradually realized how broken our HYP
idmap code is. Badly broken.
The main problem is about supporting CPU hotplug. Imagine a CPU being
initialized normally, running VMs, and then being powered down. So
far, so good. Now mentally bring it back online. The CPU will
In order to prepare for having to deal with multiple HYP page tables,
pass the PGD parameter to the function performing the freeing of the
page tables.
Also move the freeing of the PGD itself there, and rename the
free_hyp_pmds to free_hyp_pgds.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
We're about to move to a init procedure where we rely on the
fact that the init code fits in a single page. Make sure we
align the idmap text on a page boundary, and that the code is
not bigger than a single page.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/kernel/vmlinux.lds.S
After the HYP page table rework, it is pretty easy to let the KVM
code provide its own idmap, rather than expecting the kernel to
provide it. It takes actually less code to do so.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/include/asm/idmap.h | 1 -
On Mon, Apr 01, 2013 at 06:05:47PM -0700, Nicholas A. Bellinger wrote:
On Fri, 2013-03-29 at 09:14 +0100, Paolo Bonzini wrote:
Il 29/03/2013 03:53, Nicholas A. Bellinger ha scritto:
On Thu, 2013-03-28 at 06:13 -0400, Paolo Bonzini wrote:
I think it's the right thing to do, but maybe not
On Fri, Mar 22, 2013 at 09:37:16PM +0100, Paolo Bonzini wrote:
Now that we have a CPU object with a reset method, it is better to
keep the KVM reset close to the CPU reset. Using qemu_register_reset
as we do now keeps them far apart.
As a side effect, a CPU reset (cpu_reset) will reset the
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, April 02, 2013 1:57 PM
To: Bhushan Bharat-R65777
Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; Wood Scott-B07421
Subject: Re: [PATCH 4/4 v2] KVM: PPC: Add userspace debug stub support
On
On Thu, Mar 28, 2013 at 05:18:35PM +0100, Paolo Bonzini wrote:
In order to migrate the PMU state correctly, we need to restore the
values of MSR_CORE_PERF_GLOBAL_STATUS (a read-only register) and
MSR_CORE_PERF_GLOBAL_OVF_CTRL (which has side effects when written).
We also need to write the
On Tue, Apr 02, 2013 at 03:15:31PM +0300, Michael S. Tsirkin wrote:
On Mon, Apr 01, 2013 at 10:13:47AM +0800, Asias He wrote:
On Sun, Mar 31, 2013 at 11:20:24AM +0300, Michael S. Tsirkin wrote:
On Fri, Mar 29, 2013 at 02:22:52PM +0800, Asias He wrote:
On Thu, Mar 28, 2013 at 11:18:22AM
On Tue, Apr 02, 2013 at 11:10:02PM +0800, Asias He wrote:
On Tue, Apr 02, 2013 at 03:15:31PM +0300, Michael S. Tsirkin wrote:
On Mon, Apr 01, 2013 at 10:13:47AM +0800, Asias He wrote:
On Sun, Mar 31, 2013 at 11:20:24AM +0300, Michael S. Tsirkin wrote:
On Fri, Mar 29, 2013 at 02:22:52PM
In vhost_scsi_handle_vq:
tv_tpg = vs-vs_tpg[target];
if (!tv_tpg) {
return
}
tv_cmd = vhost_scsi_allocate_cmd(tv_tpg, v_req,
1) vs-vs_tpg[target] might change after the NULL check and 2) the above
line might access tv_tpg from
On Tue, Apr 02, 2013 at 11:31:37PM +0800, Asias He wrote:
In vhost_scsi_handle_vq:
tv_tpg = vs-vs_tpg[target];
if (!tv_tpg) {
return
}
tv_cmd = vhost_scsi_allocate_cmd(tv_tpg, v_req,
1) vs-vs_tpg[target] might change after the
On 04/02/2013 04:09 PM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, April 02, 2013 1:57 PM
To: Bhushan Bharat-R65777
Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; Wood Scott-B07421
Subject: Re: [PATCH 4/4 v2] KVM: PPC:
We use the vfp_host pointer to store the host VFP context, should
the guest start using VFP itself.
Actually, we can use this pointer in a more generic way to store
CPU speficic data, and arm64 is using it to dump the whole host
state before switching to the guest.
Simply rename the vfp_host
Alex,
We are in the process of implementing vfio-pci support for the Freescale
IOMMU (PAMU). It is an aperture/window-based IOMMU and is quite different
than x86, and will involve creating a 'type 2' vfio implementation.
For each device's DMA mappings, PAMU has an overall aperture and a number
On 04/02/2013 09:09:34 AM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, April 02, 2013 1:57 PM
To: Bhushan Bharat-R65777
Cc: kvm-...@vger.kernel.org; kvm@vger.kernel.org; Wood Scott-B07421
Subject: Re: [PATCH 4/4 v2]
On 04/02/2013 12:32:00 PM, Yoder Stuart-B08248 wrote:
Alex,
We are in the process of implementing vfio-pci support for the
Freescale
IOMMU (PAMU). It is an aperture/window-based IOMMU and is quite
different
than x86, and will involve creating a 'type 2' vfio implementation.
For each
Hi Stuart,
On Tue, 2013-04-02 at 17:32 +, Yoder Stuart-B08248 wrote:
Alex,
We are in the process of implementing vfio-pci support for the Freescale
IOMMU (PAMU). It is an aperture/window-based IOMMU and is quite different
than x86, and will involve creating a 'type 2' vfio
On Tue, Apr 2, 2013 at 2:39 PM, Scott Wood scottw...@freescale.com wrote:
On 04/02/2013 12:32:00 PM, Yoder Stuart-B08248 wrote:
Alex,
We are in the process of implementing vfio-pci support for the Freescale
IOMMU (PAMU). It is an aperture/window-based IOMMU and is quite different
than x86,
On 04/02/2013 03:38:42 PM, Stuart Yoder wrote:
On Tue, Apr 2, 2013 at 2:39 PM, Scott Wood scottw...@freescale.com
wrote:
On 04/02/2013 12:32:00 PM, Yoder Stuart-B08248 wrote:
Alex,
We are in the process of implementing vfio-pci support for the
Freescale
IOMMU (PAMU). It is an
On Tue, Apr 2, 2013 at 3:32 PM, Alex Williamson
alex.william...@redhat.com wrote:
2. MSI window mappings
The more problematic question is how to deal with MSIs. We need to
create mappings for up to 3 MSI banks that a device may need to target
to generate interrupts. The Linux MSI
On 04/02/2013 03:32:17 PM, Alex Williamson wrote:
On Tue, 2013-04-02 at 17:32 +, Yoder Stuart-B08248 wrote:
2. MSI window mappings
The more problematic question is how to deal with MSIs. We need
to
create mappings for up to 3 MSI banks that a device may need to
target
to
On Tue, Apr 2, 2013 at 3:47 PM, Scott Wood scottw...@freescale.com wrote:
On 04/02/2013 03:38:42 PM, Stuart Yoder wrote:
On Tue, Apr 2, 2013 at 2:39 PM, Scott Wood scottw...@freescale.com
wrote:
On 04/02/2013 12:32:00 PM, Yoder Stuart-B08248 wrote:
Alex,
We are in the process of
On Tue, Apr 2, 2013 at 3:57 PM, Scott Wood scottw...@freescale.com wrote:
This could also be done as another type2 ioctl extension.
Again, what is type2, specifically? If someone else is adding their own
IOMMU that is kind of, sort of like PAMU, how would they know if it's close
enough?
On Tue, 2013-04-02 at 15:54 -0500, Stuart Yoder wrote:
On Tue, Apr 2, 2013 at 3:32 PM, Alex Williamson
alex.william...@redhat.com wrote:
2. MSI window mappings
The more problematic question is how to deal with MSIs. We need to
create mappings for up to 3 MSI banks that a device
On Tue, 2013-04-02 at 15:57 -0500, Scott Wood wrote:
On 04/02/2013 03:32:17 PM, Alex Williamson wrote:
On Tue, 2013-04-02 at 17:32 +, Yoder Stuart-B08248 wrote:
2. MSI window mappings
The more problematic question is how to deal with MSIs. We need
to
create mappings
On Tue, 2013-04-02 at 16:08 -0500, Stuart Yoder wrote:
On Tue, Apr 2, 2013 at 3:57 PM, Scott Wood scottw...@freescale.com wrote:
C. Explicit mapping using normal DMA map. The last idea is that
we would introduce a new ioctl to give user-space an fd to
the MSI bank,
On 04/02/2013 04:08:27 PM, Stuart Yoder wrote:
On Tue, Apr 2, 2013 at 3:57 PM, Scott Wood scottw...@freescale.com
wrote:
This could also be done as another type2 ioctl extension.
Again, what is type2, specifically? If someone else is adding
their own
IOMMU that is kind of, sort of like
On 04/02/2013 04:16:11 PM, Alex Williamson wrote:
On Tue, 2013-04-02 at 15:54 -0500, Stuart Yoder wrote:
The number of windows is always power of 2 (and max is 256). And
to reduce
PAMU cache pressure you want to use the fewest number of windows
you can.So, I don't see practically how
On 04/02/2013 04:32:04 PM, Alex Williamson wrote:
On Tue, 2013-04-02 at 15:57 -0500, Scott Wood wrote:
On 04/02/2013 03:32:17 PM, Alex Williamson wrote:
On x86 the interrupt remapper handles this transparently when MSI
is enabled and userspace never gets direct access to the device
MSI
On 04/02/2013 04:38:45 PM, Alex Williamson wrote:
On Tue, 2013-04-02 at 16:08 -0500, Stuart Yoder wrote:
On Tue, Apr 2, 2013 at 3:57 PM, Scott Wood
scottw...@freescale.com wrote:
C. Explicit mapping using normal DMA map. The last idea
is that
we would introduce a new ioctl
On Tue, 2013-04-02 at 15:01 +0300, Michael S. Tsirkin wrote:
On Mon, Apr 01, 2013 at 11:58:21PM +, Nicholas A. Bellinger wrote:
From: Nicholas Bellinger n...@linux-iscsi.org
Hi folks,
This series adds a virtio_queue_valid() for use by virtio-pci code in
order to prevent
On Tue, 2013-04-02 at 18:39 +0300, Michael S. Tsirkin wrote:
On Tue, Apr 02, 2013 at 11:31:37PM +0800, Asias He wrote:
In vhost_scsi_handle_vq:
tv_tpg = vs-vs_tpg[target];
if (!tv_tpg) {
return
}
tv_cmd =
Gleb Natapov wrote on 2013-04-02:
On Fri, Mar 29, 2013 at 03:25:16AM +, Zhang, Yang Z wrote:
Paolo Bonzini wrote on 2013-03-26:
Il 22/03/2013 06:24, Yang Zhang ha scritto:
+static void rtc_irq_ack_eoi(struct kvm_vcpu *vcpu,
+ struct rtc_status *rtc_status, int irq)
+{
+
destroy_workqueue+0x1df/0x3d0()
[6.764507] Modules linked in:
[6.764792] Pid: 1, comm: swapper/0 Tainted: GW
3.9.0-rc5-next-20130402-sasha-00015-g3522ec5 #324
[6.765654] Call Trace:
[6.765875] [811074fb] warn_slowpath_common+0x8b/0xc0
[6.766436] [81107545
From: Yang Zhang yang.z.zh...@intel.com
For a given vcpu, kvm_apic_match_dest() will tell you whether
the vcpu in the destination list quickly. Drop kvm_calculate_eoi_exitmap()
and use kvm_apic_match_dest() instead.
Signed-off-by: Yang Zhang yang.z.zh...@intel.com
---
arch/x86/kvm/lapic.c |
On Mon, Apr 01, 2013 at 05:47:48PM -0500, Scott Wood wrote:
Currently, devices that are emulated inside KVM are configured in a
hardcoded manner based on an assumption that any given architecture
only has one way to do it. If there's any need to access device state,
it is done through
On 04/02/2013 08:02:39 PM, Paul Mackerras wrote:
On Mon, Apr 01, 2013 at 05:47:48PM -0500, Scott Wood wrote:
Currently, devices that are emulated inside KVM are configured in a
hardcoded manner based on an assumption that any given architecture
only has one way to do it. If there's any need
On 04/03/2013 01:30 AM, Scott Wood wrote:
On 04/02/2013 01:59:57 AM, tiejun.chen wrote:
On 04/02/2013 06:47 AM, Scott Wood wrote:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index ff71541..ed033c0 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2158,6 +2158,17 @@ out:
On 04/03/2013 09:34 AM, Scott Wood wrote:
On 04/02/2013 08:28:01 PM, tiejun.chen wrote:
On 04/03/2013 01:30 AM, Scott Wood wrote:
On 04/02/2013 01:59:57 AM, tiejun.chen wrote:
On 04/02/2013 06:47 AM, Scott Wood wrote:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index
Fixed some patch shuffling errors and some minor issues.
Scott Wood (6):
kvm: add device control API
kvm/ppc/mpic: import hw/openpic.c from QEMU
kvm/ppc/mpic: remove some obviously unneeded code
kvm/ppc/mpic: adapt to kernel style and environment
kvm/ppc/mpic: in-kernel MPIC emulation
Remove some parts of the code that are obviously QEMU or Raven specific
before fixing style issues, to reduce the style issues that need to be
fixed.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/kvm/mpic.c | 344 ---
1 file
Enabling this capability connects the vcpu to the designated in-kernel
MPIC. Using explicit connections between vcpus and irqchips allows
for flexibility, but the main benefit at the moment is that it
simplifies the code -- KVM doesn't need vm-global state to remember
which MPIC object is
Hook the MPIC code up to the KVM interfaces, add locking, etc.
TODO: irqfd support, split up into multiple patches, KVM_IRQ_LINE
support
Signed-off-by: Scott Wood scottw...@freescale.com
---
v3: mpic_put - kvmppc_mpic_put
Documentation/virtual/kvm/devices/mpic.txt | 37 ++
Remove braces that Linux style doesn't permit, remove space after
'*' that Lindent added, keep error/debug strings contiguous, etc.
Substitute type names, debug prints, etc.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/kvm/mpic.c | 445
This is QEMU's hw/openpic.c from commit
abd8d4a4d6dfea7ddea72f095f993e1de941614e (Update version for
1.4.0-rc0), run through Lindent with no other changes to ease merging
future changes between Linux and QEMU. Remaining style issues
(including those introduced by Lindent) will be fixed in a later
Currently, devices that are emulated inside KVM are configured in a
hardcoded manner based on an assumption that any given architecture
only has one way to do it. If there's any need to access device state,
it is done through inflexible one-purpose-only IOCTLs (e.g.
KVM_GET/SET_LAPIC). Defining
Hi,
Thank you for testing the patch.
Yangminqiang yangminqi...@huawei.com wrote:
Hi Tomoki
I tried your smart patch cpu isolation and direct interrupt delivery,
http://article.gmane.org/gmane.linux.kernel/1353803
got output when I run qemu
kvm_set_slave_cpu: Invalid
Hi,
Thank you for testing the patch.
Yangminqiang yangminqi...@huawei.com wrote:
Hi Tomoki
I tried your smart patch cpu isolation and direct interrupt delivery,
http://article.gmane.org/gmane.linux.kernel/1353803
got output when I run qemu
kvm_set_slave_cpu: Invalid
On Tue, Apr 02, 2013 at 08:19:56PM -0500, Scott Wood wrote:
On 04/02/2013 08:02:39 PM, Paul Mackerras wrote:
On Mon, Apr 01, 2013 at 05:47:48PM -0500, Scott Wood wrote:
+4.79 KVM_CREATE_DEVICE
+
+Capability: KVM_CAP_DEVICE_CTRL
I notice this patch doesn't add this capability;
Yes, it
On Tue, 2013-04-02 at 17:13 -0500, Scott Wood wrote:
On 04/02/2013 04:16:11 PM, Alex Williamson wrote:
On Tue, 2013-04-02 at 15:54 -0500, Stuart Yoder wrote:
The number of windows is always power of 2 (and max is 256). And
to reduce
PAMU cache pressure you want to use the fewest
On Tue, 2013-04-02 at 17:44 -0500, Scott Wood wrote:
On 04/02/2013 04:32:04 PM, Alex Williamson wrote:
On Tue, 2013-04-02 at 15:57 -0500, Scott Wood wrote:
On 04/02/2013 03:32:17 PM, Alex Williamson wrote:
On x86 the interrupt remapper handles this transparently when MSI
is enabled
On Tue, 2013-04-02 at 17:50 -0500, Scott Wood wrote:
On 04/02/2013 04:38:45 PM, Alex Williamson wrote:
On Tue, 2013-04-02 at 16:08 -0500, Stuart Yoder wrote:
On Tue, Apr 2, 2013 at 3:57 PM, Scott Wood
scottw...@freescale.com wrote:
C. Explicit mapping using normal DMA map. The
On Wed, Apr 03, 2013 at 12:21:05AM +, Zhang, Yang Z wrote:
Gleb Natapov wrote on 2013-04-02:
On Fri, Mar 29, 2013 at 03:25:16AM +, Zhang, Yang Z wrote:
Paolo Bonzini wrote on 2013-03-26:
Il 22/03/2013 06:24, Yang Zhang ha scritto:
+static void rtc_irq_ack_eoi(struct kvm_vcpu
On Tue, 2013-04-02 at 16:27 +0300, Michael S. Tsirkin wrote:
On Mon, Apr 01, 2013 at 06:05:47PM -0700, Nicholas A. Bellinger wrote:
On Fri, 2013-03-29 at 09:14 +0100, Paolo Bonzini wrote:
Il 29/03/2013 03:53, Nicholas A. Bellinger ha scritto:
On Thu, 2013-03-28 at 06:13 -0400, Paolo
Alexander Graf wrote:
On 04/02/2013 12:44 PM, Kukjin Kim wrote:
Alexander Graf wrote:
When running on an exynos 5250 SoC, we don't initialize the architected
timers. The chip however supports architected timers.
Yes, exynos5250 can support, mct(multi core timer) is used though.
On Tue, 2013-04-02 at 21:04 -0700, Nicholas A. Bellinger wrote:
On Tue, 2013-04-02 at 16:27 +0300, Michael S. Tsirkin wrote:
On Mon, Apr 01, 2013 at 06:05:47PM -0700, Nicholas A. Bellinger wrote:
On Fri, 2013-03-29 at 09:14 +0100, Paolo Bonzini wrote:
Il 29/03/2013 03:53, Nicholas A.
On 04/02/2013 06:47 AM, Scott Wood wrote:
Currently, devices that are emulated inside KVM are configured in a
hardcoded manner based on an assumption that any given architecture
only has one way to do it. If there's any need to access device state,
it is done through inflexible one-purpose-only
On 29.03.2013, at 07:04, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Thursday, March 28, 2013 10:06 PM
To: Bhushan Bharat-R65777
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; Wood Scott-B07421; Bhushan
Bharat-R65777
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, April 02, 2013 1:57 PM
To: Bhushan Bharat-R65777
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; Wood Scott-B07421
Subject: Re: [PATCH 4/4 v2] KVM: PPC: Add userspace debug stub support
On
On 04/02/2013 04:09 PM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, April 02, 2013 1:57 PM
To: Bhushan Bharat-R65777
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; Wood Scott-B07421
Subject: Re: [PATCH 4/4 v2] KVM: PPC:
On 04/02/2013 09:09:34 AM, Bhushan Bharat-R65777 wrote:
-Original Message-
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Tuesday, April 02, 2013 1:57 PM
To: Bhushan Bharat-R65777
Cc: kvm-ppc@vger.kernel.org; k...@vger.kernel.org; Wood Scott-B07421
Subject: Re: [PATCH 4/4 v2]
On Mon, Apr 01, 2013 at 05:47:48PM -0500, Scott Wood wrote:
Currently, devices that are emulated inside KVM are configured in a
hardcoded manner based on an assumption that any given architecture
only has one way to do it. If there's any need to access device state,
it is done through
On 04/02/2013 08:02:39 PM, Paul Mackerras wrote:
On Mon, Apr 01, 2013 at 05:47:48PM -0500, Scott Wood wrote:
Currently, devices that are emulated inside KVM are configured in a
hardcoded manner based on an assumption that any given architecture
only has one way to do it. If there's any need
On 04/03/2013 01:30 AM, Scott Wood wrote:
On 04/02/2013 01:59:57 AM, tiejun.chen wrote:
On 04/02/2013 06:47 AM, Scott Wood wrote:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index ff71541..ed033c0 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2158,6 +2158,17 @@ out:
On 04/03/2013 09:34 AM, Scott Wood wrote:
On 04/02/2013 08:28:01 PM, tiejun.chen wrote:
On 04/03/2013 01:30 AM, Scott Wood wrote:
On 04/02/2013 01:59:57 AM, tiejun.chen wrote:
On 04/02/2013 06:47 AM, Scott Wood wrote:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index
Enabling this capability connects the vcpu to the designated in-kernel
MPIC. Using explicit connections between vcpus and irqchips allows
for flexibility, but the main benefit at the moment is that it
simplifies the code -- KVM doesn't need vm-global state to remember
which MPIC object is
Hook the MPIC code up to the KVM interfaces, add locking, etc.
TODO: irqfd support, split up into multiple patches, KVM_IRQ_LINE
support
Signed-off-by: Scott Wood scottw...@freescale.com
---
v3: mpic_put - kvmppc_mpic_put
Documentation/virtual/kvm/devices/mpic.txt | 37 ++
This is QEMU's hw/openpic.c from commit
abd8d4a4d6dfea7ddea72f095f993e1de941614e (Update version for
1.4.0-rc0), run through Lindent with no other changes to ease merging
future changes between Linux and QEMU. Remaining style issues
(including those introduced by Lindent) will be fixed in a later
Currently, devices that are emulated inside KVM are configured in a
hardcoded manner based on an assumption that any given architecture
only has one way to do it. If there's any need to access device state,
it is done through inflexible one-purpose-only IOCTLs (e.g.
KVM_GET/SET_LAPIC). Defining
On Tue, Apr 02, 2013 at 08:19:56PM -0500, Scott Wood wrote:
On 04/02/2013 08:02:39 PM, Paul Mackerras wrote:
On Mon, Apr 01, 2013 at 05:47:48PM -0500, Scott Wood wrote:
+4.79 KVM_CREATE_DEVICE
+
+Capability: KVM_CAP_DEVICE_CTRL
I notice this patch doesn't add this capability;
Yes, it
91 matches
Mail list logo
