Re: Disk I/O stuck with KVM - no clue how to solve that
On Fri, Nov 5, 2010 at 5:16 PM, Hermann Himmelbauer wrote: > I experience strange disk I/O stucks on my Linux Host + Guest with KVM, which > make the system (especially the guests) almost unusable. These stucks come > periodically, e.g. every 2 to 10 seconds and last between 3 and sometimes > over 120 seconds, which trigger kernel messages like this (on host and/or > guest): > > INFO: task postgres:2195 blocked for more than 120 seconds The fact that this happens on the host too suggests there's an issue with the host software/hardware and the VM is triggering it but not the root cause. Does dmesg display any other suspicious messages? Stefan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM x86: Makefile clean up
Changed makefile to use the ccflags-y option instead of EXTRA_CFLAGS. Signed-off-by: Tracey Dent --- arch/x86/kvm/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile index 31a7035..a851df9 100644 --- a/arch/x86/kvm/Makefile +++ b/arch/x86/kvm/Makefile @@ -1,5 +1,5 @@ -EXTRA_CFLAGS += -Ivirt/kvm -Iarch/x86/kvm +ccflags-y += -Ivirt/kvm -Iarch/x86/kvm CFLAGS_x86.o := -I. CFLAGS_svm.o := -I. -- 1.7.3.2.146.gca209 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm unhandled exit 4400
On 11/05/2010 06:32 PM, Michael Tokarev wrote: > > Um. Please excuse me but this is a complete bullshit. As others pointed out, this is too harsh. It wasn't intentional to be extra harsh here, it was just me not realizing how harsh such a statement is, as English is not my native language and I dont use it much. Far more appropriate word for this context is "nonsense". I apologize for using inappropriate words. May I suggest "wrong" or "incorrect"? -- 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 majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -v2] Monitor command: pfa2hva, translate guest physical address to host virtual address
On 11/01/2010 03:22 PM, Anthony Liguori wrote:
On 11/01/2010 02:20 PM, Huang Ying wrote:
Yes. As general interface, it may not work so well, but as test
interface, it works quite well and useful.
Do we have any mechanism to add a test only interface?
I'd like to see what Luiz/Markus think but definitely only a human
monitor interface and probably prefix the command with a 'x-' prefix
to indicate that it's not a supported interface.
Automated testing will want to use qmp.
The documentation should be very clear about the limitations of the
interface and the intended use-case.
Perhaps a { execute: 'enable-version-specific-commands', arguments:
['pfa2hva'] } ?
--
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 majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.
Gleb Natapov writes: > On Sat, Nov 06, 2010 at 10:01:25AM +0100, Markus Armbruster wrote: > [skip] >> > Why should Seabios match against three (or even more) different type of >> > devices to detect ata interface? Why require Seabios changes when this >> > can be avoided (if new device that provide ata is added)? OpenBIOS also >> > supports qemu BTW (this is Open Firmware implementation for pc, you can >> > run and see what kind of device paths it generates). >> >> I think we've finally cut through the confusion caused by the >> unfortunate choice of driver_name for this new device attribute. >> >> The fact that you choose values of your driver_name in a way that is >> inspired by the syntactic conventions of IEEE 1275 is not its >> distinguishing characteristic. The values of existing member name are >> inspired by that as well. driver_name's distinguishing characteristic >> is its purpose: communication with SeaBIOS. >> > My understanding of this name in IEEE 1275 is that it specifies what > driver in FW handles a device. > >> I'm fine with you choosing its values however it's convenient for that >> purpose, as long as you give it a name reflecting that purpose. What >> about fw_name and qdev_fw_name()? >> > I am not attached to the name. Can "alias" be used for that purpose? alias needs to be an unambigous name of the device, just like name. If I understand you correctly, you want to use the same string for different, yet sufficiently compatible devices, so alias won't do. >> Next, I'm worried about overloading of method get_dev_path(). It's >> being used for a very specific purpose: savevm/loadvm. >> > This part of the patch is not completed yet. I intend to change the code > in savevm/loadvm to call qdev_get_dev_path() to get full device path > there. > >> * It's currently defined only for PCI devices. Your PATCH 7/8 changes >> its value there, from DOMAIN:BUS:SLOT.FUNCTION to fw_n...@slot. >> > Old definition is buggy BTW. BUS part is controlled by a guest and may > be different from default value at destination. Yes, it's problematic for anything domain:bus 0:0. Which happens to be the only one that can occur here currently, as far as I know. >> - The old value identifies the qdev. The new value does not >> (remember, we have a separate qdev per PCI function). Why is this >> okay? >> > No no. New value is fw_n...@slot,FUNC. Spec says that if FUNC is zero it > can be omitted. Okay. >> - Is the value saved with the VM? If yes, this is an incompatible >> change. > Don't understand that remark. If the value somehow makes it into the savevm data, then changing values could render the data incompatible: old qemu can't load new data, and vice versa. >> * You extend it for ISA and System bus (PATCH 5,6/8). How does this >> affect savevm? >> > We should ask savevm experts. As far as I can see it affects id > creation. As long as id is unique we should be OK. We may send more info > on migration after the patches. We definitely need review and testing there. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.
Gleb Natapov writes:
> On Sat, Nov 06, 2010 at 10:25:31AM +0100, Markus Armbruster wrote:
>> Gleb Natapov writes:
>>
>> > On Fri, Nov 05, 2010 at 05:31:38PM +0100, Markus Armbruster wrote:
>> >> Gleb Natapov writes:
>> >>
>> >> > On Fri, Nov 05, 2010 at 03:04:05PM +0100, Markus Armbruster wrote:
>> >> [...]
>> >> >> >> >> There has been quite some discussion on "canonical path" on the
>> >> >> >> >> list,
>> >> >> >> >> but no consensus. Ironically, one of the places where we got
>> >> >> >> >> stuck was
>> >> >> >> >> ISA. You cut right through that, so that's progress. Maybe
>> >> >> >> >> people
>> >> >> >> >> aren't looking ;)
>> >> >> >> > That is funny since the problem was already solved looong time
>> >> >> >> > ago. Just
>> >> >> >> > look at Open Firmware device path. They are capable of addressing
>> >> >> >> > all
>> >> >> >> > devices just fine, ISA devices included. What specific problem
>> >> >> >> > you had
>> >> >> >> > with ISA bus?
>> >> >> >>
>> >> >> >> Lack of consensus. I was in favour of using I/O base, just like
>> >> >> >> you do.
>> >> >> >> There were worries about ISA devices not using any I/O ports.
>> >> >> > There is a solution for that problem for almost 15 years and we are
>> >> >> > still looking for consensus on qemu list?! Here is ISA device binding
>> >> >> > spec for Open Firmware:
>> >> >> > http://playground.sun.com/1275/bindings/isa/isa0_4d.ps
>> >> >> > If ISA device have no IO ports MMIO is used.
>> >> >>
>> >> >> Precedence should promote consensus, but it can't replace it. If you
>> >> >> can push the list to consensus, more power to you.
>> >> > I do not see disagreement right now :) You are saying you agree. Blue
>> >> > Swirl asked me to use Open Firmware so I assume he agrees to. So who is
>> >> > against and what are his arguments?
>> >>
>> >> Start here:
>> >>
>> >> http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg01618.html
>> >
>> > I saw this in fact. The wouldn't agree with this device path proposal
>> > too. It mixes qemu internal names (which is a big no-no for my purpose)
>> > and bus addresses. Paul made sensible points there and if you look
>> > closely what he proposes is what I implemented here. Regarding ISA
>> > ("busses that don't have a consistent addressing scheme" he called it)
>> > he himself proposed to use address of the first IO port/memory region
>> > as an ID. This is what is already implemented by my patch.
>>
>> You don't have to convince me; I was with Paul in that thread.
>>
> So who should I convince :)? Alex? He is CCed. Jan? I do not see him
> complaining here.
No more complaints, no more convincing.
[...]
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.
On Sat, Nov 06, 2010 at 10:01:25AM +0100, Markus Armbruster wrote: [skip] > > Why should Seabios match against three (or even more) different type of > > devices to detect ata interface? Why require Seabios changes when this > > can be avoided (if new device that provide ata is added)? OpenBIOS also > > supports qemu BTW (this is Open Firmware implementation for pc, you can > > run and see what kind of device paths it generates). > > I think we've finally cut through the confusion caused by the > unfortunate choice of driver_name for this new device attribute. > > The fact that you choose values of your driver_name in a way that is > inspired by the syntactic conventions of IEEE 1275 is not its > distinguishing characteristic. The values of existing member name are > inspired by that as well. driver_name's distinguishing characteristic > is its purpose: communication with SeaBIOS. > My understanding of this name in IEEE 1275 is that it specifies what driver in FW handles a device. > I'm fine with you choosing its values however it's convenient for that > purpose, as long as you give it a name reflecting that purpose. What > about fw_name and qdev_fw_name()? > I am not attached to the name. Can "alias" be used for that purpose? > > Next, I'm worried about overloading of method get_dev_path(). It's > being used for a very specific purpose: savevm/loadvm. > This part of the patch is not completed yet. I intend to change the code in savevm/loadvm to call qdev_get_dev_path() to get full device path there. > * It's currently defined only for PCI devices. Your PATCH 7/8 changes > its value there, from DOMAIN:BUS:SLOT.FUNCTION to fw_n...@slot. > Old definition is buggy BTW. BUS part is controlled by a guest and may be different from default value at destination. > - The old value identifies the qdev. The new value does not > (remember, we have a separate qdev per PCI function). Why is this > okay? > No no. New value is fw_n...@slot,FUNC. Spec says that if FUNC is zero it can be omitted. > - Is the value saved with the VM? If yes, this is an incompatible > change. Don't understand that remark. > > * You extend it for ISA and System bus (PATCH 5,6/8). How does this > affect savevm? > We should ask savevm experts. As far as I can see it affects id creation. As long as id is unique we should be OK. We may send more info on migration after the patches. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.
On Sat, Nov 06, 2010 at 10:25:31AM +0100, Markus Armbruster wrote:
> Gleb Natapov writes:
>
> > On Fri, Nov 05, 2010 at 05:31:38PM +0100, Markus Armbruster wrote:
> >> Gleb Natapov writes:
> >>
> >> > On Fri, Nov 05, 2010 at 03:04:05PM +0100, Markus Armbruster wrote:
> >> [...]
> >> >> >> >> There has been quite some discussion on "canonical path" on the
> >> >> >> >> list,
> >> >> >> >> but no consensus. Ironically, one of the places where we got
> >> >> >> >> stuck was
> >> >> >> >> ISA. You cut right through that, so that's progress. Maybe
> >> >> >> >> people
> >> >> >> >> aren't looking ;)
> >> >> >> > That is funny since the problem was already solved looong time
> >> >> >> > ago. Just
> >> >> >> > look at Open Firmware device path. They are capable of addressing
> >> >> >> > all
> >> >> >> > devices just fine, ISA devices included. What specific problem you
> >> >> >> > had
> >> >> >> > with ISA bus?
> >> >> >>
> >> >> >> Lack of consensus. I was in favour of using I/O base, just like you
> >> >> >> do.
> >> >> >> There were worries about ISA devices not using any I/O ports.
> >> >> > There is a solution for that problem for almost 15 years and we are
> >> >> > still looking for consensus on qemu list?! Here is ISA device binding
> >> >> > spec for Open Firmware:
> >> >> > http://playground.sun.com/1275/bindings/isa/isa0_4d.ps
> >> >> > If ISA device have no IO ports MMIO is used.
> >> >>
> >> >> Precedence should promote consensus, but it can't replace it. If you
> >> >> can push the list to consensus, more power to you.
> >> > I do not see disagreement right now :) You are saying you agree. Blue
> >> > Swirl asked me to use Open Firmware so I assume he agrees to. So who is
> >> > against and what are his arguments?
> >>
> >> Start here:
> >>
> >> http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg01618.html
> >
> > I saw this in fact. The wouldn't agree with this device path proposal
> > too. It mixes qemu internal names (which is a big no-no for my purpose)
> > and bus addresses. Paul made sensible points there and if you look
> > closely what he proposes is what I implemented here. Regarding ISA
> > ("busses that don't have a consistent addressing scheme" he called it)
> > he himself proposed to use address of the first IO port/memory region
> > as an ID. This is what is already implemented by my patch.
>
> You don't have to convince me; I was with Paul in that thread.
>
So who should I convince :)? Alex? He is CCed. Jan? I do not see him
complaining here.
> Regarding DeviceInfo member name values being QEMU internal: hardly.
> They're ABI. They're what we use to identify device types on external
> interfaces including command line, human monitor and QMP.
Correct. They are ABI since they are user visible. But they describe
device type where I prefer to have a field that specifies device
functionality for cases when one driver handles multiple devices in a
guest. So to clarify: "name" will work (that is why I use it when
driver_name is not set), but I want something more optimal.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.
Gleb Natapov writes:
> On Fri, Nov 05, 2010 at 05:31:38PM +0100, Markus Armbruster wrote:
>> Gleb Natapov writes:
>>
>> > On Fri, Nov 05, 2010 at 03:04:05PM +0100, Markus Armbruster wrote:
>> [...]
>> >> >> >> There has been quite some discussion on "canonical path" on the
>> >> >> >> list,
>> >> >> >> but no consensus. Ironically, one of the places where we got stuck
>> >> >> >> was
>> >> >> >> ISA. You cut right through that, so that's progress. Maybe people
>> >> >> >> aren't looking ;)
>> >> >> > That is funny since the problem was already solved looong time ago.
>> >> >> > Just
>> >> >> > look at Open Firmware device path. They are capable of addressing all
>> >> >> > devices just fine, ISA devices included. What specific problem you
>> >> >> > had
>> >> >> > with ISA bus?
>> >> >>
>> >> >> Lack of consensus. I was in favour of using I/O base, just like you
>> >> >> do.
>> >> >> There were worries about ISA devices not using any I/O ports.
>> >> > There is a solution for that problem for almost 15 years and we are
>> >> > still looking for consensus on qemu list?! Here is ISA device binding
>> >> > spec for Open Firmware:
>> >> > http://playground.sun.com/1275/bindings/isa/isa0_4d.ps
>> >> > If ISA device have no IO ports MMIO is used.
>> >>
>> >> Precedence should promote consensus, but it can't replace it. If you
>> >> can push the list to consensus, more power to you.
>> > I do not see disagreement right now :) You are saying you agree. Blue
>> > Swirl asked me to use Open Firmware so I assume he agrees to. So who is
>> > against and what are his arguments?
>>
>> Start here:
>>
>> http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg01618.html
>
> I saw this in fact. The wouldn't agree with this device path proposal
> too. It mixes qemu internal names (which is a big no-no for my purpose)
> and bus addresses. Paul made sensible points there and if you look
> closely what he proposes is what I implemented here. Regarding ISA
> ("busses that don't have a consistent addressing scheme" he called it)
> he himself proposed to use address of the first IO port/memory region
> as an ID. This is what is already implemented by my patch.
You don't have to convince me; I was with Paul in that thread.
Regarding DeviceInfo member name values being QEMU internal: hardly.
They're ABI. They're what we use to identify device types on external
interfaces including command line, human monitor and QMP.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure.
Gleb Natapov writes:
> On Fri, Nov 05, 2010 at 05:24:01PM +0100, Markus Armbruster wrote:
>> Gleb Natapov writes:
>>
>> > On Fri, Nov 05, 2010 at 03:14:20PM +0100, Markus Armbruster wrote:
>> >> Gleb Natapov writes:
>> >>
>> >> > On Thu, Nov 04, 2010 at 03:58:03PM +0100, Markus Armbruster wrote:
>> >> >> Gleb Natapov writes:
>> >> >>
>> >> >> > On Thu, Nov 04, 2010 at 10:20:18AM +0100, Markus Armbruster wrote:
>> >> >> >> Gleb Natapov writes:
>> >> >> >>
>> >> >> >> > Add "deriver_name" to DeviceInfo to use in device path building.
>> >> >> >> > In
>> >> >> >>
>> >> >> >> Typo "deriver". Same in subject.
>> >> >> >>
>> >> >> > Heh.
>> >> >> >
>> >> >> >> > contrast to "name" "driver_name" should refer to functionality
>> >> >> >> > device
>> >> >> >> > provides instead of particular device model like "name" does.
>> >> >> >>
>> >> >> >> Why is that useful in a device path?
>> >> >> >>
>> >> >> > Sometimes it is sometimes it is not. Lets look at path like that:
>> >> >> > /p...@i0cf8/ether...@4/ethernet-...@0
>> >> >> >
>> >> >> > It is important to have pci in the fist path element since it defines
>> >> >> > what kind of bus addressing is used by next element ether...@4.
>> >> >>
>> >> >> It is for consumers that don't know what's sitting at i0cf8 on the
>> >> >> system bus.
>> >> > Yes. Same firmware may support different boards that have same pci
>> >> > controller but on different addresses. Device name may even contain
>> >> > manufacturer ID, so firmware will be able to find matching driver and
>> >> > support more board without recompiling.
>> >>
>> >> "pci" tells us it's some kind of PCI host bridge. Why is that enough?
>> >> Why don't we have to identify the particular host bridge, such as
>> >> "i440FX-pcihost"?
>> >>
>> > As I said below manufacturer ID may be part of device name. It should be
>> > separated by comma though. Something like "i440FX,pci".
>>
>> I'd expect "intel,i440FX".
>>
> It is impossible to figure what i440FX is. Anyway as I said many times
> already device path shouldn't contain full information about all devices
> in the path but only enough information to find device the path points
> to. FDT contains full information about device including all resources
> it uses, full device name, compatible device list an so on. This patch
> is not about passing FDT to FW, just about creating Open Firmware
> complaint device path.
>
>> Note that comma makes for extremely user-hostile -device usage. Right
>> now, it doesn't work at all.
>>
>> > But for x86 qemu
>> > emulation this is not needed since all chipsets implement essentially
>> > the same pci controller.
>>
>> Will it stay that way? What about Isaku's q35 work?
>>
> AFAIK all PC chipsets implement same PCI config interface accessible
> through io ports 0cf8-0cff. Otherwise each OS will have to have support
> for each chipset.
Nice to have some compatibility, for once.
>> > Other platforms qemu emulates may use more
>> > elaborate names. Other platforms may want to get full FDT tree from
>> > qemu anyway.
>> >
>> >> >> > 4 is
>> >> >> > slot number in case of pci bus. On the other hand ethernet part is
>> >> >> > not
>> >> >> > important since OS can figure it out by looking in pci config space.
>> >> >>
>> >> >> The OS does know what's sitting in slot 4 on the PCI bus.
>> >> >>
>> >> > Yes, and? That what I wrote above. "ethernet" part is redundant in case
>> >> > of PCI bus. A little bit of redundancy will not hurt and required by the
>> >> > spec.
>> >> >
>> >> >> If the OS number doesn't know what's sitting at i0cf8, why is "pci"
>> >> >> sufficient information? Why don't we have to distinguish between the
>> >> >> different PCI host bridges?
>> >> > Manufacturer ID may be put along with pci. Full FDT contains much more
>> >> > information about each node though. It may even list compatible HW. Here
>> >> > we are concerned with device paths only.
>> > Here I said it already :)
>> >
>> >> >
>> >> >>
>> >> >> >> I'm afraid "driver_name" is too confusing, because we already use
>> >> >> >> "driver" and "name" for the name of the device model: DeviceInfo
>> >> >> >> member
>> >> >> >> name, and qemu_device_opts option name "driver".
>> >> >> > I use "driver_name" here since I am coding to Open Firmware spec now
>> >> >> > and this element in device path is called driver_name by the spec.
>> >> >>
>> >> >> Why is it different from our DeviceInfo member name?
>> >> >>
>> >> >> We already have name (e.g. "lsi53c895a") and alias ("lsi"), why do we
>> >> >> need a third?
>> >> > I haven't noticed we have alias! What is it used for? I think I can use
>> >> > it instead.
>> >> >
>> >> >>
>> >> >> Do you envisage different device models sharing the same driver_name?
>> >> >>
>> >> > Yes. isa-ide, piix3-ide, piix4-ide all provides exactly same ata bus.
>>
