Hi Andrea,
Is there any new about this discussion? ;)
Will you plan to support 'only wrprotect fault' in the userfault API?
Thanks,
zhanghailiang
On 2014/10/30 19:31, zhanghailiang wrote:
On 2014/10/30 1:46, Andrea Arcangeli wrote:
Hi Zhanghailiang,
On Mon, Oct 27, 2014 at 05:32:51PM +0800,
On Mon, Nov 10, 2014 at 09:47:27PM +0800, Herbert Xu wrote:
> On Mon, Nov 03, 2014 at 11:56:24PM +0800, Amos Kong wrote:
> >
> > @@ -98,6 +99,8 @@ static inline void cleanup_rng(struct kref *kref)
> >
> > if (rng->cleanup)
> > rng->cleanup(rng);
>
> You need a compiler barrier he
Amos Kong writes:
> From: Rusty Russell
>
> current_rng holds one reference, and we bump it every time we want
> to do a read from it.
>
> This means we only hold the rng_mutex to grab or drop a reference,
> so accessing /sys/devices/virtual/misc/hw_random/rng_current doesn't
> block on read of /
Amos Kong writes:
> From: Rusty Russell
>
> The previous patch added one potential problem: we can still be
> reading from a hwrng when it's unregistered. Add a wait for zero
> in the hwrng_unregister path.
>
> v4: add cleanup_done flag to insure that cleanup is done
That's a bit weird. The us
Paolo Bonzini wrote on 2014-11-11:
>
>
> On 11/11/2014 10:20, Wu, Feng wrote:
>>> Since legacy KVM device assignment is effectively deprecated, have
>>> you considered how we might do this with VFIO? Thanks,
>>
>> I haven't thought about how to enable this in VFIO so far. I think I
>> can conti
On Tue, Nov 11, 2014 at 4:33 PM, Linus Torvalds
wrote:
>
> I guess as a workaround it is fine, as long as we don't lose sight of
> trying to eventually do a better job.
Oh, and when it comes to the actual gcc bug - do you have any reason
to believe that it's somehow triggered more easily by somet
On Tue, Nov 11, 2014 at 1:16 PM, Christian Borntraeger
wrote:
>
> Are you ok with the patch as is in kvm/next for the time being or shall
> we revert that and replace it with the .val scheme?
Is that the one that was quoted at the beginning of the thread, that
uses barrier()?
I guess as a workar
On 2014-11-11 19:55, Samuel Thibault wrote:
> Hello,
>
> jenkins.debian.net is running inside a KVM VM, and it runs nested
> KVM guests for its installation attempts. This goes fine with Linux
> kernels, but it is extremely slow with gnumach kernels. I have
> reproduced the issue with my laptop
From: Ben Hutchings
Date: Tue, 11 Nov 2014 17:12:58 +
> This reverts commit 88e0e0e5aa722b193c8758c8b45d041de5316924 for
> the tap drivers, but leaves UFO disabled in virtio_net.
>
> libvirt at least assumes that tap features will never be dropped
> in new kernel versions, and doing so preve
Am 10.11.2014 um 22:07 schrieb Linus Torvalds:
> On Mon, Nov 10, 2014 at 12:18 PM, Christian Borntraeger
> wrote:
>>
>> Now: I can reproduces belows miscompile on gcc46 and gcc 47
>> gcc 45 seems ok, gcc 48 is fixed. This makes blacklisting
>> a bit hard, especially since it is not limited to s39
On Tue, Oct 28, 2014 at 10:04:10AM +0100, Paolo Bonzini wrote:
> can you test using QEMU from git://git.qemu-project.org/qemu.git?
That seems to work great, yes.
Looking through the commit history, I see:
kvmclock: Ensure time in migration never goes backward
kvmclock: Ensure proper e
Hello,
jenkins.debian.net is running inside a KVM VM, and it runs nested
KVM guests for its installation attempts. This goes fine with Linux
kernels, but it is extremely slow with gnumach kernels. I have
reproduced the issue with my laptop with a linux 3.17 host kernel, a
3.16 L1-guest kernel, a
On Tue, 2014-11-11 at 17:57 +0200, Michael S. Tsirkin wrote:
> On Tue, Nov 11, 2014 at 12:17:26PM +, Ben Hutchings wrote:
> > On Tue, 2014-11-11 at 10:58 +, Stefan Hajnoczi wrote:
> > > Commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4 ("drivers/net: Disable
> > > UFO through virtio") breaks
This reverts commit 88e0e0e5aa722b193c8758c8b45d041de5316924 for
the tap drivers, but leaves UFO disabled in virtio_net.
libvirt at least assumes that tap features will never be dropped
in new kernel versions, and doing so prevents migration of VMs to
the never kernel version while they are runnin
From: "Michael S. Tsirkin"
Date: Tue, 11 Nov 2014 17:57:50 +0200
> Basically userspace assumed that features will only
> ever be added, never removed, so this change is
> breaking it.
I essentially agree.
We can't just toss feature bits like this which have been present for so
long.
"There is
On Tue, Nov 11, 2014 at 12:17:26PM +, Ben Hutchings wrote:
> On Tue, 2014-11-11 at 10:58 +, Stefan Hajnoczi wrote:
> > Commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4 ("drivers/net: Disable
> > UFO through virtio") breaks live migration of KVM guests from older to
> > newer host kernels:
>
Linus,
The following changes since commit 0df1f2487d2f0d04703f142813d53615d62a1da4:
Linux 3.18-rc3 (2014-11-02 15:01:51 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
for you to fetch changes up to d29b9d7ed76c0b961603ca692b8a562
Juan Quintela wrote:
> Hi
>
> Please, send any topic that you are interested in covering.
As there are no agenda, call is cancelled.
Have a nice day.
Later, Juan.
>
> Thanks, Juan.
>
> Call details:
>
> 15:00 CEST
> 13:00 UTC
> 09:00 EDT
>
> Every two weeks
>
> By popular demand, a goog
On 2014/11/10 14:26, Feng Wu wrote:
> We don't need to migrate the irqs for VT-d Posted-Interrtups here.
> When 'pst' is set in IRTE, the associated irq will be posted to
> guests instead of interrupt remapping. The destination of the
> interrupt is set in Posted-Interrupts Descriptor, and the mi
Hi Feng,
Other than this solution, how about introducing new
struct irte_pi for posted interrupt?
On 2014/11/10 14:26, Feng Wu wrote:
> This patch adjusts the definition of 'struct irte', so that we can
> add the VT-d Posted-Interrtups format in this structure later.
>
> Signed-off-by: Fe
On 2014/11/10 14:26, Feng Wu wrote:
> VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
> With VT-d Posted-Interrupts enabled, external interrupts from
> direct-assigned devices can be delivered to guests without VMM
> intervention when guest is running in non-root mode.
>
>
On 2014/11/10 14:26, Feng Wu wrote:
> This patch initialize the VT-d Posted-interrupt Descritpor.
>
> Signed-off-by: Feng Wu
> ---
> arch/x86/include/asm/irq_remapping.h |1 +
> arch/x86/kernel/apic/apic.c |1 +
> arch/x86/kvm/vmx.c | 56 +
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Tuesday, November 11, 2014 7:02 PM
> To: Wu, Feng; Alex Williamson
> Cc: g...@kernel.org; dw...@infradead.org; j...@8bytes.org;
> t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
> kvm@vg
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Tuesday, November 11, 2014 7:02 PM
> To: Wu, Feng; Alex Williamson
> Cc: g...@kernel.org; dw...@infradead.org; j...@8bytes.org;
> t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
> kvm@vg
On Tue, 2014-11-11 at 10:58 +, Stefan Hajnoczi wrote:
> Commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4 ("drivers/net: Disable
> UFO through virtio") breaks live migration of KVM guests from older to
> newer host kernels:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/comm
On 11/11/2014 10:20, Wu, Feng wrote:
> > Since legacy KVM device assignment is effectively deprecated, have you
> > considered how we might do this with VFIO? Thanks,
>
> I haven't thought about how to enable this in VFIO so far. I think I can
> continue to
> implement that if needed after thi
> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Tuesday, November 11, 2014 5:58 AM
> To: Wu, Feng
> Cc: g...@kernel.org; pbonz...@redhat.com; dw...@infradead.org;
> j...@8bytes.org; t...@linutronix.de; mi...@redhat.com; h...@zytor.com;
> x...@kerne
On 10/11/2014 13:15, Paolo Bonzini wrote:
>
>
> On 10/11/2014 11:45, Gleb Natapov wrote:
>>> I tried making also the other shared MSRs the same between guest and
>>> host (STAR, LSTAR, CSTAR, SYSCALL_MASK), so that the user return notifier
>>> has nothing to do. That saves about 4-500 cycles o
Commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4 ("drivers/net: Disable
UFO through virtio") breaks live migration of KVM guests from older to
newer host kernels:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3d0ad09412ffe00c9afa201d01effdb6023d09b4
The problem occurs
> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Tuesday, November 11, 2014 5:58 AM
> To: Wu, Feng
> Cc: g...@kernel.org; pbonz...@redhat.com; dw...@infradead.org;
> j...@8bytes.org; t...@linutronix.de; mi...@redhat.com; h...@zytor.com;
> x...@kerne
> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Tuesday, November 11, 2014 5:58 AM
> To: Wu, Feng
> Cc: pbonz...@redhat.com; r...@twiddle.net; mtosa...@redhat.com;
> qemu-de...@nongnu.org; kvm@vger.kernel.org
> Subject: Re: [PATCH] x86: Update VT-d
> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Tuesday, November 11, 2014 5:57 AM
> To: Wu, Feng
> Cc: g...@kernel.org; pbonz...@redhat.com; dw...@infradead.org;
> j...@8bytes.org; t...@linutronix.de; mi...@redhat.com; h...@zytor.com;
> x...@kerne
Hi All,
I have second thoughts about rebasing KVM PMU patches
to Marc's irq-forwarding patches.
The PMU IRQs (when virtualized by KVM) are not exactly
forwarded IRQs because they are shared between Host
and Guest.
Scenario1
-
We might have perf running on Host and no KVM guest
runni
33 matches
Mail list logo
