On Tue, Feb 05, 2013 at 05:57:14AM +, Zhang, Yang Z wrote:
> Marcelo Tosatti wrote on 2013-02-05:
> > On Mon, Feb 04, 2013 at 05:59:52PM -0200, Marcelo Tosatti wrote:
> >> On Mon, Feb 04, 2013 at 07:13:01PM +0200, Gleb Natapov wrote:
> >>> On Mon, Feb 04, 2013 at 12:43:45PM -0200, Marcelo Tosat
On Sun, Feb 03, 2013 at 04:36:11PM +, Blue Swirl wrote:
> On Sun, Feb 3, 2013 at 2:10 PM, Pandarathil, Vijaymohan R
> wrote:
> > - Create eventfd per vfio device assigned to a guest and register an
> > event handler
> >
> > - This fd is passed to the vfio_pci driver t
We are upgrading, carefully, from 1.0 to 1.1.
We welcome the improved AC97 support and the loss of the ehci warning message
on startup.
I am finding an issue getting through to the monitor however.
Neither ctrl-alt-shift-2 nor ctrl-alt-2 exposes the monitor.
I have even tried using the -mon op
On Tue, Feb 05, 2013 at 02:55:07PM +0800, ya su wrote:
> I use the following cmd on rhel6.2 kernel 2.6.32-220.17.1:
> x86_64-softmmu/qemu-system-x86_64 -hda win8.img -cdrom
> window_8_pro.iso -m 2048 -L pc-bios -cpu host, it will display the
> following error:
> Your PC needs to restart.
> Please h
On Mon, Feb 04, 2013 at 11:24:01PM -0200, Marcelo Tosatti wrote:
> On Wed, Jan 30, 2013 at 04:45:05PM +0200, Gleb Natapov wrote:
> > This reverts commit bd4c86eaa6ff10abc4e00d0f45d2a28b10b09df4.
> >
> > There is not user for kvm_mmu_isolate_page() any more.
> >
> > Signed-off-by: Gleb Natapov
>
Veruca Salt writes:
> We are upgrading, carefully, from 1.0 to 1.1.
Keep going; we're about to release 1.4 ;)
> We welcome the improved AC97 support and the loss of the ehci warning
> message on startup.
>
> I am finding an issue getting through to the monitor however.
> Neither ctrl-alt-shift-
Current code has two ways to walk pte_list, the one is pte_list_walk and
the another way is rmap_get_first and rmap_get_next, they have the same logic.
This patchset tries to unify the code and also make the code more tidy.
Patch 1: KVM: MMU: introduce mmu_spte_establish, which tries to eliminates
There is little different between walking parent pte and walking ramp:
all spte in rmap must be present but this is not true on parent pte list,
in kvm_mmu_alloc_page, we always link the parent list before set the spte
to present
This patch introduce mmu_spte_establish which set the spte before li
In kvm_set_pte_rmapp, if the new mapping is writable, we need to remove
all spte pointing to that page otherwisewe we only need to adjust the sptes
to let them point to the new page. This patch clarifys the logic and makes
the later patch more clean
[ Impact: no logic changed ]
Signed-off-by: Xia
Current code has two ways to walk pte_list, the one is pte_list_walk and
the another way is rmap_get_first and rmap_get_next, they have the same logic.
This patch introduces for_each_spte_in_pte_list to integrate their code
[ Impact: no logic changed, most of the change is function/struct rename
PT_PRESENT_MASK bit is not enough to see the spte has already been mapped
into pte-list for mmio spte also set this bit. Use is_shadow_present_pte
instead to fix it
Also, this patch move many assertions to the common place to clean up the
code
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/mmu.
If a shadow page is being zapped or a host page is going to be freed, kvm
will drop all the reverse-mappings on the shadow page or the gfn. Currently,
it drops the reverse-mapping one by one - it deletes the first reverse mapping,
then moves other reverse-mapping between the description-table. When
Gleb:
would you pls tell where to find RHEL 6.4 kernel, as the current
latest office release is 6.3?
and would you figure out what the root cause that produce the problem?
thanks.
Regards.
Suya
2013/2/5 ya su :
> Gleb:
>
> would you pls tell where to find RHEL 6.4 kernel, as
On Tue, Feb 05, 2013 at 04:55:57PM +0800, ya su wrote:
> Gleb:
>
> would you pls tell where to find RHEL 6.4 kernel, as the current
> latest office release is 6.3?
>
> and would you figure out what the root cause that produce the problem?
>
> thanks.
>
Through your RHEL subscription
> -Original Message-
> From: Gleb Natapov [mailto:g...@redhat.com]
> Sent: Tuesday, February 05, 2013 12:05 AM
> To: Blue Swirl
> Cc: Pandarathil, Vijaymohan R; Alex Williamson; Bjorn Helgaas; Ortiz, Lance
> E; kvm@vger.kernel.org; qemu-de...@nongnu.org; linux-...@vger.kernel.org;
> linux
On Tue, Feb 05, 2013 at 03:11:09PM +0800, Xiao Guangrong wrote:
> Currently, kvm zaps the large spte if write-protected is needed, the later
> read can fault on that spte. Actually, we can make the large spte readonly
> instead of making them un-present, the page fault caused by read access can
> b
On Tue, Feb 05, 2013 at 09:05:19AM +, Pandarathil, Vijaymohan R wrote:
>
>
> > -Original Message-
> > From: Gleb Natapov [mailto:g...@redhat.com]
> > Sent: Tuesday, February 05, 2013 12:05 AM
> > To: Blue Swirl
> > Cc: Pandarathil, Vijaymohan R; Alex Williamson; Bjorn Helgaas; Ortiz,
> From: verucasal...@hotmail.co.uk
> To: arm...@redhat.com
> CC: kvm@vger.kernel.org
> Subject: RE: I may have found a bug(unlikely) with Qemu-kvm 1.1
> Date: Tue, 5 Feb 2013 09:19:13 +
>
>
> Thank you very much Markus.
> We were literally two minutes
Thank you very much Markus.
We were literally two minutes ahead, we've added a tty to -monitor so that a
function key exposes it; actually, this is better than the original qemu
monitor.
So now it's (say) -monitor /dev/tty2 and a simple ctrl-alt-f2 exposes a momitor
screen.
Sorry for the false
Gleb Natapov wrote on 2013-02-05:
> On Tue, Feb 05, 2013 at 05:57:14AM +, Zhang, Yang Z wrote:
>> Marcelo Tosatti wrote on 2013-02-05:
>>> On Mon, Feb 04, 2013 at 05:59:52PM -0200, Marcelo Tosatti wrote:
On Mon, Feb 04, 2013 at 07:13:01PM +0200, Gleb Natapov wrote:
> On Mon, Feb 04, 20
On Tue, Feb 05, 2013 at 10:35:55AM +, Zhang, Yang Z wrote:
> Gleb Natapov wrote on 2013-02-05:
> > On Tue, Feb 05, 2013 at 05:57:14AM +, Zhang, Yang Z wrote:
> >> Marcelo Tosatti wrote on 2013-02-05:
> >>> On Mon, Feb 04, 2013 at 05:59:52PM -0200, Marcelo Tosatti wrote:
> On Mon, Feb 0
Gleb Natapov wrote on 2013-02-05:
> On Tue, Feb 05, 2013 at 10:35:55AM +, Zhang, Yang Z wrote:
>> Gleb Natapov wrote on 2013-02-05:
>>> On Tue, Feb 05, 2013 at 05:57:14AM +, Zhang, Yang Z wrote:
Marcelo Tosatti wrote on 2013-02-05:
> On Mon, Feb 04, 2013 at 05:59:52PM -0200, Marcel
> -Original Message-
> From: Gleb Natapov [mailto:g...@redhat.com]
> Sent: Tuesday, February 05, 2013 1:21 AM
> To: Pandarathil, Vijaymohan R
> Cc: Blue Swirl; Alex Williamson; Bjorn Helgaas; Ortiz, Lance E;
> kvm@vger.kernel.org; qemu-de...@nongnu.org; linux-...@vger.kernel.org;
> linux-
On Tue, Feb 05, 2013 at 10:58:28AM +, Zhang, Yang Z wrote:
> Gleb Natapov wrote on 2013-02-05:
> > On Tue, Feb 05, 2013 at 10:35:55AM +, Zhang, Yang Z wrote:
> >> Gleb Natapov wrote on 2013-02-05:
> >>> On Tue, Feb 05, 2013 at 05:57:14AM +, Zhang, Yang Z wrote:
> Marcelo Tosatti wr
On Tue, Feb 05, 2013 at 10:59:41AM +, Pandarathil, Vijaymohan R wrote:
>
>
> > -Original Message-
> > From: Gleb Natapov [mailto:g...@redhat.com]
> > Sent: Tuesday, February 05, 2013 1:21 AM
> > To: Pandarathil, Vijaymohan R
> > Cc: Blue Swirl; Alex Williamson; Bjorn Helgaas; Ortiz, L
On Tue, Feb 05, 2013 at 03:26:21PM +0800, Xiao Guangrong wrote:
> There are the simple cleanups for MMU, no function / logic changed.
>
> Marcelo, Gleb, please apply them after applying
> "[PATCH v3] KVM: MMU: lazily drop large spte"
>
> Changelog:
> no change, just split them from the previous p
> -Original Message-
> From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> ow...@vger.kernel.org] On Behalf Of Gleb Natapov
> Sent: Tuesday, February 05, 2013 3:37 AM
> To: Pandarathil, Vijaymohan R
> Cc: Blue Swirl; Alex Williamson; Bjorn Helgaas; Ortiz, Lance E;
> kvm@vger.kernel
On Tue, Feb 5, 2013 at 1:26 AM, Marcelo Tosatti wrote:
> - 'Steal time' is the amount of time taken while vcpu is able to run
> but not runnable. Maybe 'vmexit latency' is a better name.
You are right, 'vmexit latency' is a better name.
> - Perhaps it would be good to subtract the time the threa
On Tue, Feb 05, 2013 at 12:05:11PM +, Pandarathil, Vijaymohan R wrote:
>
>
> > -Original Message-
> > From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> > ow...@vger.kernel.org] On Behalf Of Gleb Natapov
> > Sent: Tuesday, February 05, 2013 3:37 AM
> > To: Pandarathil, Vijaymo
On Tue, Feb 05, 2013 at 04:52:35PM +0800, Xiao Guangrong wrote:
> Current code has two ways to walk pte_list, the one is pte_list_walk and
> the another way is rmap_get_first and rmap_get_next, they have the same logic.
> This patchset tries to unify the code and also make the code more tidy.
>
>
On Sun, Feb 03, 2013 at 07:59:07PM -0600, Neil Aggarwal wrote:
> I have a CentOS server using KVM to host guest servers.
> I am trying to limit the bandwidth usable by a guest server.
>
> I tried to use tc, but that is only limiting the download bandwidth
> to a server. It does not seem to filter
Juan Quintela writes:
> Hi
>
> Please send in any agenda topics you are interested in.
FYI, I have a conflict for today so I won't be able to attend.
Regards,
Anthony Liguori
>
> Later, Juan.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to m
Gleb Natapov wrote on 2013-02-05:
> On Tue, Feb 05, 2013 at 10:58:28AM +, Zhang, Yang Z wrote:
>> Gleb Natapov wrote on 2013-02-05:
>>> On Tue, Feb 05, 2013 at 10:35:55AM +, Zhang, Yang Z wrote:
Gleb Natapov wrote on 2013-02-05:
> On Tue, Feb 05, 2013 at 05:57:14AM +, Zhang, Ya
On Tue, Feb 05, 2013 at 01:26:42PM +, Zhang, Yang Z wrote:
> Gleb Natapov wrote on 2013-02-05:
> > On Tue, Feb 05, 2013 at 10:58:28AM +, Zhang, Yang Z wrote:
> >> Gleb Natapov wrote on 2013-02-05:
> >>> On Tue, Feb 05, 2013 at 10:35:55AM +, Zhang, Yang Z wrote:
> Gleb Natapov wrote
Am Montag, den 04.02.2013, 08:49 -0700 schrieb Alex Williamson:
> Can you clarify what you mean by assign? Are you actually assigning the
> root ports to the qemu guest (1c.0 & 1c.6)? vfio will require they be
> owned by vfio-pci to make use of 3:00.0, but assigning them to the guest
> is not re
On Tue, 2013-02-05 at 12:05 +, Pandarathil, Vijaymohan R wrote:
>
> > -Original Message-
> > From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> > ow...@vger.kernel.org] On Behalf Of Gleb Natapov
> > Sent: Tuesday, February 05, 2013 3:37 AM
> > To: Pandarathil, Vijaymohan R
> >
Gleb Natapov wrote on 2013-02-05:
> On Tue, Feb 05, 2013 at 01:26:42PM +, Zhang, Yang Z wrote:
>> Gleb Natapov wrote on 2013-02-05:
>>> On Tue, Feb 05, 2013 at 10:58:28AM +, Zhang, Yang Z wrote:
Gleb Natapov wrote on 2013-02-05:
> On Tue, Feb 05, 2013 at 10:35:55AM +, Zhang, Ya
On Tue, Feb 05, 2013 at 06:37:35AM -0700, Alex Williamson wrote:
> On Tue, 2013-02-05 at 12:05 +, Pandarathil, Vijaymohan R wrote:
> >
> > > -Original Message-
> > > From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
> > > ow...@vger.kernel.org] On Behalf Of Gleb Natapov
> > > Se
On Tue, Feb 05, 2013 at 01:40:44PM +, Zhang, Yang Z wrote:
> Gleb Natapov wrote on 2013-02-05:
> > On Tue, Feb 05, 2013 at 01:26:42PM +, Zhang, Yang Z wrote:
> >> Gleb Natapov wrote on 2013-02-05:
> >>> On Tue, Feb 05, 2013 at 10:58:28AM +, Zhang, Yang Z wrote:
> Gleb Natapov wrote
On Tue, 2013-02-05 at 15:42 +0200, Gleb Natapov wrote:
> On Tue, Feb 05, 2013 at 06:37:35AM -0700, Alex Williamson wrote:
> > On Tue, 2013-02-05 at 12:05 +, Pandarathil, Vijaymohan R wrote:
> > >
> > > > -Original Message-
> > > > From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci
Anthony Liguori wrote:
> Juan Quintela writes:
>
>> Hi
>>
>> Please send in any agenda topics you are interested in.
>
> FYI, I have a conflict for today so I won't be able to attend.
As this was the only answer to the agenda, today call gets cancelled.
Happy hacking, Juan.
--
To unsubscribe fr
On Tue, 2013-02-05 at 14:31 +0100, David Gstir wrote:
> Am Montag, den 04.02.2013, 08:49 -0700 schrieb Alex Williamson:
>
> > Can you clarify what you mean by assign? Are you actually assigning the
> > root ports to the qemu guest (1c.0 & 1c.6)? vfio will require they be
> > owned by vfio-pci to
Hi,
I am starting to working on a port of KVM to an architecture that has a
dual TLB. The Guest Virtual Addresses (GVA) are translated to Guest
Physical Addresses (GPA) by the first TLB, then a second TLB translates
the GPA to a Root Physical Address (RPA). For the sake of this
question, we
On Tue, 2013-02-05 at 08:37 -0700, Alex Williamson wrote:
> On Tue, 2013-02-05 at 14:31 +0100, David Gstir wrote:
> > Am Montag, den 04.02.2013, 08:49 -0700 schrieb Alex Williamson:
> >
> > > Can you clarify what you mean by assign? Are you actually assigning the
> > > root ports to the qemu gues
Am Tue, 05 Feb 2013 13:36:53 -0700
schrieb Alex Williamson :
> > Ugh, the infamous and useless error 10. It could be anything.
> > I've got a system with onboard usb3, let me see what windows does
> > with it here first. Thanks,
>
> Well, I've got an Etron USB3 HBA and (un)fortunately it works j
Expand the steal time msr to also contain the consigned time.
Signed-off-by: Michael Wolf
---
arch/x86/include/asm/paravirt.h |4 ++--
arch/x86/include/asm/paravirt_types.h |2 +-
arch/x86/kernel/kvm.c |7 ++-
kernel/sched/core.c | 10 +++
Change the paravirt calls that retrieve the steal-time information
from the host. Add to it getting the consigned value as well as
the steal time.
Signed-off-by: Michael Wolf
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/include/asm/paravirt.h |4 ++--
arch/x86/include/ua
Add a helper routine to scheduler/core.c to allow the kvm module
to retrieve the cpu hardlimit settings. The values will be used
to set up a timer that is used to separate the consigned from the
steal time.
Signed-off-by: Michael Wolf
---
arch/x86/include/asm/kvm_host.h |9 ++
arch/x86/
In the case of where you have a system that is running in a
capped or overcommitted environment the user may see steal time
being reported in accounting tools such as top or vmstat. This can
cause confusion for the end user. To ease the confusion this patch set
adds the idea of consigned (expecte
Modify the amount of stealtime that the kernel reports via the /proc interface.
Steal time will now be broken down into steal_time and consigned_time.
Consigned_time will represent the amount of time that is expected to be lost
due to overcommitment of the physical cpu or by using cpu hard capping.
On Mon, Feb 04, 2013 at 11:50:43AM +0800, Dongxiao Xu wrote:
> Changes from v1 to v2:
> - Modify commit message and comments according to Gleb's suggestions.
>
> SMEP is disabled if CPU is in non-paging mode in hardware.
> However KVM always uses paging mode to emulate guest non-paging
> mode wit
Applied, thanks.
--
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 http://vger.kernel.org/majordomo-info.html
On Thu, Jan 31, 2013 at 12:06:08PM -0800, Geoff Levand wrote:
> Signed-off-by: Geoff Levand
> ---
>
> Saw this in v3.8-rc5, please apply.
>
> Documentation/virtual/kvm/api.txt | 13 -
> 1 file changed, 13 deletions(-)
Applied, thanks.
--
To unsubscribe from this list: send the l
This adds virtio-scsi multi-queue support to tcm_vhost.
Guest side virtio-scsi multi-queue support can be found here:
https://lkml.org/lkml/2012/12/18/166
Some initial perf numbers:
1 queue, 4 targets, 1 lun per target
4K request size, 50% randread + 50% randwrite: 127K/127k IOPS
4 queues,
On Mon, Feb 4, 2013 at 9:37 PM, Will Deacon wrote:
> On Mon, Feb 04, 2013 at 12:45:53PM +, Pekka Enberg wrote:
>> On Mon, Feb 4, 2013 at 2:17 PM, Michael Ellerman
>> wrote:
>> > Commit 21692d1 (Beautify debug output) broke the powerpc build because
>> > it changed the signature for kvm__dump
On Wed, 2013-02-06 at 13:20 +0800, Asias He wrote:
> This adds virtio-scsi multi-queue support to tcm_vhost.
>
> Guest side virtio-scsi multi-queue support can be found here:
>
>https://lkml.org/lkml/2012/12/18/166
>
> Some initial perf numbers:
> 1 queue, 4 targets, 1 lun per target
> 4K r
On 02/06/2013 02:45 PM, Nicholas A. Bellinger wrote:
> On Wed, 2013-02-06 at 13:20 +0800, Asias He wrote:
>> This adds virtio-scsi multi-queue support to tcm_vhost.
>>
>> Guest side virtio-scsi multi-queue support can be found here:
>>
>>https://lkml.org/lkml/2012/12/18/166
>>
>> Some initial p
57 matches
Mail list logo
