> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org
> [mailto:kvm-ppc-ow...@vger.kernel.org] On Behalf Of Alexander Graf
> Sent: Tuesday, September 20, 2011 7:36 AM
> To: kvm-...@vger.kernel.org
> Cc: kvm@vger.kernel.org
> Subject: [PATCH] KVM: PPC: E500: Support hugetlbfs
>
> W
On Thu, Sep 22, 2011 at 12:35:13AM -0400, Kevin O'Connor wrote:
> On Wed, Sep 21, 2011 at 03:44:13PM +0300, Michael S. Tsirkin wrote:
> > The reason is that our acpi tables declare both _RMV with value 0,
> > and _EJ0 method for these slots. What happens in this case
> > is undocumented by ACPI spe
On Wed, Sep 21, 2011 at 03:44:13PM +0300, Michael S. Tsirkin wrote:
> The reason is that our acpi tables declare both _RMV with value 0,
> and _EJ0 method for these slots. What happens in this case
> is undocumented by ACPI spec, so linux ignores _RMV,
> and windows seems to ignore _EJ0.
Could the
Commit c4525754 added a capability check for KVM_CAP_DEVICE_MSIX,
which is unfortunately not exposed, resulting in MSIX never
being listed as a capability. This breaks anything depending on
MSIX, such as igbvf. Since we can't specifically check for MSIX
support and KVM_CAP_ASSIGN_DEV_IRQ indicate
We now need to scan PCI capabilities and setup an MSI-X page
before we walk the device resources since the overlay is now
setup during init instead of at the first mapping by the guest.
Signed-off-by: Alex Williamson
---
hw/device-assignment.c | 16
1 files changed, 8 inserti
Assigned device MSI-X support hasn't been working, this fixes
it. I believe this should also fix:
https://bugs.launchpad.net/qemu/+bug/830558
Thanks,
Alex
---
Alex Williamson (2):
pci-assign: Fix MSI-X registration
pci-assign: Re-order initfn for memory API
hw/device-assignment
Hi,
I have "20:04.0 Network controller: Sangoma Technologies Corp. A104d
QUAD T1/E1 AFT caHi,
I have "20:04.0 Network controller: Sangoma Technologies Corp. A104d
QUAD T1/E1 AFT card" on Host OS, Its not visible on guest OS using
linux KVM application.
I did open the window for guest from virt
On Wed, 2011-09-21 at 10:23 -0700, Erik Flister wrote:
> i posted this to virt-tools but got no replies, hoping you guys can help me.
> :)
>
> >>>AMD
> phenom II X6 1075T proc
> >>>ASUS M4A87TD mobo
Google says this is an AMD 870 chipset, so you do not have AMD IOMMU
(AMD-Vi) support :(
> >>>
Hi
I am interested in kernel development and more inclined towards kvm.
However, I need some initial direction which can help me contribute.
Please let me know if I can take up some small task to begin with and
gain some acquaintance. Also, I have gone through the to do list @
http://www.linux-kvm
I've rewritten the script in python. Seems to work but
I didn't have time to test - only compiled for now -
and needs to move to tools - but I hope this makes
review easier.
Thanks,
---
src/find_ej0.py | 140 +++
1 files changed, 140 insertion
On Tue, Sep 20, 2011 at 09:03:51PM +0100, Jamie Lokier wrote:
> Marcelo Tosatti wrote:
> > In case the VM stops for whatever reason, the host system is not
> > supposed to adjust time related hardware state to compensate, in an
> > attempt to present apparent continuous time.
> >
> > If you save a
On Wed, Sep 21, 2011 at 07:11:08AM -0700, Dave Hansen wrote:
> On Tue, 2011-09-20 at 16:55 -0300, Marcelo Tosatti wrote:
> > > and the wall clock stays behind my host wall clock by the amount of
> > > time it took to resume.
> >
> > This is expected, similar to savevm/loadvm.
>
> That seems like
On Wed, Sep 21, 2011 at 11:46:03AM +0300, Avi Kivity wrote:
> On 09/20/2011 08:28 PM, Avi Kivity wrote:
> >On 09/20/2011 07:30 PM, Marcelo Tosatti wrote:
> >>> >
> >>> >> We do have a small issue. If we exit during
> >>NMI-blocked-by-STI and
> >>> >> nmi_pending == 2, then we lose the second i
i posted this to virt-tools but got no replies, hoping you guys can help me. :)
>- Forwarded Message -
>>From: Erik Flister
>>To: erik flister ; "virt-tools-l...@redhat.com"
>>
>>Sent: Tuesday, September 20, 2011 9:36 AM
>>Subject: Re: [virt-tools-list] pci passthrough fail on fedora
Amit,
can you have a look at the patch below and give feedback or apply
if appropriate?
---
On s390 I have seen some random "Warning: unable to open an initial
console" boot failure. Turns out that tty_open fails, because the
hvc_alloc was not yet done. In former times this could not happen,
sinc
On 09/21/2011 05:28 PM, Avi Kivity wrote:
Coming back to this, the trigger if cpuid family=6 and model>=13
(model 12 works). Looks like the code disables rep_good is some MSR
doesn't have the expected value. While we should configure the MSR
correctly, it looks like the fallback code for !r
On Wed, Sep 21, 2011 at 05:27:32PM +0300, Gleb Natapov wrote:
> On Wed, Sep 21, 2011 at 03:44:29PM +0300, Michael S. Tsirkin wrote:
> > script ./src/find_ej0.pl finds all instances of
> > method named EJ0_ and the matching _ADR information,
> > and outputs the AML offset and slot mask of each.
> >
On 08/08/2011 12:55 PM, Tejun Heo wrote:
Hello, Avi.
On Sun, Aug 07, 2011 at 06:32:35PM +0300, Avi Kivity wrote:
> qemu, under some conditions (-cpu host or -cpu kvm64), erroneously
> passes family=15 as the virtual cpuid. This causes a BUG() in
> percpu code during late boot:
>
> -
On Wed, Sep 21, 2011 at 03:44:29PM +0300, Michael S. Tsirkin wrote:
> script ./src/find_ej0.pl finds all instances of
> method named EJ0_ and the matching _ADR information,
> and outputs the AML offset and slot mask of each.
>
There is tools/ directory for such kind of scripts. Most (if not all) o
On Tue, 2011-09-20 at 16:55 -0300, Marcelo Tosatti wrote:
> > and the wall clock stays behind my host wall clock by the amount of
> > time it took to resume.
>
> This is expected, similar to savevm/loadvm.
That seems like pretty undesirable behavior to me. It's too bad that it
does that with sa
On Wed, Sep 21, 2011 at 08:47:39AM -0400, Kevin O'Connor wrote:
> On Wed, Sep 21, 2011 at 02:09:08PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Sep 21, 2011 at 01:39:22AM -0400, Amos Kong wrote:
> > > - Original Message -
> > > > How about moving code into functions so that it isn't dupli
On Wed, Sep 21, 2011 at 02:09:08PM +0300, Michael S. Tsirkin wrote:
> On Wed, Sep 21, 2011 at 01:39:22AM -0400, Amos Kong wrote:
> > - Original Message -
> > > How about moving code into functions so that it isn't duplicated for
> > > each PCI device. See the patch below as an example (100
On Wed, Sep 21, 2011 at 03:44:21PM +0300, Michael S. Tsirkin wrote:
> Use iasl -l flag to produce a mixed listing, where a
> source line is followed by matching AML.
> Since we use a preprocessed input, this generates long lines with
> multiple commands per line. To make it possible to match
> AML
The macro gen_pci_device is used to add _RMV
method to a slot device so it is no longer needed:
presence of _EJ0 now indicates that the slot is ejectable.
It is also placing two devices with the same _ADR
on the same bus, which isn't defined by the ACPI spec.
So let's remove it.
Signed-off-by: Mic
Modify ACPI to only supply _EJ0 methods for PCI
slots that support hotplug.
This is done by runtime patching:
- Rename _EJ0 methods for PCI slots in DSDT to EJ0_:
note that this has the same checksum, but
is ignored by OSPM.
- At compile time, look for these methods in ASL source,
find the m
script ./src/find_ej0.pl finds all instances of
method named EJ0_ and the matching _ADR information,
and outputs the AML offset and slot mask of each.
Signed-off-by: Michael S. Tsirkin
---
src/find_ej0.pl | 136 +++
1 files changed, 136 insert
Use iasl -l flag to produce a mixed listing, where a
source line is followed by matching AML.
Since we use a preprocessed input, this generates long lines with
multiple commands per line. To make it possible to match
AML to source exactly, split the input that we supply iasl,
with each command on a
Here's a bug: guest thinks it can eject VGA device and ISA bridge.
[root@dhcp74-172 ~]#lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX
On 09/21/2011 01:48 PM, Nadav Har'El wrote:
This patch solves two outstanding nested-VMX issues:
Sorry, I missed an important point on the first review.
--- .before/arch/x86/kvm/vmx.c 2011-09-21 13:45:59.0 +0300
+++ .after/arch/x86/kvm/vmx.c 2011-09-21 13:45:59.0 +0300
@@
On Wed, Sep 21, 2011 at 01:39:22AM -0400, Amos Kong wrote:
> - Original Message -
> > On Tue, Sep 20, 2011 at 06:45:57AM -0400, Amos Kong wrote:
> > > From 48ea1c9188334b89a60b4f9e853e86fc04fda4a5 Mon Sep 17 00:00:00
> > > 2001
> > > From: Amos Kong
> > > Date: Tue, 20 Sep 2011 15:38:43 +0
This patch solves two outstanding nested-VMX issues:
1. "unexpected, valid vectoring info" warnings appeared in L1.
These are fixed by correcting the emulation of concurrent L0->L1 and
L1->L2 injections.
2. When we must run L2 next (e.g., on L1's VMLAUNCH/VMRESUME), injection into
L1 was delayed
Hi,
I am new to the list, so please guide me to the correct place to ask if
my issue is misplaced here.
My system is an openSuSE 11.4 box with
kvm-0.14.0.0-1.10.1.x86_64
libvirt-client-0.8.8-0.12.1.x86_64
libvirt-devel-0.8.8-0.12.1.x86_64
virt-manager-0.8.5-8.1.x86_64
libvirt-0.8.8-0.1
On 09/20/2011 08:28 PM, Avi Kivity wrote:
On 09/20/2011 07:30 PM, Marcelo Tosatti wrote:
> >
> >> We do have a small issue. If we exit during
NMI-blocked-by-STI and
> >> nmi_pending == 2, then we lose the second interrupt. Should
rarely
> >> happen, since external interrupts never exit
Am 20.09.2011 18:49, schrieb Jan Kiszka:
> Upstream's version is about to be signal-free and will stop handling
> SIGUSR2 specially. So it's time to adopt its implementation, ie. switch
> from signalfd to a pipe.
>
> Signed-off-by: Jan Kiszka
> ---
>
> This should help pulling upstream into qemu
On Tue, Sep 20, 2011 at 06:49:49PM +0200, Jan Kiszka wrote:
> Upstream's version is about to be signal-free and will stop handling
> SIGUSR2 specially. So it's time to adopt its implementation, ie. switch
> from signalfd to a pipe.
>
> Signed-off-by: Jan Kiszka
> ---
>
> This should help pulling
On Tue, Sep 20, 2011 at 8:34 PM, Marcelo Tosatti wrote:
> On Mon, Sep 19, 2011 at 05:55:41PM +0800, Zhi Yong Wu wrote:
>> On Wed, Sep 14, 2011 at 6:50 PM, Marcelo Tosatti wrote:
>> > On Tue, Sep 13, 2011 at 11:09:46AM +0800, Zhi Yong Wu wrote:
>> >> On Fri, Sep 9, 2011 at 10:44 PM, Marcelo Tosatt
36 matches
Mail list logo
