我怎么退订邮件
> Date: Mon, 7 Jun 2010 19:52:22 -0400 > From: qemu-devel-requ...@nongnu.org > Subject: Qemu-devel Digest, Vol 87, Issue 177 > To: qemu-devel@nongnu.org > > Send Qemu-devel mailing list submissions to > qemu-devel@nongnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.nongnu.org/mailman/listinfo/qemu-devel > or, via email, send a message with subject or body 'help' to > qemu-devel-requ...@nongnu.org > > You can reach the person managing the list at > qemu-devel-ow...@nongnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Qemu-devel digest..." > > > Today's Topics: > > 1. Re: [PATCH v3 00/17] clean up vl.c code (Juan Quintela) > 2. Re: [PATCH] configure: add an option to disable vlans > (Anthony Liguori) > 3. Re: [RFC] Moving the kvm ioapic, pic, and pit back to > userspace (Anthony Liguori) > 4. KVM call agenda for June 8 (Chris Wright) > 5. Re: KVM call agenda for June 8 (Anthony Liguori) > 6. Re: Getting tcg in a standalone library (Alexander Graf) > 7. [PATCH 03/22] QemuOpts: add function to set QemuOpts from > defaults (Anthony Liguori) > 8. [PATCH 0/22] Refactor machine support (Anthony Liguori) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 07 Jun 2010 23:41:40 +0200 > From: Juan Quintela <quint...@redhat.com> > Subject: [Qemu-devel] Re: [PATCH v3 00/17] clean up vl.c code > To: jes.soren...@redhat.com > Cc: qemu-devel@nongnu.org > Message-ID: <m3wruazfjf....@trasno.mitica> > Content-Type: text/plain; charset=us-ascii > > jes.soren...@redhat.com wrote: > > From: Jes Sorensen <jes.soren...@redhat.com> > > > > Hi, > > > > Ok third time lucky ... I hope! This fixes the missing git add on > > qemu-options.h as building for win32 using mingw (thanks Paolo!). > > > > The patches try to clean up the vl.c code by separating out OS > > specific code into OS specific files. Basically it is focused on > > moving things into os-posix.c for most UNIX/Linux systems, and > > os-win32.c for win32 specific bits. > > > > I have tried to be as careful as I can to not break non Linux support, > > but so far the patch has only been tested on Linux. > > > > Oh and this time without 'I am not very clever' editor backup files! > > > > Thanks, > > Jes > > Acked-by: Juan Quintela <quint...@redhat.com> > > Nice, thanks. Once there, perhaps you want to look about moving osdep.c > definitions to os-{posix,win32}.c. And no, that file is not nice > either. > > > > ------------------------------ > > Message: 2 > Date: Mon, 07 Jun 2010 16:57:09 -0500 > From: Anthony Liguori <anth...@codemonkey.ws> > Subject: Re: [Qemu-devel] [PATCH] configure: add an option to disable > vlans > To: "Michael S. Tsirkin" <m...@redhat.com> > Cc: Paul Brook <p...@codesourcery.com>, qemu-devel@nongnu.org > Message-ID: <4c0d6b35.8080...@codemonkey.ws> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 06/07/2010 04:37 PM, Anthony Liguori wrote: > > On 06/07/2010 03:58 PM, Michael S. Tsirkin wrote: > >> On Mon, Jun 07, 2010 at 03:40:57PM -0500, Anthony Liguori wrote: > >>> On 06/07/2010 02:21 PM, Michael S. Tsirkin wrote: > >>>> So I see two ways to go forward: switch default value in my patch, > >>>> or disable vlans unconditionally. > >>>> > >>> The problem with disabling vlans unconditionally is that you break -net > >>> socket and -net dump. > >>> > >>> If we can come up with an alternative way to do these things, I'm all > >>> for removing it. > >> Hmm, I'll try to look at supporting -net socket in netdev. > >> Does -net dump do anything that can't be done with tap+tcpdump? > > > > tap+tcpdump requires root privileges (even if you have a tap helper). > > > > Plus tcpdump doesn't help with slirp and -net dump is very useful for > > debugging slirp. > > Of course, you could add this functionality to netdev. It's arguably > better there too because then you can debug virtio-net+tap with full > offload enabled (which you cannot do today). > > Regards, > > Anthony Liguori > > > > > ------------------------------ > > Message: 3 > Date: Mon, 07 Jun 2010 17:23:57 -0500 > From: Anthony Liguori <anth...@codemonkey.ws> > Subject: [Qemu-devel] Re: [RFC] Moving the kvm ioapic, pic, and pit > back to userspace > To: Avi Kivity <a...@redhat.com> > Cc: qemu-devel <qemu-devel@nongnu.org>, KVM list <k...@vger.kernel.org> > Message-ID: <4c0d717d.8010...@codemonkey.ws> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 06/07/2010 01:42 PM, Avi Kivity wrote: > > On 06/07/2010 08:04 PM, Anthony Liguori wrote: > >> > >> I think we could also move the local APIC. > > > > I'm not even sure we can safely move the ioapic/pic (mostly due to > > churn). But the local APIC is so heavily accessed by the guest that > > it's impossible to move it. Run an ftrace one day, especially on an > > smp guest. Every IPI requires several APIC accesses. Before a halt a > > tickless kernel sets the wakeup timer. EOIs. > > > >> > >> To optimize device models, we've tended to put the full device model > >> in the kernel whereas the hardware vendors have tended to put only > >> the fast paths of the devices models in hardware. > >> > >> For instance, we could introduce a userspace interface similar to > >> vapic support whereas a shared page that mapped the APIC's layout was > >> used with a mask to select which registers trapped on read/write. > > > > That leads to very problematic interfaces. When you separate along a > > device boundary, you have a spec that defines the software > > interfaces. When you separate along a boundary that you define, it's > > up to you to get everything right. > > > > In fact with the ioapic/pic/lapic one of the problems is that the > > interconnection between the devices that is not well defined, and > > that's where we have bugs. > > > >> > >> That said, I can understand an argument that the local APIC is part > >> of the CPU state since it's a very special type of device. > >> > >> A better example would be a generic counter kernel mechanism. I can > >> envision such a device as doing nothing more than providing a > >> read-only view of a counter with a userspace configurable divider and > >> width. Any write to the counter or read of any other byte outside > >> the counter register would result in a trap to userspace. > > > > What about latches? byte access to word registers? There will be as > > many special cases as there are timers. > > > > If the kernel supported a bytecode/jit facility I'd happily use that > > to download portions of the device model into the kernel. > > > >> > >> That should allow both the PIT and the HPET to be accelerated with > >> minimal effort in the kernel. > > > > IMO it's probably more effort than porting HPET to the kernel. Try > > outlining an interface that supports PIT, HPET, RTC, and ACPI PMTIMER. > > I was referring specifically to time sources, not time events. > > An accelerated counter for HPET is pretty trivial. It's a 32-bit > register that's actually a nanosecond value in qemu. We need to be able > to set an offset from the host wall clock time, a means to stop it, and > a means to start it. > > The PIT is latched so the kernel needs to know enough about how to > decode the PIT state to understand the latching. There's very little > state associated with latching though so I don't think this is a huge > problem. It's a fixed value write to a fixed register followed by a > read to a fixed register. The act of latching doesn't effect the state > beyond the fact that you need to save the latched value in the event > that you have a live migration before reading the latched value. > > The PMTIMER is also pretty straight forward. It's a variable port > address (that's fixed during execution). > > Even if we require three separate interfaces, the interfaces are so > simply that it seems like an obvious win. > > >> > >> I'd be in favor of a straight port to userspace. We already have the > >> interfaces to communicate with an external device model for these > >> devices so let's just take the kernel code and stick it into > >> dedicated threads in userspace. > > > > Currently we support an all-or-nothing approach. I don't think local > > APIC in userspace is worthwhile. Esp. as it will slow down vhost and > > assigned devices significantly - interrupts will have to be mediated > > by userspace. > > Yeah, as I said, I can understand the arguments for keeping the lapic in > the kernel. > > >> > >> I think it's easier to then work to merge the two bits of code in the > >> same tree than it is to try and take out-of-tree code and merge it > >> incrementally. > > > > Are you talking about qemu.git/qemu-kvm.git? That's the least of my > > concerns, I'm worried about kvm.git. > > qemu.git. > > >> > >>> 5. Risk > >>> > >>> We may find out after all this is implemented that performance is > >>> not acceptable and all the work will have to be dropped. > >> > >> That's another advantage to a straight port to userspace. We can > >> collect performance data with only a modest amount of engineering > >> effort. > > > > Port what exactly? We have a userspace irqchip implementation. What > > we don't have is just the ioapic/pic/pit in userspace, and the only > > way to try it out is to implement the whole thing. > > If you take the kernel code and do a pretty straight port: switching > kernel functions to libc functions and maintaining all the existing > locking via pthreads, you could then implement a very simple MMIO/PIO > dispatch mechanism in the kvm code that shortcutted those devices before > we ever hit the qemu_mutex and the traditional qemu code paths. It > should be a relatively easy conversion and it gives a proper vehicle for > doing experimentations. > > In fact, you could pretty quickly determine viability by porting the PIT > to userspace and implementing a vpit interface in the kernel that > allowed the channel 0 counters to be latched and read within lightweight > exits. > > Regards, > > Anthony Liguori > > > > > ------------------------------ > > Message: 4 > Date: Mon, 7 Jun 2010 15:26:37 -0700 > From: Chris Wright <chr...@redhat.com> > Subject: [Qemu-devel] KVM call agenda for June 8 > To: k...@vger.kernel.org > Cc: qemu-devel@nongnu.org > Message-ID: <20100607222637.ga21...@x200.localdomain> > Content-Type: text/plain; charset=us-ascii > > Please send in any agenda items you are interested in covering. > > If we have a lack of agenda items I'll cancel the week's call. > > thanks, > -chris > > > > ------------------------------ > > Message: 5 > Date: Mon, 07 Jun 2010 17:41:51 -0500 > From: Anthony Liguori <anth...@codemonkey.ws> > Subject: [Qemu-devel] Re: KVM call agenda for June 8 > To: Chris Wright <chr...@redhat.com> > Cc: qemu-devel@nongnu.org, k...@vger.kernel.org > Message-ID: <4c0d75af.7050...@codemonkey.ws> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 06/07/2010 05:26 PM, Chris Wright wrote: > > Please send in any agenda items you are interested in covering. > > > > If we have a lack of agenda items I'll cancel the week's call. > > > > > > - Accelerating counters (aka moving PIT to userspace, keeping HPET in > userspace) > - Live migration + hotplug > > Regards, > > Anthony Liguori > > > thanks, > > -chris > > -- > > 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 > > > > > > > ------------------------------ > > Message: 6 > Date: Tue, 8 Jun 2010 01:35:47 +0200 > From: Alexander Graf <ag...@suse.de> > Subject: Re: [Qemu-devel] Getting tcg in a standalone library > To: Peter Fritzsche <peter.fritzs...@gmx.de> > Cc: qemu-devel@nongnu.org > Message-ID: <cc39af26-861d-4864-81f9-fe4688048...@suse.de> > Content-Type: text/plain; charset=us-ascii > > > On 07.06.2010, at 23:27, Peter Fritzsche wrote: > > > Hi, > > > > I am currently quite interesting in tcg for binary translation. There are > > many > > emulator projects (I mean mostly console emulators) out there which start > > to > > implement more or less bad ILs to translate their specific cpu (for example > > gameboy has z80, n64 has r4300i, gamecube has powerpc 750CXe, ...). These > > are > > most of the time x86 only and very limited. But it seems that qemu's cpu > > libraries aren't made for those cpu's and don't seem to provide the needed > > infrastructure for emulating such highly integrated systems (please correct > > me > > if I am wrong). > > The old stuff is pretty tough, as it's timing critical. Everything as of the > GC should be fairly easy to emulate using tcg though, as you can just count > the overall emulated instructions and throttle it lazily from there. That's > basically what Dolphin does too. > > For the 750CXe all that's left to do is to emulate the paired single > instructions. And I have a full emulation of those in the KVM code already, > so you could take it from there. > > > I think that the best way to share code would be if other projects could > > also > > use tcg for their translation needs. But it seems to me that it it to > > tightly > > integrated into qemu and cannot be ripped out. Are their any plans to open > > it > > for other projects as you have already done it with the emulation cores? > > Yes, I agree. That would indeed be useful. Patches are welcome. > > > Alex > > > > > ------------------------------ > > Message: 7 > Date: Mon, 7 Jun 2010 18:51:51 -0500 > From: Anthony Liguori <aligu...@us.ibm.com> > Subject: [Qemu-devel] [PATCH 03/22] QemuOpts: add function to set > QemuOpts from defaults > To: qemu-devel@nongnu.org > Cc: Glauber Costa <glom...@redhat.com>, Anthony Liguori > <aligu...@us.ibm.com>, Gerd Hoffman <kra...@redhat.com> > Message-ID: <1275954730-8196-4-git-send-email-aligu...@us.ibm.com> > > This lets us hard code a list of default QemuOpts values in a structured way. > > Signed-off-by: Anthony Liguori <aligu...@us.ibm.com> > > diff --git a/qemu-option.c b/qemu-option.c > index 03b1ef7..b990cf5 100644 > --- a/qemu-option.c > +++ b/qemu-option.c > @@ -954,3 +954,23 @@ int qemu_opts_foreach(QemuOptsList *list, > qemu_opts_loopfunc func, void *opaque, > loc_pop(&loc); > return rc; > } > + > +int qemu_opts_set_defaults(QemuOpts *opts, const QemuOptValue *defvals) > +{ > + int i; > + > + for (i = 0; defvals[i].name; i++) { > + int ret; > + > + if (qemu_opt_get(opts, defvals[i].name)) { > + continue; > + } > + > + ret = qemu_opt_set(opts, defvals[i].name, defvals[i].value); > + if (ret < 0) { > + return ret; > + } > + } > + > + return 0; > +} > diff --git a/qemu-option.h b/qemu-option.h > index 4823219..4a6717c 100644 > --- a/qemu-option.h > +++ b/qemu-option.h > @@ -104,6 +104,11 @@ struct QemuOptsList { > QemuOptDesc desc[]; > }; > > +typedef struct QemuOptValue { > + const char *name; > + const char *value; > +} QemuOptValue; > + > const char *qemu_opt_get(QemuOpts *opts, const char *name); > int qemu_opt_get_bool(QemuOpts *opts, const char *name, int defval); > uint64_t qemu_opt_get_number(QemuOpts *opts, const char *name, uint64_t > defval); > @@ -113,6 +118,8 @@ typedef int (*qemu_opt_loopfunc)(const char *name, const > char *value, void *opaq > int qemu_opt_foreach(QemuOpts *opts, qemu_opt_loopfunc func, void *opaque, > int abort_on_failure); > > +int qemu_opts_set_defaults(QemuOpts *opts, const QemuOptValue *defvals); > + > QemuOpts *qemu_opts_find(QemuOptsList *list, const char *id); > QemuOpts *qemu_opts_create(QemuOptsList *list, const char *id, int > fail_if_exists); > int qemu_opts_set(QemuOptsList *list, const char *id, > -- > 1.7.0.4 > > > > > ------------------------------ > > Message: 8 > Date: Mon, 7 Jun 2010 18:51:48 -0500 > From: Anthony Liguori <aligu...@us.ibm.com> > Subject: [Qemu-devel] [PATCH 0/22] Refactor machine support > To: qemu-devel@nongnu.org > Cc: Glauber Costa <glom...@redhat.com>, Paul Brook > <p...@codesourcery.com> > Message-ID: <1275954730-8196-1-git-send-email-aligu...@us.ibm.com> > > This series introduces a rather radical change in the way we deal with machine > definitions in QEMU. Here are the features this series introduces: > > - Machines are definable via a -machine-def option or a [machine-def] config > stanza > - Parameters such as -kernel, -initrd, -append, -m, -acpi-enable, > -enable-kvm, > and potentially many more are now support via a config > - It's possible to set a default block format (ide, scsi, virtio) for a > machine > - It's possible to make kvm enablement a property of a machine type. The > support modes are KVM enabled, TCG enabled, and KVM enabled with TCG > fallback. > - All properties of the default machine type are overridable via global > config. > IOW, you can make KVM enablement default without touching the source code. > You can also increase the default ram size without touching any code. > > Conceptually, it works by introducing a MachineCore concept. A MachineCore is > a function that is able to create a machine based on a set of user specified > parameters. These parameters may be high level properties (like ram size) or > qdev global properties (virtio-blk-pci.vectors). > > A builtin Machine is an instance of a MachineCore that has a set of default > parameters set. > > The concept of MachineCore is *not* a stop-gap measure for proper qdev > conversion. Rather, the idea behind MachineCore is that it's a device tree > builder. > > You certainly could still have a machine described purely by a device tree and > qdev properties but that's not enough to represent the UI that we currently > expose. We need a way convert user visible operations like enable usb to > platform specific operations like add a PIIX3 USB hub. This is what a > MachineCore does. > > > > ------------------------------ > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > > > End of Qemu-devel Digest, Vol 87, Issue 177 > ******************************************* _________________________________________________________________ SkyDrive电子画册，带你领略精彩照片，分享“美”时“美”刻! http://www.windowslive.cn/campaigns/e-magazine/ngmchina/?a=c
