Menu
▾
▴
kvm-devel — kernel virtual machine development
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(33) |
Nov
(325) |
Dec
(320) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(484) |
Feb
(438) |
Mar
(407) |
Apr
(713) |
May
(831) |
Jun
(806) |
Jul
(1023) |
Aug
(1184) |
Sep
(1118) |
Oct
(1461) |
Nov
(1224) |
Dec
(1042) |
| 2008 |
Jan
(1449) |
Feb
(1110) |
Mar
(1428) |
Apr
(1643) |
May
(682) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Johannes S. <Joh...@gm...> - 2008-05-14 15:13:56
|
Hi, On Wed, 14 May 2008, Javier Guerra wrote: > What about Lua? (http://www.lua.org) > > it started up as a configuration language, and evolved into a full > programming language, while remaining _very_ light (less than 200K > with all libraries), and wonderfully easy to embed into C programs. Okay, so much for the upsides. Now for the downsides: a language that nearly nobody knows, for something that is not meant to be executed (think security implications). Hth, Dscho |
|
From: Dor L. <dor...@qu...> - 2008-05-14 15:13:34
|
On Wed, 2008-05-14 at 15:52 +0200, Tomasz Chmielewski wrote: > Avi Kivity wrote: > > > This is the second release of network drivers for Windows guests running > > on a kvm host. The drivers are intended for Windows 2000 and Windows > > XP, and Windows 2003. Both x86 and x64 variants are provided. kvm-61 > > or later is needed in the host. At the moment only binaries are available. > > Hi, > > This is great news! > > Do you have any performance numbers for networking to see how it compares to the > real hardware? > > - Linux host (or: real Windows running on that host) For host you can measure yourself but for Linux guest (to host) it currently do about 1G, using TSO (work in progress) it can do 2.5G, and there is also work in progress to make the kernel know virtio through the tap interface which will further boot performance. > - PV Windows (network driver) About 700Mb+-, there is currently extra copy that we need to omit. Thanks for Anthony, we just have to change the driver. > - non-PV Windows What do you mean? Other fully emulated nics like e1000? It does not perform as pv but depending on the guest it can do up to 600Mb+-. |
|
From: Johannes S. <Joh...@gm...> - 2008-05-14 15:10:40
|
Hi, On Wed, 14 May 2008, andrzej zaborowski wrote: > What I'd love, though, but expect others will consider bloat, is that > files are passed through cpp before interpreting. This will add a dependency to a developer's tool on an application that has not much to do with development for most users. Ciao, Dscho |
|
From: Anthony L. <ali...@us...> - 2008-05-14 15:10:39
|
Paul Brook wrote: >> the "class" field is used to select the device model. Then all the other >> parameters are used to initialize the device model. That way it is >> possible to keep the compatibility with the existing options and add a >> provision to instanciate arbitrary new device models, such as: >> > > I like the idea, but I'm not so keen on the automatic allocation. I generally > prefer explicit declaration over implicit things. The latter makes it very > easy to not notice when you make a typo. > > It sounds like what you really want is something similar to an OF device tree. > So you have something like: > > # pciide0 may be an alias (possibly provided by qemu) > # e.g. pci0.slot1.func1.ide > alias hda ide0.primary.master > What I don't like about the ide0.primary.master syntax is that there isn't enough structure. I would prefer: alias hda ide,bus=0,primary,master If you combine this with your magic variable idea, you could also do: alias hda ide,bus=0,unit=$next But you could also just fold that into Fabrice's syntax (which I prefer): hda.class = ide,bus=0,unit=$next hda.type = disk hda.file = foo.img If you then default bus, and unit, you can just write: hda.class = ide hda.type = disk hda.file = foo.img And better yet, you could even allow for something like: hda.class = ide hda.bus = 0 hda.unit = 0 hda.type = disk hda.file = foo.img So I really actually prefer Fabrice's syntax because there is much more structure. I think it's a good idea to allow .class to contain multiple properties and to basically establish an alias. This way, you could predefine a bunch of aliases for today's parameters like hda, hdb, etc. > hda.type=disk > hda.file=foo.img > > You can then define some form of magic aliases that select the next unused > device. e.g. > > alias mydrive $next_ide_disk > > IMHO This provides the flexibility and structure that Fabrice is talking > about, and with suitable aliases can be made to look a lot like the existing > options. > > This may require some internal restructuring to allow the machine descriptions > to feed into the user config file. > I think if we choose a syntax we like, we can start using that pretty easily. We'll have to start adjusting option names keeping them only valid on the command line (for things like -m). However, I think it would grow pretty well into a machine description mechanism. Regards, Anthony Liguori > Thoughts? > > Paul > |
|
From: Daniel P. B. <ber...@re...> - 2008-05-14 15:05:27
|
On Wed, May 14, 2008 at 05:52:56PM +0300, Dor Laor wrote: > > On Wed, 2008-05-14 at 17:41 +0300, Avi Kivity wrote: > > Daniel P. Berrange wrote: > > > That's very nearly YAML format[1], which is attractive because parsers > > > are available in every major programming language, and it is still > > > pretty human friendly. > > > > > > So my preference would be to go with the last option and make sure > > > it really is YAML compliant so people can use standard tools for > > > generating and parsing the format. > > > > > > > Using a standard format has the added benefit that things like quoting > > are taken care of. > > > > Filenames with leading and trailing spaces, anyone? Embedded control > > characters? > > > > Please don't jump over me but I think it is worth mentioning OVF, at > least for to know what's you opinions. OVF is insanely overcomplicated. It is also addressing a different problem space, that of virtual machine applinance interchange / distribution. And it is a disgusting format for users to deal with. > Open Virtualization Format - > http://www.vmware.com/appliances/learn/ovf.html > > It's xml based, supported by all major hypervisors, so qemu/kvm/xen > users might eventually use a product that support OVF. > Since its a new format it is open for changes and has lots of > flexibility. As a start we don't have to be completely compatible with > it. It is a 'open' format defined in secret invitation only cabal by a bunch of proprietry software vendors. No thanks. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| |
|
From: Anthony L. <ali...@us...> - 2008-05-14 15:00:56
|
Avi Kivity wrote: > Daniel P. Berrange wrote: >> That's very nearly YAML format[1], which is attractive because parsers >> are available in every major programming language, and it is still >> pretty human friendly. >> >> So my preference would be to go with the last option and make sure >> it really is YAML compliant so people can use standard tools for >> generating and parsing the format. >> > > Using a standard format has the added benefit that things like quoting > are taken care of. > > Filenames with leading and trailing spaces, anyone? Embedded control > characters? YAML is a bad choice though. It's purpose is to model data structures of embedded languages (similar to JSON). The syntax would get out of hand quickly because what we've been talking about so far would be modeled as an association whereas semantically, we want it to be a sequence. To make it a sequence, we would have to prefix every line with '-'. I'm not against following some sort of standard (or even best practice). I just don't like YAML. Regards, Anthony Liguori |
|
From: Dor L. <dor...@qu...> - 2008-05-14 14:56:48
|
On Wed, 2008-05-14 at 17:41 +0300, Avi Kivity wrote: > Daniel P. Berrange wrote: > > That's very nearly YAML format[1], which is attractive because parsers > > are available in every major programming language, and it is still > > pretty human friendly. > > > > So my preference would be to go with the last option and make sure > > it really is YAML compliant so people can use standard tools for > > generating and parsing the format. > > > > Using a standard format has the added benefit that things like quoting > are taken care of. > > Filenames with leading and trailing spaces, anyone? Embedded control > characters? > Please don't jump over me but I think it is worth mentioning OVF, at least for to know what's you opinions. Open Virtualization Format - http://www.vmware.com/appliances/learn/ovf.html It's xml based, supported by all major hypervisors, so qemu/kvm/xen users might eventually use a product that support OVF. Since its a new format it is open for changes and has lots of flexibility. As a start we don't have to be completely compatible with it. It supports definition cpus, startup options, various devices (nic, ide, scsi,...). For example: " <Item> <rasd:Caption>Ethernet adapter on "VM Network"</rasd:Caption> <rasd:InstanceId>4000</rasd:InstanceId> <rasd:ResourceType>10</rasd:ResourceType> <rasd:ResourceSubType>VmxNet, E1000</rasd:ResourceSubType> <rasd:AutomaticAllocation>true</rasd:AutomaticAllocation> <rasd:Connection>VM Network</rasd:Connection> </Item> <Item> <rasd:Caption>SCSI Controller 0</rasd:Caption> <rasd:InstanceId>1000</rasd:InstanceId> <rasd:ResourceType>6</rasd:ResourceType> <rasd:ResourceSubType>LsiLogic, BusLogic</rasd:ResourceSubType> </Item> <Item> <rasd:Caption>Harddisk 1</rasd:Caption> <rasd:InstanceId>22001</rasd:InstanceId> <rasd:ResourceType>17</rasd:ResourceType> <rasd:HostResource>disk/vmdisk1</rasd:HostResource> <rasd:Parent>1000</rasd:Parent> </Item> <Item> </Item> " One can claim to xml is bad and ovf is outside of the scope and if one wants ovf, mgmt tool can wrap it around qemu. Nevertheless why doubling the effort? Qemu can reuse it and its mgmt tools. |
|
From: Javier G. <ja...@gu...> - 2008-05-14 14:45:02
|
What about Lua? (http://www.lua.org) it started up as a configuration language, and evolved into a full programming language, while remaining _very_ light (less than 200K with all libraries), and wonderfully easy to embed into C programs. it lets you write things like: drives = { hda = {if='scsi', file='hda.img'}, hdb = {if='ide', file='hdb.img'}, } mem = 512*MB or, equivalently: drives={} drives.hda={} drives.hda.if='scsi' drives.hda.file='hda.img' drives.hdb={} drives.hdb.if='ide' drives.hdb.file='hdb.img' mem=512*MB or, if you want: drive {if='scsi', file='hda.img'} drive {if='ide', file='hdb.img'} mem(512*MB) or even: for img in lfs.dir("*.img") do drive{if='scsi', file=img} end -- Javier |
|
From: Avi K. <av...@qu...> - 2008-05-14 14:41:36
|
Daniel P. Berrange wrote: > That's very nearly YAML format[1], which is attractive because parsers > are available in every major programming language, and it is still > pretty human friendly. > > So my preference would be to go with the last option and make sure > it really is YAML compliant so people can use standard tools for > generating and parsing the format. > Using a standard format has the added benefit that things like quoting are taken care of. Filenames with leading and trailing spaces, anyone? Embedded control characters? -- error compiling committee.c: too many arguments to function |
|
From: andrzej z. <ba...@gm...> - 2008-05-14 14:36:44
|
On 14/05/2008, Anthony Liguori <an...@co...> wrote:
> Anthony Liguori wrote:
>
> > I think this is pretty useful as-is. I think it also gives us a
> reasonable
> > way to move forward that will keep everyone pretty happy.
> >
> > Here's a short example:
> >
> > qemu-system-x86_64 -hda ~/images/linux.img -snapshot -vnc :2
> >
> > Would become `foo.qemu':
> >
> > # Main disk image
> > hda=/home/anthony/images/linux.img
> >
> > # Redirect disk writes to a temporary image
> > snapshot
> >
> > # Make the graphical display available on port 5902
> > vnc=:2
> >
> > With:
> >
> > qemu-system-x86_64 -config foo.qemu
> >
>
> One thought I had, is that it would be very nice to break up the -drive
> file=foo.img,if=scsi syntax within the config file. In general, I'm
> thinking something like:
>
> [drive]
> file=foo.img
> if=scsi
>
> or:
>
> drive {
> file=foo.img
> if=scsi
> }
I like this one and it would be nice to be able to replace the equal
sign with whitespace.
What I'd love, though, but expect others will consider bloat, is that
files are passed through cpp before interpreting. This way the syntax
becomes not (much) less powerful than the current command line
invocation where you get variable expansion for free. I would hate to
type in some things in as many times as there are instances of a given
hardware. Consider some disk arrays or the once discussed -pins
switch for initial state of pins or jumpers (some machines have
hundreds of them).
--
Please do not print this email unless absolutely necessary. Spread
environmental awareness.
|
|
From: Paul B. <pa...@co...> - 2008-05-14 14:26:29
|
> I suggested it because my original plan for the configuration file was
> based on this syntax with a strong inspiration from the OpenFirmware
> device tree. The idea was that the object name ("drive" here) had no
> hardcoded meaning, except for some predefined object names in order to
> keep a kind of backward compatibility with the current QEMU options. In
> order to create a new drive for example, you just have to do:
>
> mydrive.class=drive
> mydrive.if=scsi
> mydrive.file=abc.img
>
> the "class" field is used to select the device model. Then all the other
> parameters are used to initialize the device model. That way it is
> possible to keep the compatibility with the existing options and add a
> provision to instanciate arbitrary new device models, such as:
I like the idea, but I'm not so keen on the automatic allocation. I generally
prefer explicit declaration over implicit things. The latter makes it very
easy to not notice when you make a typo.
It sounds like what you really want is something similar to an OF device tree.
So you have something like:
# pciide0 may be an alias (possibly provided by qemu)
# e.g. pci0.slot1.func1.ide
alias hda ide0.primary.master
hda.type=disk
hda.file=foo.img
You can then define some form of magic aliases that select the next unused
device. e.g.
alias mydrive $next_ide_disk
IMHO This provides the flexibility and structure that Fabrice is talking
about, and with suitable aliases can be made to look a lot like the existing
options.
This may require some internal restructuring to allow the machine descriptions
to feed into the user config file.
Thoughts?
Paul
|
|
From: Anthony L. <ali...@us...> - 2008-05-14 14:06:57
|
Fabrice Bellard wrote:
> Avi Kivity wrote:
>> Fabrice Bellard wrote:
>>>
>>> I prefer:
>>>
>>> drive.file=foo.img
>>> drive.if=scsi
>>>
>>
>> That doesn't support multiple drives very well.
>
> Right, I realized it afterwards !
>
> I suggested it because my original plan for the configuration file was
> based on this syntax with a strong inspiration from the OpenFirmware
> device tree. The idea was that the object name ("drive" here) had no
> hardcoded meaning, except for some predefined object names in order to
> keep a kind of backward compatibility with the current QEMU options.
> In order to create a new drive for example, you just have to do:
>
> mydrive.class=drive
> mydrive.if=scsi
> mydrive.file=abc.img
>
> the "class" field is used to select the device model. Then all the
> other parameters are used to initialize the device model. That way it
> is possible to keep the compatibility with the existing options and
> add a provision to instanciate arbitrary new device models, such as:
I like this syntax primarily because it provides a means to associate
arbitrary data with a VM. It also provides a sane way to keep track of
which device is which so that the "config" can be updated while the VM
is running. I'll update the patch.
Regards,
Anthony Liguori
> mynetworkcard.class="ne2000pci"
> mynetworkcard.bus=1 # pci bus selection
> mynetworkcard.macaddr=00:01:02:03:04:05
> mynetworkcard.vlan=1
>
> I will strongly support configuration file formats having this property.
>
> Regards,
>
> Fabrice.
>
|
|
From: Tomasz C. <ma...@wp...> - 2008-05-14 13:52:41
|
Avi Kivity wrote: > This is the second release of network drivers for Windows guests running > on a kvm host. The drivers are intended for Windows 2000 and Windows > XP, and Windows 2003. Both x86 and x64 variants are provided. kvm-61 > or later is needed in the host. At the moment only binaries are available. Hi, This is great news! Do you have any performance numbers for networking to see how it compares to the real hardware? - Linux host (or: real Windows running on that host) - PV Windows (network driver) - non-PV Windows -- Tomasz Chmielewski http://wpkg.org |
|
From: OCEANIC <oce...@ya...> - 2008-05-14 13:46:18
|
新しいメールアドレスをお知らせします新しいメールアドレス： oce...@ya... This is to officially inform you that we have verified your contract/inheritance fund file and found out that you have not received your fund,you will receive it thru this card,forward your name, address and direct telephone number. Rev.peter Precious. +234-8029094044. - OCEANIC |
|
From: Daniel P. B. <ber...@re...> - 2008-05-14 13:35:32
|
On Wed, May 14, 2008 at 02:26:40PM +0200, Fabrice Bellard wrote:
> Avi Kivity wrote:
> > Fabrice Bellard wrote:
> >>
> >> I prefer:
> >>
> >> drive.file=foo.img
> >> drive.if=scsi
> >>
> >
> > That doesn't support multiple drives very well.
>
> Right, I realized it afterwards !
>
> I suggested it because my original plan for the configuration file was
> based on this syntax with a strong inspiration from the OpenFirmware
> device tree. The idea was that the object name ("drive" here) had no
> hardcoded meaning, except for some predefined object names in order to
> keep a kind of backward compatibility with the current QEMU options. In
> order to create a new drive for example, you just have to do:
>
> mydrive.class=drive
> mydrive.if=scsi
> mydrive.file=abc.img
With this kind of syntax, now tools generating config files need to make
up unique names for each drive. So you'll probably end up with them just
naming things based on the class name + a number appended.
drive0.class=drive
drive0.if=scsi
drive0.file=foo.img
drive1.class=drive
drive1.if=scsi
drive1.file=bar.img
drive2.class=drive
...
Which suggests it'd be better to take your original previous syntax example
and using an explicit numeric component to represent lists of drives, eg
drive.0.file=foo.img
drive.0.if=scsi
drive.1.file=bar.img
drive.1.if=scsi
drive.2.file=wiz.img
drive.2.if=scsi
Thus avoiding the need for adding the 'class' setting at all
Dan.
--
|: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
|
|
From: SourceForge.net <no...@so...> - 2008-05-14 13:18:40
|
Bugs item #1958715, was opened at 2008-05-06 15:13 Message generated for change (Comment added) made by gthouvenin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958715&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libkvm Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: gth (gthouvenin) Assigned to: Nobody/Anonymous (nobody) Summary: kvm-userspace failed to start linux kernel (kernel panic) Initial Comment: CPU: Intel Xeon (eight cpu) KVM: kvm-68-2049-g6307419 Host kernel arch: x86_64 Guest: Ubuntu-8.04-desktop-i386 livecd QEMU Command: qemu-system-x86_64 -cdrom /images_iso/ubuntu-8.04-desktop-i386.iso -boot d -m 256 KVM-USERSPACE: kvm-66-147-gc33833a The problem doesn't go away if I'm using the -no-kvm-irqchip or -no-kvm-pit switch. When I use the commit bae043c (kvm-userspace) I can start the liveCD but the next commit c33833a produces a kernel panic. I see the screen with different choice of installation but when I choose to install linux I get a kernel panic (see file attach). It also happens with an old fedora that is installed on a qcow2 file. Regards, Guillaume ---------------------------------------------------------------------- >Comment By: gth (gthouvenin) Date: 2008-05-14 15:18 Message: Logged In: YES user_id=1938803 Originator: YES The bug disappeared with commit 9ac293621d3c467f. I don't know if it's this commit that solves the problem (probably not) but it's working now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1958715&group_id=180599 |
|
From: Jack S. <st...@sg...> - 2008-05-14 13:16:08
|
On Tue, May 13, 2008 at 10:43:59PM -0700, Benjamin Herrenschmidt wrote: > On Tue, 2008-05-13 at 22:14 +1000, Nick Piggin wrote: > > ea. > > > > I don't see why you're bending over so far backwards to accommodate > > this GRU thing that we don't even have numbers for and could actually > > potentially be batched up in other ways (eg. using mmu_gather or > > mmu_gather-like idea). > > I agree, we're better off generalizing the mmu_gather batching > instead... Unfortunately, we are at least several months away from being able to provide numbers to justify batching - assuming it is really needed. We need large systems running real user workloads. I wish we had that available right now, but we don't. It also depends on what you mean by "no batching". If you mean that the notifier gets called for each pte that is removed from the page table, then the overhead is clearly very high for some operations. Consider the unmap of a very large object. A TLB flush per page will be too costly. However, something based on the mmu_gather seems like it should provide exactly what is needed to do efficient flushing of the TLB. The GRU does not require that it be called in a sleepable context. As long as the notifier callout provides the mmu_gather and vaddr range being flushed, the GRU can do the efficiently do the rest. > > I had some never-finished patches to use the mmu_gather for pretty much > everything except single page faults, tho various subtle differences > between archs and lack of time caused me to let them take the dust and > not finish them... > > I can try to dig some of that out when I'm back from my current travel, > though it's probably worth re-doing from scratch now. > > Ben. > -- jack |
|
From: Avi K. <av...@qu...> - 2008-05-14 12:38:31
|
Anthony Liguori wrote: > We need to be able to send fragmented packets in KVM to avoid an extra copy > in the TX path. This patch adds a qemu_sendv_packet() function to send > fragemented packets. It also provides backwards compatibility for old clients > that don't support the new interface. > Applied all, thanks. -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-05-14 12:34:38
|
Christian Borntraeger wrote: > as this patch is now in your queue, can you push this change > --- > commit eee4646877b748afbfd34d8dbe6ea9b454a65745 > Author: Heiko Carstens <hei...@de...> > Date: Tue May 6 17:38:30 2008 +0300 > > s390: KVM guest: fix compile error > --- > > soon to Linus? kvm still does not compile on s390. > Certainly; I plan to push my queue in a day or two. -- error compiling committee.c: too many arguments to function |
|
From: Avi K. <av...@qu...> - 2008-05-14 12:33:35
|
Zhang, Xiantao wrote: > Hi, Avi > This patch should be a fix for v2.6.26. Otherwise, guests can't > enable networking. > Xiantao > > Subject: [PATCH] KVM: KVM/IA64: Set KVM_IOAPIC_NUM_PINS to 48. > > Guest's firmware needs the viosapic with 48 pins for ia64 guests. > Applied and queued, thanks. -- error compiling committee.c: too many arguments to function |
|
From: Fabrice B. <fa...@be...> - 2008-05-14 12:26:37
|
Avi Kivity wrote:
> Fabrice Bellard wrote:
>>
>> I prefer:
>>
>> drive.file=foo.img
>> drive.if=scsi
>>
>
> That doesn't support multiple drives very well.
Right, I realized it afterwards !
I suggested it because my original plan for the configuration file was
based on this syntax with a strong inspiration from the OpenFirmware
device tree. The idea was that the object name ("drive" here) had no
hardcoded meaning, except for some predefined object names in order to
keep a kind of backward compatibility with the current QEMU options. In
order to create a new drive for example, you just have to do:
mydrive.class=drive
mydrive.if=scsi
mydrive.file=abc.img
the "class" field is used to select the device model. Then all the other
parameters are used to initialize the device model. That way it is
possible to keep the compatibility with the existing options and add a
provision to instanciate arbitrary new device models, such as:
mynetworkcard.class="ne2000pci"
mynetworkcard.bus=1 # pci bus selection
mynetworkcard.macaddr=00:01:02:03:04:05
mynetworkcard.vlan=1
I will strongly support configuration file formats having this property.
Regards,
Fabrice.
|
|
From: Zhang, X. <xia...@in...> - 2008-05-14 12:07:46
|
Hi, Avi
This patch should be a fix for v2.6.26. Otherwise, guests can't
enable networking.
Xiantao
>From df3a290e438b3079edb3627f2fea3e1fdd85b5f2 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <xia...@in...>
Date: Wed, 14 May 2008 19:44:57 +0800
Subject: [PATCH] KVM: KVM/IA64: Set KVM_IOAPIC_NUM_PINS to 48.
Guest's firmware needs the viosapic with 48 pins for ia64 guests.
Signed-off-by: Xiantao Zhang <xia...@in...>
---
include/asm-ia64/kvm.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-ia64/kvm.h b/include/asm-ia64/kvm.h
index eb2d355..f9db48e 100644
--- a/include/asm-ia64/kvm.h
+++ b/include/asm-ia64/kvm.h
@@ -29,7 +29,7 @@
/* Architectural interrupt line count. */
#define KVM_NR_INTERRUPTS 256
-#define KVM_IOAPIC_NUM_PINS 24
+#define KVM_IOAPIC_NUM_PINS 48
struct kvm_ioapic_state {
__u64 base_address;
--
1.5.2
|
|
From: Robin H. <ho...@sg...> - 2008-05-14 11:26:22
|
On Wed, May 14, 2008 at 06:11:22AM +0200, Nick Piggin wrote: > On Tue, May 13, 2008 at 10:32:38AM -0500, Robin Holt wrote: > > On Tue, May 13, 2008 at 10:06:44PM +1000, Nick Piggin wrote: > > > On Thursday 08 May 2008 10:38, Robin Holt wrote: > > > > In order to invalidate the remote page table entries, we need to message > > > > (uses XPC) to the remote side. The remote side needs to acquire the > > > > importing process's mmap_sem and call zap_page_range(). Between the > > > > messaging and the acquiring a sleeping lock, I would argue this will > > > > require sleeping locks in the path prior to the mmu_notifier invalidate_* > > > > callouts(). > > > > > > Why do you need to take mmap_sem in order to shoot down pagetables of > > > the process? It would be nice if this can just be done without > > > sleeping. > > > > We are trying to shoot down page tables of a different process running > > on a different instance of Linux running on Numa-link connected portions > > of the same machine. > > Right. You can zap page tables without sleeping, if you're careful. I > don't know that we quite do that for anonymous pages at the moment, but it > should be possible with a bit of thought, I believe. > > > > The messaging is clearly going to require sleeping. Are you suggesting > > we need to rework XPC communications to not require sleeping? I think > > that is going to be impossible since the transfer engine requires a > > sleeping context. > > I guess that you have found a way to perform TLB flushing within coherent > domains over the numalink interconnect without sleeping. I'm sure it would > be possible to send similar messages between non coherent domains. I assume by coherent domains, your are actually talking about system images. Our memory coherence domain on the 3700 family is 512 processors on 128 nodes. On the 4700 family, it is 16,384 processors on 4096 nodes. We extend a "Read-Exclusive" mode beyond the coherence domain so any processor is able to read any cacheline on the system. We also provide uncached access for certain types of memory beyond the coherence domain. For the other partitions, the exporting partition does not know what virtual address the imported pages are mapped. The pages are frequently mapped in a different order by the MPI library to help with MPI collective operations. For the exporting side to do those TLB flushes, we would need to replicate all that importing information back to the exporting side. Additionally, the hardware that does the TLB flushing is protected by a spinlock on each system image. We would need to change that simple spinlock into a type of hardware lock that would work (on 3700) outside the processors coherence domain. The only way to do that is to use uncached addresses with our Atomic Memory Operations which do the cmpxchg at the memory controller. The uncached accesses are an order of magnitude or more slower. > So yes, I'd much rather rework such highly specialized system to fit in > closer with Linux than rework Linux to fit with these machines (and > apparently slow everyone else down). But it isn't that we are having a problem adapting to just the hardware. One of the limiting factors is Linux on the other partition. > > Additionally, the call to zap_page_range expects to have the mmap_sem > > held. I suppose we could use something other than zap_page_range and > > atomically clear the process page tables. > > zap_page_range does not expect to have mmap_sem held. I think for anon > pages it is always called with mmap_sem, however try_to_unmap_anon is > not (although it expects page lock to be held, I think we should be able > to avoid that). zap_page_range calls unmap_vmas which walks to vma->next. Are you saying that can be walked without grabbing the mmap_sem at least readably? I feel my understanding of list management and locking completely shifting. > > Doing that will not alleviate > > the need to sleep for the messaging to the other partitions. > > No, but I'd venture to guess that is not impossible to implement even > on your current hardware (maybe a firmware update is needed)? Are you suggesting the sending side would not need to sleep or the receiving side? Assuming you meant the sender, it spins waiting for the remote side to acknowledge the invalidate request? We place the data into a previously agreed upon buffer and send an interrupt. At this point, we would need to start spinning and waiting for completion. Let's assume we never run out of buffer space. The receiving side receives an interrupt. The interrupt currently wakes an XPC thread to do the work of transfering and delivering the message to XPMEM. The transfer of the data which XPC does uses the BTE engine which takes up to 28 seconds to timeout (hardware timeout before raising and error) and the BTE code automatically does a retry for certain types of failure. We currently need to grab semaphores which _MAY_ be able to be reworked into other types of locks. Thanks, Robin |
|
From: Christian B. <bor...@de...> - 2008-05-14 10:38:24
|
Am Montag, 5. Mai 2008 schrieb Avi Kivity:
> I can, but tell me which one. Also, the patch (Heiko's) needs a
> changelog entry and a signoff.
Avi,
as this patch is now in your queue, can you push this change
---
commit eee4646877b748afbfd34d8dbe6ea9b454a65745
Author: Heiko Carstens <hei...@de...>
Date: Tue May 6 17:38:30 2008 +0300
s390: KVM guest: fix compile error
---
soon to Linus? kvm still does not compile on s390.
Thank you
Christian
|
|
From: Avi K. <av...@qu...> - 2008-05-14 10:31:12
|
Fabrice Bellard wrote: > > I prefer: > > drive.file=foo.img > drive.if=scsi > That doesn't support multiple drives very well. -- error compiling committee.c: too many arguments to function |
157 messages has been excluded from this view by a project administrator.
