[Qemu-devel] RE: Qemu-devel Digest, Vol 87, Issue 177

[孙澈]

我怎么退订邮件

> Date: Mon, 7 Jun 2010 19:52:22 -0400
> From: address@hidden
> Subject: Qemu-devel Digest, Vol 87, Issue 177
> To: address@hidden
>
> Send Qemu-devel mailing list submissions to
> address@hidden
>
> 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
> address@hidden
>
> You can reach the person managing the list at
> address@hidden
>
> 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 <address@hidden>
> Subject: [Qemu-devel] Re: [PATCH v3 00/17] clean up vl.c code
> To: address@hidden
> Cc: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> address@hidden wrote:
> > From: Jes Sorensen <address@hidden>
> >
> > 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 <address@hidden>
>
> 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 <address@hidden>
> Subject: Re: [Qemu-devel] [PATCH] configure: add an option to disable
> vlans
> To: "Michael S. Tsirkin" <address@hidden>
> Cc: Paul Brook <address@hidden>, address@hidden
> Message-ID: <address@hidden>
> 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 <address@hidden>
> Subject: [Qemu-devel] Re: [RFC] Moving the kvm ioapic, pic, and pit
> back to userspace
> To: Avi Kivity <address@hidden>
> Cc: qemu-devel <address@hidden>, KVM list <address@hidden>
> Message-ID: <address@hidden>
> 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 <address@hidden>
> Subject: [Qemu-devel] KVM call agenda for June 8
> To: address@hidden
> Cc: address@hidden
> Message-ID: <address@hidden>
> 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 <address@hidden>
> Subject: [Qemu-devel] Re: KVM call agenda for June 8
> To: Chris Wright <address@hidden>
> Cc: address@hidden, address@hidden
> Message-ID: <address@hidden>
> 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 address@hidden
> > 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 <address@hidden>
> Subject: Re: [Qemu-devel] Getting tcg in a standalone library
> To: Peter Fritzsche <address@hidden>
> Cc: address@hidden
> Message-ID: <address@hidden>
> 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 <address@hidden>
> Subject: [Qemu-devel] [PATCH 03/22] QemuOpts: add function to set
> QemuOpts from defaults
> To: address@hidden
> Cc: Glauber Costa <address@hidden>, Anthony Liguori
> <address@hidden>, Gerd Hoffman <address@hidden>
> Message-ID: <address@hidden>
>
> This lets us hard code a list of default QemuOpts values in a structured way.
>
> Signed-off-by: Anthony Liguori <address@hidden>
>
> 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 <address@hidden>
> Subject: [Qemu-devel] [PATCH 0/22] Refactor machine support
> To: address@hidden
> Cc: Glauber Costa <address@hidden>, Paul Brook
> <address@hidden>
> Message-ID: <address@hidden>
>
> 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
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
> End of Qemu-devel Digest, Vol 87, Issue 177
> *******************************************

---

聊天+搜索+邮箱 想要轻松出游,手机MSN帮你搞定! 立刻下载！