> > Considering the following when the same seabios code snippet:
> >
> >pci_config_writeb(0x31): bdf: 0x pam: 0x005b
> >
> > is executed to mark an pc.ram area 0xc as readonly:
> >
> > Entering vhost_begin
> > Entering vhost_region_del section: 0
Currently, vs->vs_endpoint is used indicate if the endpoint is setup or
not. It is set or cleared in vhost_scsi_set_endpoint() or
vhost_scsi_clear_endpoint() under the vs->dev.mutex lock. However, when
we check it in vhost_scsi_handle_vq(), we ignored the lock.
Instead of using the vs->vs_endpoint
This patch fixes guest hang when booting seabios and guest.
[0.576238] scsi0 : Virtio SCSI HBA
[0.616754] virtio_scsi virtio1: request:id 0 is not a head!
vq->last_used_idx is initialized only when /dev/vhost-scsi is
opened or closed.
vhost_scsi_open -> vhost_dev_init() -> vhost_v
Hello mst,
How about this one?
Asias He (2):
tcm_vhost: Use vq->private_data to indicate if the endpoint is setup
tcm_vhost: Initialize vq->last_used_idx when set endpoint
drivers/vhost/tcm_vhost.c | 145 --
1 file changed, 102 insertions(+), 43 d
On Tue, Apr 02, 2013 at 06:18:33PM +0300, Michael S. Tsirkin wrote:
> 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:
The CVE-2013-1796
(https://git.kernel.org/cgit/virt/kvm/kvm.git/commit/?id=c300aa64ddf57d9c5d9c898a64b36877345dd4a9)
reports a possibility of host memory corruption.
I see that this could lead into corruption of guest kernel memory,
but how could be the wrong aligned address reported by guest corru
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, Nicho
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
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,
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
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
> > wrote:
> > > >> >C. Explicit mapping using normal DMA map. The last idea
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
> > > >
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 f
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 capabil
Hi,
Thank you for testing the patch.
Yangminqiang 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 argument
>
> So I w
Hi,
Thank you for testing the patch.
Yangminqiang 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 argument
>
> So I w
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 n
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 late
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
---
arch/powerpc/kvm/mpic.c | 445 ++-
1 file chan
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
---
v3: mpic_put -> kvmppc_mpic_put
Documentation/virtual/kvm/devices/mpic.txt | 37 ++
arch/powerpc/include/asm/kvm_host.h
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 associat
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
---
arch/powerpc/kvm/mpic.c | 344 ---
1 file changed, 344 deletions(-)
di
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
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 ff71541..ed033
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/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 nee
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 infl
From: Yang Zhang
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
---
arch/x86/kvm/lapic.c | 47 ---
queue.c:4204
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] [] warn_slowpath_common+0x8b/0xc0
[6.766436] [] warn_
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, in
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_cm
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
> >
> > Hi folks,
> >
> > This series adds a virtio_queue_valid() for use by virtio-pci code in
> > order to prevent opreations upon
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
wrote:
> >> >C. Explicit mapping using normal DMA map. The last idea
is that
> >> >we would introduce a new ioctl to give user-s
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
MS
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 ho
On 04/02/2013 04:08:27 PM, Stuart Yoder wrote:
On Tue, Apr 2, 2013 at 3:57 PM, Scott Wood
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 wou
On Tue, 2013-04-02 at 16:08 -0500, Stuart Yoder wrote:
> On Tue, Apr 2, 2013 at 3:57 PM, Scott Wood 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, which could be
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
> > >
On Tue, 2013-04-02 at 15:54 -0500, Stuart Yoder wrote:
> On Tue, Apr 2, 2013 at 3:32 PM, Alex Williamson
> 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 t
On Tue, Apr 2, 2013 at 3:57 PM, Scott Wood 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? What assumption
On Tue, Apr 2, 2013 at 3:47 PM, Scott Wood wrote:
> On 04/02/2013 03:38:42 PM, Stuart Yoder wrote:
>>
>> On Tue, Apr 2, 2013 at 2:39 PM, Scott Wood
>> wrote:
>> > On 04/02/2013 12:32:00 PM, Yoder Stuart-B08248 wrote:
>> >>
>> >> Alex,
>> >>
>> >> We are in the process of implementing vfio-pci sup
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
>
On Tue, Apr 2, 2013 at 3:32 PM, Alex Williamson
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 driver can alloc
On 04/02/2013 03:38:42 PM, Stuart Yoder wrote:
On Tue, Apr 2, 2013 at 2:39 PM, Scott Wood
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
On Tue, Apr 2, 2013 at 2:39 PM, Scott Wood 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, and will i
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 implemen
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 devic
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
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
o
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 fiel
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: A
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 chan
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 vs->vs_tp
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:
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:
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
> -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 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
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
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
---
arch/arm/include/asm/idmap.h | 1 -
arch/arm/include/asm/kvm_mmu.h | 1 -
arch/a
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
---
arch/arm/include/
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
---
arch/arm/kernel/vmlinux.lds.S | 2 +-
arch/arm/kvm
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 co
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
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 around
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 ke
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.
Sign
Juan Quintela 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 majordomo info at ht
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
On Tue, Apr 02, 2013 at 09:27:57AM +1030, Rusty Russell wrote:
> "Michael S. Tsirkin" 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 fixed in
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
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:
On Mon, Apr 01, 2013 at 11:58:21PM +, Nicholas A. Bellinger wrote:
> From: Nicholas Bellinger
>
> 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 during seabios se
On Mon, Apr 01, 2013 at 12:42:33AM +, Zhang, Yang Z wrote:
> Zhang, Yang Z wrote on 2013-03-21:
> > From: Yang Zhang
> >
> > 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_
On Mon, Mar 25, 2013 at 02:14:20PM -0700, Kevin Hilman wrote:
> Gleb Natapov writes:
>
> > On Sun, Mar 24, 2013 at 02:44:26PM +0100, Frederic Weisbecker wrote:
> >> 2013/3/21 Gleb Natapov :
> >> > Isn't is simpler for kernel/context_tracking.c to define empty
> >> > __guest_enter()/__guest_exit()
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
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
Giridhar Maruthy wrote:
>
> Exynos5440 has GIC which has virtualization support
> in them. These are used by KVM.
>
> Signed-off-by: Giridhar Maruthy
> ---
> arch/arm/boot/dts/exynos5440.dtsi |6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exy
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 the
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? o
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-R
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
>> Bhara
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
83 matches
Mail list logo
