Marcelo Tosatti writes:
>> Yes, it was an another option to fix this. As note, the wrong percpu
>> usage (use it before initialization) is still true even if merged
>> KVM_CLOCK.
>
> Its fine, i believe, because there is a percpu area for the "boot
> processor" (see __per_cpu_offset at arch/x86/k
gah, I hate it when I miss an already filed bug.
https://bugzilla.redhat.com/show_bug.cgi?id=623199
However the problem has apparently not be fixed for good. Even though the
above is marked resolved. A regression? Or another wrinkle that was missed?
--
To unsubscribe from this list: send the
On 08/12/2012 01:45 PM, Michael S. Tsirkin wrote:
> On Mon, Jul 30, 2012 at 08:08:31PM +0200, Bernd Schubert wrote:
>> On 07/30/2012 07:33 PM, Bernd Schubert wrote:
>>> Hello Stefan,
>>>
>>> Stefan Hajnoczi gmail.com> writes:
On Wed, Jan 11, 2012 at 4:18 PM, Bernd Schubert
itwm.fra
My quick search thru the archives didn't turn up a match. I didn't see
anything obvious in bugzilla.redhat.com either. Hopefully my search-foo
was sufficient to not offend.
In the interst of keeping this short, I have a longer writeup with various
'virsh' output over at
http://www.linux-kvm
>
> +/* Please call after prepare_to_enter. This function puts the lazy ee state
> + back to normal mode, without actually enabling interrupts. */
> +static inline void kvmppc_lazy_ee_enable(void)
> +{
> +#ifdef CONFIG_PPC64
> + /* Only need to enable IRQs by hard enabling them after this *
On Fri, 2012-08-17 at 15:39 -0300, Marcelo Tosatti wrote:
> On Fri, Aug 17, 2012 at 05:06:18PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2012-08-15 at 14:59 -0300, Marcelo Tosatti wrote:
> > >
> > > The guest should not expect memory accesses to an address
> > > to behave sanely while chang
On Fri, Aug 17, 2012 at 05:06:18PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2012-08-15 at 14:59 -0300, Marcelo Tosatti wrote:
> >
> > The guest should not expect memory accesses to an address
> > to behave sanely while changing a BAR anyway.
> >
> > Yes, compatibility for change of GPA base
On Fri, Aug 17, 2012 at 09:10:42AM +0900, OGAWA Hirofumi wrote:
> Marcelo Tosatti writes:
>
> > On Wed, Aug 15, 2012 at 11:05:57PM +0900, OGAWA Hirofumi wrote:
> >>
> >> If !CONFIG_KVM_GUEST, kvm_smp_prepare_boot_cpu() is not defined. So,
> >> kvm_register_clock("primary cpu clock") in kvm_smp_p
On Thu, Aug 16, 2012 at 05:54:49PM +0300, Avi Kivity wrote:
> Instead of populating the the entire register file, read in registers
> as they are accessed, and write back only the modified ones. This
> saves a VMREAD and VMWRITE on Intel (for rsp, since it is not usually
> used during emulation),
https://bugzilla.kernel.org/show_bug.cgi?id=30402
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On 2012-08-17 16:41, Jan Kiszka wrote:
> On 2012-08-17 16:36, Jan Kiszka wrote:
>> On 2012-08-17 15:11, Jan Kiszka wrote:
>>> On 2012-08-06 17:11, Stefan Hajnoczi wrote:
On Thu, Jun 28, 2012 at 2:05 PM, Peter Lieven wrote:
> i debugged my initial problem further and found out that the pro
On 2012-08-17 16:36, Jan Kiszka wrote:
> On 2012-08-17 15:11, Jan Kiszka wrote:
>> On 2012-08-06 17:11, Stefan Hajnoczi wrote:
>>> On Thu, Jun 28, 2012 at 2:05 PM, Peter Lieven wrote:
i debugged my initial problem further and found out that the problem
happens
to be that
the m
On 2012-08-17 15:11, Jan Kiszka wrote:
> On 2012-08-06 17:11, Stefan Hajnoczi wrote:
>> On Thu, Jun 28, 2012 at 2:05 PM, Peter Lieven wrote:
>>> i debugged my initial problem further and found out that the problem happens
>>> to be that
>>> the main thread is stuck in pause_all_vcpus() on reset or
On 2012-08-06 17:11, Stefan Hajnoczi wrote:
> On Thu, Jun 28, 2012 at 2:05 PM, Peter Lieven wrote:
>> i debugged my initial problem further and found out that the problem happens
>> to be that
>> the main thread is stuck in pause_all_vcpus() on reset or quit commands in
>> the monitor
>> if one cp
On Thu, Aug 16, 2012 at 02:16:50PM +0200, Alexander Graf wrote:
> Hi Avi,
>
> This is my patch queue for ppc patches that should go into 3.6. Please pull.
>
> * Fix memset in e500_tlb
> * Fix icache flush when mapping executable pages
> * Fix wrong branch in book3s hv code
>
> Alex
>
>
Richard,
Not sure if you've tried this, but I noticed massive performance gains
(easily booting 2-3 times as fast) by converting from RAW disk images to
direct-mapped raw partitions and making sure that IOMMU support was
enabled in the BIOS and in the kernel at boot time. The obvious downside
https://bugzilla.kernel.org/show_bug.cgi?id=46101
--- Comment #2 from Alessandro Surace 2012-08-17 12:47:27
---
Clear this is not a kernel problem. I thought this was the right place for
userspace tool bug.
The problem started from qemu-kvm-1.1.1 version.
I will open a bug on launchpad.
Hi Avi,
Thanks to you and several others for offering help. We will work with Avi at
first, but are grateful for all the other offers of help. We have a number
of other qemu-related projects which we'd be interested in getting done, and
will get in touch with these names (and anyone else who comes
https://bugzilla.kernel.org/show_bug.cgi?id=46101
Michael Tokarev changed:
What|Removed |Added
CC||m...@tls.msk.ru
--- Comment #1 from
https://bugzilla.kernel.org/show_bug.cgi?id=46101
Alessandro Surace changed:
What|Removed |Added
Platform|All |x86-64
--
Configure bugmail: htt
https://bugzilla.kernel.org/show_bug.cgi?id=46101
Alessandro Surace changed:
What|Removed |Added
Kernel Version||3.2.1-gentoo-r2
--
Configure bug
https://bugzilla.kernel.org/show_bug.cgi?id=46101
Summary: > qemu-kvm-1.1.1-r1 - USB activkey doesn't work
anymore
Product: Virtualization
Version: unspecified
Platform: All
OS/Version: Linux
Tree: Mainline
https://bugzilla.kernel.org/show_bug.cgi?id=30042
Alan changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On 2012-07-10 12:41, Jan Kiszka wrote:
> On 2012-07-02 11:07, Avi Kivity wrote:
>> On 06/29/2012 07:37 PM, Jan Kiszka wrote:
>>> Instead of flushing pending coalesced MMIO requests on every vmexit,
>>> this provides a mechanism to selectively flush when memory regions
>>> related to the coalesced o
On Fri, Aug 17, 2012 at 06:38:03PM +1000, Benjamin Herrenschmidt wrote:
> This patch removes the powerpc "generic" updates of vcpu->cpu in
> load and put, and moves them to the various backends.
>
> The reason is that "HV" KVM does its own sauce with that field
> and the generic updates might corr
On Fri, Aug 17, 2012 at 06:38:29PM +1000, Benjamin Herrenschmidt wrote:
> When making a vcpu non-runnable we incorrectly changed the
> thread IDs of all other threads on the core, just remove that
> code.
>
> Signed-off-by: Benjamin Herrenschmidt
Acked-by: Paul Mackerras
--
To unsubscribe from
On Fri, Aug 17, 2012 at 12:26 PM, Asias He wrote:
> This patch brings virito-scsi support to kvm tool.
>
> With the introduce of tcm_vhost (vhost-scsi)
>
>tcm_vhost: Initial merge for vhost level target fabric driver
>
> we can implement virito-scsi by simply having vhost-scsi to handle the
>
This patch brings virito-scsi support to kvm tool.
With the introduce of tcm_vhost (vhost-scsi)
tcm_vhost: Initial merge for vhost level target fabric driver
we can implement virito-scsi by simply having vhost-scsi to handle the
SCSI command.
Howto use:
1) Setup the tcm_vhost target through
This changes the implementation of the ICP (presentation
controller which is attached to each CPU) to operate
based on an atomic update mechanism rather than mutexes.
This is done to make it possible to implement large
portions of it to work in "real mode" (ie. MMU off)
in order to speed things up
When making a vcpu non-runnable we incorrectly changed the
thread IDs of all other threads on the core, just remove that
code.
Signed-off-by: Benjamin Herrenschmidt
---
This is a bug fix and thus should probably be merged ASAP
arch/powerpc/kvm/book3s_hv.c |6 --
1 file changed, 6 deleti
- Forwarded Message -
From: "Andrew Holway"
To: "Alex Jia"
Cc: kvm@vger.kernel.org
Sent: Friday, August 17, 2012 4:24:33 PM
Subject: Re: [libvirt-users] vm pxe fail
Hello,
On Aug 17, 2012, at 4:34 AM, Alex Jia wrote:
> Hi Andrew,
> I can't confirm a root reason based on your informatio
This is an initial variant of the in-kernel XICS emulation
for both HV and PR KVM running in PAPR mode.
This is based on an initial implementation by Michael Ellerman
reworked by myself.
It supports up to 4095 "BUID" (blocks of interrupts) of up to
4096 interrupts each.
Signed-off-by: Benjamin
For pseries machine emulation, in order to move the interrupt
controller code to the kernel, we need to intercept some RTAS
calls in the kernel itself
Signed-off-by: Michael Ellerman
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/hvcall.h |3 +
arch/powerpc/include/asm
This adds an implementation of the XICS hypercalls in real
mode for HV KVM which allows us to avoid exiting the guest
MMU context on all threads for a variety of operations such
as fetching a pending interrupt, EOI of messages, IPIs, ...
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kvm
Currently, we wake up a CPUs by sending a host IPI with
smp_send_reschedule() to thread 0 of that core, which will
take all threads out of the guest, and cause them to re-evalutate
their interrupt status on the way back in.
This adds a mechanism to differenciate real host IPIs and
IPIs sent by KVM
This patch removes the powerpc "generic" updates of vcpu->cpu in
load and put, and moves them to the various backends.
The reason is that "HV" KVM does its own sauce with that field
and the generic updates might corrupt it. The field contains the
CPU# of the -first- HW CPU of the core always for a
Hello,
On Aug 17, 2012, at 4:34 AM, Alex Jia wrote:
> Hi Andrew,
> I can't confirm a root reason based on your information, perhaps you may
> try to find a reason by yourself via the following docs:
>
> http://wiki.libvirt.org/page/PXE_boot_%28or_dhcp%29_on_guest_failed
> (Troubleshooting)
> h
On Fri, Aug 17, 2012 at 03:43:56AM -0400, Tomas Racek wrote:
> Well, I've added some debug statements to the code:
>
> void __init arch_init_ideal_nops(void)
> {
> switch (boot_cpu_data.x86_vendor) {
> case X86_VENDOR_INTEL:
> /*
> * Due to a decode
On Wed, 2012-08-15 at 14:59 -0300, Marcelo Tosatti wrote:
>
> The guest should not expect memory accesses to an address
> to behave sanely while changing a BAR anyway.
>
> Yes, compatibility for change of GPA base can be done in the
> kernel. I can look into it next week if nobody has done so at
If we fail before or inside assigned_dev_register_regions, we so far
unconditionally unregistered IO resources, triggering an assertion in
the memory layer. Non-null u.r_baseport tells us if the region has been
registered.
Signed-off-by: Jan Kiszka
---
hw/device-assignment.c | 10 ++
1
In contrast to the old wrappers, the new ones only take the required
parameters instead of a preinitialized kvm_assigned_pci_dev structure.
We also move the dev_id generation into kvm_device_pci_assign and store
the result in the AssignedDevice structure. It will serve as handle for
all upcoming kv
Avoid passing kvm_assigned_irq on INTx assignment and separate this
function from (to-be-refactored) MSI/MSI-X assignment.
Signed-off-by: Jan Kiszka
---
hw/device-assignment.c | 16 ++--
target-i386/kvm.c | 25 +
target-i386/kvm_i386.h |2 ++
3 fi
Move kvm_device_intx_set_mask prototype and implementation to their
upstream positions.
Signed-off-by: Jan Kiszka
---
qemu-kvm.c |9 -
qemu-kvm.h |2 --
target-i386/kvm.c |9 +
target-i386/kvm_i386.h |1 +
4 files changed, 10 insertion
Introduce three new KVM services, kvm_device_intx/msi/msix_deassign, to
release assigned interrupts. These no longer require to pass
pre-initialized kvm_assigned_irq structures but only request required
parameters.
To trace which type of interrupt is currently assigned, use a new enum
AssignedIRQT
Helps valgrind, doesn't cost much (compared to the associated PCI config
space write). Align variable naming to other helpers at this chance.
Signed-off-by: Jan Kiszka
---
target-i386/kvm.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/target-i386/kvm.c b/targe
Hurray!
Signed-off-by: Jan Kiszka
---
hw/device-assignment.c |1 -
kvm-all.c |3 ---
kvm.h |7 ---
qemu-kvm.c | 37 -
qemu-kvm.h | 37 -
5 files chang
Use kvm_irqchip_add_msi_route and introduce kvm_irqchip_update_msi_route
to set up the required IRQ routes for MSI-X injections. This removes the
last direct interaction with the IRQ routing API of the KVM kernel so
that we can remove/unexport related services.
Signed-off-by: Jan Kiszka
---
hw/d
There are no other dependencies of device assignment except for
CONFIG_KVM and an x86 target. So there is also no point in controlling
this feature via configure.
Signed-off-by: Jan Kiszka
---
configure | 11 ---
hw/i386/Makefile.objs |2 +-
2 files changed, 1 insertion
Move device-assignment.c into hw/kvm, calling it pci-assign.c now, just
like its device name.
Signed-off-by: Jan Kiszka
---
hw/i386/Makefile.objs|3 ---
hw/kvm/Makefile.objs |2 +-
hw/{device-assignment.c => kvm/pci-assign.c} | 10 +--
Remove remainders of previous refactorings.
Signed-off-by: Jan Kiszka
---
hw/kvm/pci-assign.c |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
index 29a4671..4f5daf3 100644
--- a/hw/kvm/pci-assign.c
+++ b/hw/kvm/pci-assign
No functional changes.
Signed-off-by: Jan Kiszka
---
hw/kvm/pci-assign.c | 181 +-
1 files changed, 105 insertions(+), 76 deletions(-)
diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
index 3611539..cfd859e 100644
--- a/hw/kvm/pci-assign.c
Inform the user properly when trying to register an IRQ-using device
without in-kernel irqchip enabled.
Signed-off-by: Jan Kiszka
---
hw/kvm/pci-assign.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
index 4
52 matches
Mail list logo
