On Sun, 2014-12-21 at 23:56 +0100, Alexander Graf wrote:
> On 21.12.14 15:13, Andreas Schwab wrote:
> > arch/powerpc/kvm/built-in.o: In function `kvm_no_guest':
> > arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.text+0x724): undefined reference
> > to `power7_wakeup_loss'
>
> Ugh. We just removed supp
On 21.12.14 15:13, Andreas Schwab wrote:
> arch/powerpc/kvm/built-in.o: In function `kvm_no_guest':
> arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.text+0x724): undefined reference to
> `power7_wakeup_loss'
Ugh. We just removed support for 970 HV mode, but that obviously doesn't
mean you can't compi
arch/powerpc/kvm/built-in.o: In function `kvm_no_guest':
arch/powerpc/kvm/book3s_hv_rmhandlers.o:(.text+0x724): undefined reference to
`power7_wakeup_loss'
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for som
ad cause the call to power7_nap() that
> put the thread into nap mode to return. The reason for doing this is
> to avoid having the KVM code having to know what low-power mode to
> put the thread into.
>
> In the case of a secondary thread used to run a KVM guest, the thread
>
mode to return. The reason for doing this is
to avoid having the KVM code having to know what low-power mode to
put the thread into.
In the case of a secondary thread used to run a KVM guest, the thread
will be offline from the point of view of the host kernel, and the
relevant power7_nap() call
From: Ashwin Chaugule
PSCIv0.2 adds a new function called AFFINITY_INFO, which
can be used to query if a specified CPU has actually gone
offline. Calling this function via cpu_kill ensures that
a CPU has quiesced after a call to cpu_die. This helps
prevent the CPU from doing arbitrary bad things
From: Heinz Graalfs
During set offline processing virtio_grab_drvdata() incorrectly
calls dev_set_drvdata() to remove the virtio_ccw_device from the
parent ccw_device's driver data. This is wrong and ends up in a
hang during virtio_ccw_reset(), as the interrupt handler still
has need o
Once stop_machine() is gone from the CPU offline path, we won't be able
to depend on disabling preemption to prevent CPUs from going offline
from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going
offline, while invoking from atomic context.
Acked-by: Paolo Bo
Once stop_machine() is gone from the CPU offline path, we won't be able
to depend on disabling preemption to prevent CPUs from going offline
from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going
offline, while invoking from atomic context.
Cc: Benjamin Herrensc
y... and I acked the other KVM patch.
>>
>
> Thank you!
>
>> However, keeping the code on the local CPU is exactly the point of this
>> particular use of get_cpu()/put_cpu(). Why does it need to synchronize
>> with offlining of other CPUs?
>
> Now that I
; particular use of get_cpu()/put_cpu(). Why does it need to synchronize
> with offlining of other CPUs?
>
Now that I looked at it again, I think you are right, get/put_cpu() is
good enough here.
But let me explain why I initially thought we needed full synchronization
with CPU of
n).
Ok, then I understood correctly... and I acked the other KVM patch.
However, keeping the code on the local CPU is exactly the point of this
particular use of get_cpu()/put_cpu(). Why does it need to synchronize
with offlining of other CPUs?
Paolo
> What this patchset deals with is synchr
Il 25/06/2013 22:30, Srivatsa S. Bhat ha scritto:
> Once stop_machine() is gone from the CPU offline path, we won't be able
> to depend on disabling preemption to prevent CPUs from going offline
> from under us.
>
> Use the get/put_online_cpus_atomic() APIs to prevent CPUs
stinctly different
from each other.
get/put_cpu() is used to disable preemption on the local CPU. (Which
also disables offlining the local CPU during that critical section).
What this patchset deals with is synchronizing with offline of *any*
CPU. Typically, we use get_online_cpus()/put_online_cpus
Il 25/06/2013 22:30, Srivatsa S. Bhat ha scritto:
> - cpu = get_cpu();
> + cpu = get_online_cpus_atomic();
> vmx_vcpu_load(&vmx->vcpu, cpu);
> vmx->vcpu.cpu = cpu;
> err = vmx_vcpu_setup(vmx);
> vmx_vcpu_put(&vmx->vcpu);
> - put_cpu();
> + put_online_cpus_ato
Once stop_machine() is gone from the CPU offline path, we won't be able
to depend on disabling preemption to prevent CPUs from going offline
from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going
offline, while invoking from atomic context.
Cc: Benjamin Herrensc
Once stop_machine() is gone from the CPU offline path, we won't be able
to depend on disabling preemption to prevent CPUs from going offline
from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going
offline, while invoking from atomic context.
Cc: Gleb Natapo
Once stop_machine() is gone from the CPU offline path, we won't be able
to depend on disabling preemption to prevent CPUs from going offline
from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going
offline, while invoking from atomic context.
Cc: Gleb Natapo
Once stop_machine() is gone from the CPU offline path, we won't be able
to depend on disabling preemption to prevent CPUs from going offline
from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going
offline, while invoking from atomic context.
Cc: Benjamin Herrensc
Once stop_machine() is gone from the CPU offline path, we won't be able
to depend on disabling preemption to prevent CPUs from going offline
from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going
offline, while invoking from atomic context.
Cc: Gleb Natapo
Once stop_machine() is gone from the CPU offline path, we won't be able
to depend on disabling preemption to prevent CPUs from going offline
from under us.
Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going
offline, while invoking from atomic context.
Cc: Gleb Natapo
I'll be on vacation again, from Sunday (the 19th) until the following
Sunday. Unfortunately, Marcelo is on vacation as well, so there won't
be anyone to tend to patches. This is doubly unfortunate since there
are still unreviewed patches on the list. I'll do my best to catch up a
little tomorrow
I'll be offline until next Monday (inclusive). Please send kvm patches
to Marcelo, as usual. Urgent or non-core memory API fixes can go to
Anthony, I'll review core memory patches, if any, when I return.
--
error compiling committee.c: too many arguments to function
--
To unsubs
It adds the online and offline migration test for virtio_console. It uses the
loopback inside the guest. The host sends the data and checks it's validity
while the guest is migrated (on localhost, multiple times).
You can find more info in the patch itself.
Regards,
Lukáš Doktor
I'll be on vacation and offline again until March 20.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More
I'll be on vacation and offline until the 25th. As usual, Marcelo will
mind kvm.git for your patching pleasure.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line "unsubscribe kvm"
copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Rafal Wijata (ravpl)
Assigned to: Nobody/Anonymous (nobody)
Summary: gue
I will be on vacation and offline, pmu threads included, for a week.
Marcelo will handle all kvm issues as usual.
--
Do not meddle in the internals of kernels, for they are subtle and quick
to panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of
I will be on vacation and offline for a week. Marcelo will continue to
hold the fort in my absence.
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message
I'll be offline from 14 July until 25 July. In my absence Marcelo will
apply patches. Looking forward to an overflowing inbox on my return.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" i
Due to an unhealthy accumulation of vacation days, I will once again be
offline for a week. Internet access is unlikely.
As usual, Marcelo will review and apply patches, so keep on posting.
See you in a week.
--
I have a truly marvellous patch that fixes the bug which this
signature is too
Marcelo Tosatti wrote:
For those interested, I'll be pushing patches to "kvm-devel" branch of
both trees:
git://git.kernel.org/pub/scm/linux/kernel/git/marcelo/kvm-userspace.git/
git://git.kernel.org/pub/scm/linux/kernel/git/marcelo/kvm.git/
I've merged these trees into the master branch.
On Sun, Jan 25, 2009 at 07:13:45AM +0200, Avi Kivity wrote:
> I'll be offline for a week, on vacation, until next Sunday. During my
> absence, Marcelo will apply patches, so no one has any excuse for
> slacking off :)
For those interested, I'll be pushing patches to &q
I'll be offline for a week, on vacation, until next Sunday. During my
absence, Marcelo will apply patches, so no one has any excuse for
slacking off :)
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
--
To unsubscribe from this list: send the
the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Rafal Wijata (ravpl)
Assigned to: Nobody/Anonymous (nobody)
Summary: guest: device offline, then
the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Rafal Wijata (ravpl)
Assigned to: Nobody/Anonymous (nobody)
Summary: guest: device offline, then
the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Rafal Wijata (ravpl)
Assigned to: Nobody/Anonymous (nobody)
Summary: guest: device offline, then
a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Rafal Wijata (ravpl)
Assigned to: Nobody/Anonymous (nobody)
Summary: guest: de
On Thu, Jul 31, 2008 at 11:39:03AM +0300, Avi Kivity wrote:
> Andrea, I see Linus hasn't pulled the kvm-mmu notifiers glue. If that's
> still the case in a few days, please resolve any issues and send it
> yourself.
Ok.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the bo
I will go offline starting tonight, for about a week. If all goes well,
I will have no Internet connectivity. I'll be back on August 10.
Stephen/Andrew, if kvm.git gives you trouble, please drop it temporarily
from linux-next.
Andrea, I see Linus hasn't pulled the kvm-mmu noti
And also cleanup and standardize vcpu waking.
--
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
41 matches
Mail list logo
