On Wed, Feb 22, 2012 at 05:33:56PM +0100, David Cure wrote:
> Le Sun, Feb 19, 2012 at 11:13:15AM +0200, Gleb Natapov ecrivait :
> >
> > > http://www.roullier.net/report-no-hpet.txt.gz
> > >
> > How have you acquired this trace? It does not trace all kvm events only
> > those that have "set_irq" i
from the kvm guest paravirt init code.
Signed-off-by: Liu Yu
---
v6:
1. rename epapr_para to epapr_paravirt
2. remove redundant warnings
3. remove unnecessary init
arch/powerpc/include/asm/epapr_hcalls.h |2 +
arch/powerpc/kernel/Makefile|1 +
arch/powerpc/kernel/epapr_hcall
And add a new flag definition in kvm_ppc_pvinfo to indicate
whether host support EV_IDLE hcall.
Signed-off-by: Liu Yu
---
v6: no change
arch/powerpc/include/asm/Kbuild |1 +
arch/powerpc/include/asm/kvm_para.h | 14 --
arch/powerpc/kvm/powerpc.c |6 ++
inc
If the guest hypervisor node contains "has-idle" property.
Signed-off-by: Liu Yu
---
v6:
reuse the EV_IDLE definition
arch/powerpc/include/asm/epapr_hcalls.h | 11 ++-
arch/powerpc/kernel/epapr_hcalls.S | 27 +++
arch/powerpc/kernel/epapr_paravirt.c|
Discard the old way that invoke hypercall,
instead, use epapr paravirt.
Signed-off-by: Liu Yu
---
v6:
select epapr_paravirt when enable fsl_hv driver
arch/powerpc/include/asm/epapr_hcalls.h | 22 +-
arch/powerpc/include/asm/fsl_hcalls.h | 36 +++---
This patch series is the result of the integration of my dirty logging
optimization work, including preparation for the new GET_DIRTY_LOG API,
and the attempt to get rid of controversial synchronize_srcu_expedited().
1 - KVM: MMU: Split the main body of rmap_write_protect() off from others
2 - KVM
We will use this in the following patch to implement another function
which needs to write protect pages using the rmap information.
Note that there is a small change in debug printing for large pages:
we do not differentiate them from others to avoid duplicating code.
Signed-off-by: Takuya Yoshi
Dropped such mappings when we enabled dirty logging and we will never
create new ones until we stop the logging.
For this we introduce a new function which can be used to write protect
a range of PT level pages: although we do not need to care about a range
of pages at this point, the following pa
We have seen some problems of the current implementation of
get_dirty_log() which uses synchronize_srcu_expedited() for updating
dirty bitmaps; e.g. it is noticeable that this sometimes gives us ms
order of latency when we use VGA displays.
Furthermore the recent discussion on the following thread
Now that we do neither double buffering nor heuristic selection of the
write protection method these are not needed anymore.
Note: some drivers have their own implementation of set_bit_le() and
making it generic needs a bit of work; so we use test_and_set_bit_le()
and will later replace it with ge
On Thu, 2012-02-23 at 20:33 +0900, Takuya Yoshikawa wrote:
> - Stop allocating extra dirty bitmap buffer area
>
> According to Peter, mmu_notifier has become preemptible. If we can
> change mmu_lock from spin_lock to mutex_lock, as Avi said before, this
> would be staightforward because we
Hi,
i have recently been playing with an old idea (originally in grsecurity
for security reasons) to change
the policy from zero on allocate to zero after free in the linux page
allocator. My concern is that linux
leaves a lot of waste in the physical memory unlike Windows which per
default zeros
On Thu, 2012-02-23 at 09:25 +0530, rukhsana ansari wrote:
> Hello,
>
> Was wondering whether someone could shed some light on the issue below.
> Without FLR exposed in the VF, VF reset via FLR cannot be initiated from
> the guest.
> Appreciate any pointers.
The device state needs to be restored a
On Thu, Feb 23, 2012 at 3:40 PM, Peter Lieven wrote:
> However, in a virtual machine I have not observed the above slow down to
> that extend
> while the benefit of zero after free in a virtualisation environment is
> obvious:
>
> 1) zero pages can easily be merged by ksm or other technique.
> 2)
Hi all,
this patch series is part of the work in progress support for Xen on
ARMv7 with virtualization extensions in Linux.
It is obviously NOT ready to be accepted upstream but implements
enough support to allow Linux Dom0 to receive event channel
notifications and initialize xenbus.
With this se
We need a register to pass the hypercall number because we might not
know it at compile time and HVC only takes an immediate argument.
Among the available registers r12 seems to be the best choice because it
is defined as "intra-procedure call scratch register".
Use the ISS to pass an hypervisor
On Thu, Feb 23, 2012 at 11:42 AM, Stefan Hajnoczi wrote:
> The other approach is a memory page "discard" mechanism - which
> obviously requires more code changes than zeroing freed pages.
>
> The advantage is that we don't take the brute-force and CPU intensive
> approach of zeroing pages. It wou
On Mon, 20 Feb 2012 02:27:25 +
"Hao, Xudong" 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.
>
Can you name the magic constants and offsets a
Stefan Hajnoczi schrieb:
>On Thu, Feb 23, 2012 at 3:40 PM, Peter Lieven wrote:
>> However, in a virtual machine I have not observed the above slow down
>to
>> that extend
>> while the benefit of zero after free in a virtualisation environment
>is
>> obvious:
>>
>> 1) zero pages can easily be
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Wednesday, February 22, 2012 7:19 PM
> 0) My alarm tests failed quite badly. :( I attach a patch for kvm-unit-tests
> (repository at git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git).
> The tests can be
On Thu, 23 Feb 2012 02:32:33 -0500, Christoffer Dall
wrote:
> diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
> index 9c75ec4..c0adab0 100644
> --- a/arch/arm/kvm/guest.c
> +++ b/arch/arm/kvm/guest.c
> @@ -24,7 +24,6 @@
> #include
> #include
>
> -
> struct kvm_stats_debugfs_item d
On Thu, 23 Feb 2012 02:32:39 -0500, Christoffer Dall
wrote:
> + /*
> + * Allocate stack pages for Hypervisor-mode
> + */
> + for_each_possible_cpu(cpu)
> + per_cpu(kvm_arm_hyp_stack_page, cpu) = NULL;
This is weird; we can't call this init function multiple times wi
On Thu, 23 Feb 2012 02:32:26 -0500, Christoffer Dall
wrote:
> From: Christoffer Dall
>
> Targets KVM support for Cortex A-15 processors.
>
> Contains no real functionality but all the framework components,
> make files, header files and some tracing functionality.
>
> “Nothing to see here. Mo
On 02/16/2012 09:39 AM, Avi Kivity wrote:
>>
>> Yes, this is on purpose
Why?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majo
On Thu, Feb 23, 2012 at 10:32 PM, Rusty Russell wrote:
> On Thu, 23 Feb 2012 02:32:26 -0500, Christoffer Dall
> wrote:
>> From: Christoffer Dall
>>
>> Targets KVM support for Cortex A-15 processors.
>>
>> Contains no real functionality but all the framework components,
>> make files, header fil
On Thu, Feb 23, 2012 at 7:08 PM, peter.lie...@gmail.com wrote:
>
>
>
>
> Stefan Hajnoczi schrieb:
>
>>On Thu, Feb 23, 2012 at 3:40 PM, Peter Lieven wrote:
>>> However, in a virtual machine I have not observed the above slow down
>>to
>>> that extend
>>> while the benefit of zero after free in a
On Fri, Feb 24, 2012 at 6:41 AM, Stefan Hajnoczi wrote:
> On Thu, Feb 23, 2012 at 7:08 PM, peter.lie...@gmail.com wrote:
>>
>>
>>
>>
>> Stefan Hajnoczi schrieb:
>>
>>>On Thu, Feb 23, 2012 at 3:40 PM, Peter Lieven wrote:
However, in a virtual machine I have not observed the above slow down
On 02/24/2012 01:55 AM, Zhang, Yang Z wrote:
> Hi paolo The DM and 24/12 test case assumes the changing of DM bit
> will reflect to RTC internal clock. But the datasheet said nothing
> will affect if you change it. Also, the current logic in qemu has the
> same assumption. Does this a bug or just b
On Thu, Feb 23, 2012 at 04:42:54PM +, Stefan Hajnoczi wrote:
> On Thu, Feb 23, 2012 at 3:40 PM, Peter Lieven wrote:
> > However, in a virtual machine I have not observed the above slow down to
> > that extend
> > while the benefit of zero after free in a virtualisation environment is
> > obvio
On Fri, Feb 24, 2012 at 6:53 AM, Stefan Hajnoczi wrote:
> On Fri, Feb 24, 2012 at 6:41 AM, Stefan Hajnoczi wrote:
>> On Thu, Feb 23, 2012 at 7:08 PM, peter.lie...@gmail.com wrote:
>>> Stefan Hajnoczi schrieb:
>>>
On Thu, Feb 23, 2012 at 3:40 PM, Peter Lieven wrote:
> However, in a virt
Am 24.02.2012 um 08:23 schrieb Stefan Hajnoczi:
> On Fri, Feb 24, 2012 at 6:53 AM, Stefan Hajnoczi wrote:
>> On Fri, Feb 24, 2012 at 6:41 AM, Stefan Hajnoczi wrote:
>>> On Thu, Feb 23, 2012 at 7:08 PM, peter.lie...@gmail.com
>>> wrote:
Stefan Hajnoczi schrieb:
> On Thu, Feb 23
31 matches
Mail list logo