Paolo Bonzini wrote:
> Il 10/01/2013 16:25, Jamie Lokier ha scritto:
> >> > Perhaps it's a bug that the cache mode is not reset when the machine is
> >> > reset. I haven't checked that, but it would be a valid complaint.
> > The question is, is ca
Paolo Bonzini wrote:
> Il 09/01/2013 14:04, Liu Yuan ha scritto:
> > > > 2 The upper layer software which relies on the 'cache=xxx' to choose
> > > > cache mode will fail its assumption against new QEMU.
> > >
> > > Which assumptions do you mean? As far as I can say the behaviour hasn't
> > > ch
Kevin Wolf wrote:
> Am 08.01.2013 11:39, schrieb Liu Yuan:
> > On 01/08/2013 06:00 PM, Kevin Wolf wrote:
> >> Am 08.01.2013 10:45, schrieb Liu Yuan:
> >>> On 01/08/2013 05:40 PM, Stefan Hajnoczi wrote:
> Otherwise use sheepdog writeback and let QEMU block.c decide when to
> flush. Never
Matthew Ogilvie wrote:
> 2. Just fix it immediately, and don't worry about migration. Squash
>the last few patches together. A single missed periodic
>timer tick that only happens when migrating
>between versions of qemu is probably not a significant
>concern. (Unless someone kno
Peter Maydell wrote:
> On 23 November 2012 15:31, Jamie Lokier wrote:
> > x86 instruction sets haven't followed a linear progression of features
> > for quite a while, especially including non-Intel chips, so it stopped
> > making sense for GCC to indicate the instructio
Peter Maydell wrote:
> On 23 November 2012 15:17, Peter Maydell wrote:
> > On 23 November 2012 15:15, Paolo Bonzini wrote:
> >> You should at least test __i686__ too:
> >>
> >> $ gcc -m32 -dM -E -x c /dev/null |grep __i
> >> #define __i686 1
> >> #define __i686__ 1
> >> #define __i386 1
> >> #def
Peter Maydell wrote:
> On 23 November 2012 15:15, Paolo Bonzini wrote:
> > Il 23/11/2012 16:12, Peter Maydell ha scritto:
> >> Adjust the conditional which guards the implementation of
> >>
> >> -#elif defined(__i386__)
> >> +#elif defined(__i586__)
> >>
> >> static inline int64_t cpu_get_real_ti
Kevin Wolf wrote:
> Am 24.10.2012 16:32, schrieb Jamie Lokier:
> > Kevin Wolf wrote:
> >> Am 24.10.2012 14:16, schrieb Nicholas Thomas:
> >>> On Tue, 2012-10-23 at 16:02 +0100, Jamie Lokier wrote:
> >>>> Since the I/O _order_ before, and sometim
Kevin Wolf wrote:
> Am 24.10.2012 14:16, schrieb Nicholas Thomas:
> > On Tue, 2012-10-23 at 16:02 +0100, Jamie Lokier wrote:
> >> Since the I/O _order_ before, and sometimes after, flush, is important
> >> for data integrity, this needs to be maintained when
Nicholas Thomas wrote:
> On Tue, 2012-10-23 at 12:33 +0200, Kevin Wolf wrote:
> > Am 22.10.2012 13:09, schrieb n...@bytemark.co.uk:
> > >
> > > This is unlikely to come up now, but is a necessary prerequisite for
> > > reconnection
> > > behaviour.
> > >
> > > Signed-off-by: Nick Thomas
> > > -
Rusty Russell wrote:
> I don't think it'll be that bad; reset clears the device to unknown,
> bar0 moves it from unknown->legacy mode, bar1/2/3 changes it from
> unknown->modern mode, and anything else is bad (I prefer being strict so
> we catch bad implementations from the beginning).
Will that w
Peter Maydell wrote:
> On 19 September 2012 14:32, Jamie Lokier wrote:
> > However, someone may run QEMU on a kernel before 2.6.32, which isn't
> > that old. (E.g. my phone is running 2.6.28).
>
> NB that ARM kernels that old have other amusing bugs, such
> as
liu ping fan wrote:
> >> +static inline void atomic_set(Atomic *v, int i)
> >> +{
> >> +v->counter = i;
> >> +}
Hi,
When running on ARM Linux kernels prior to 2.6.32, userspace
atomic_set() needs to use "clrex" or "strex" too.
See Linux commit 200b812d, "Clear the exclusive monitor when retu
Avi Kivity wrote:
> On 09/13/2012 09:54 AM, liu ping fan wrote:
>
> >>> +typedef struct Atomic {
> >>> +int counter;
> >>> +} Atomic;
> >>
> >> Best to mark counter 'volatile'.
> >>
> >>> +
> >>> +static inline void atomic_set(Atomic *v, int i)
> >>> +{
> >>> +v->counter = i;
> >>> +}
> >>
陳韋任 wrote:
> > As x86 doesn't use or need barrier instructions, when translating x86
> > to (say) run on ARM host, multi-threaded code that needs barriers
> > isn't easy to detect, so barriers may be required between every memory
> > access in the generated ARM code.
>
> Sounds awful to me. Rega
Anthony Liguori wrote:
> >The new API will do away with the IOAPIC/PIC/PIT emulation and defer
> >them to userspace.
>
> I'm a big fan of this.
I agree with getting rid of unnecessary emulations.
(Why were those things emulated in the first place?)
But it would be good to retain some way to "plu
Michael Roth wrote:
> In some cases initializing the alarm timers can lead to non-negligable
> overhead from programs that link against qemu-tool.o. At least,
> setting a max-resolution WinMM alarm timer via mm_start_timer() (the
> current default for Windows) can increase the "tick rate" on Window
陳韋任 wrote:
> What's load/store exclusive implementation?
It's how some architectures do atomic operations, instead of having
atomic instructions like x86 does.
> And as a general emulator, QEMU shouldn't implement any
> architecture-specific memory model, right? What comes into my mind
> is QEM
Peter Maydell wrote:
> > "guest binaries don't actually rely that much on the memory model."
> >
> > I think the reason is those guest binaries are single thread. Memory model
> > is
> > important in multi-threaded case. BTW, our binary translator now can
> > translate
> > x86 binary to ARM bina
Jan Kiszka wrote:
> Usability. Users should not have to care about individual tick-based
> clocks. They care about "my OS requires lost ticks compensation, yes or no".
Conceivably an OS may require lost ticks compensation depending on
boot options given to the OS telling it which clock sources to
Michael Roth wrote:
> >STDIO is one of the major areas of code that is definitely not
> >async signal safe. Consider Thread A doing something like
> >fwrite(stderr, "Foo\n"), while another thread forks, and then
> >its child also does an fwrite(stderr, "Foo\n"). Given that
> >every stdio function w
Eric Blake wrote:
> On 01/16/2012 03:51 AM, Jamie Lokier wrote:
> > I'm not sure if it's relevant to the this code, but on Glibc fork() is
> > not async-signal-safe and has been known to crash in signal handlers.
> > This is why fork() was removed from SUS async-s
Eric Blake wrote:
> On 01/13/2012 12:15 PM, Luiz Capitulino wrote:
> > This might look complex, but the final code is quite simple. The
> > purpose of that approach is to allow qemu-ga to reap its children
> > (semi-)automatically from its SIGCHLD handler.
>
> Yes, given your desire for the top-le
>>> On 11/16/2011 03:36 PM, Anthony Liguori wrote:
We have another requirement. We need to embed the source for the guest
agent in the QEMU release tarball. This is for GPL compliance since we
want to include an ISO (eventually) that contains binaries.
Paolo Bonzini wrote:
> ovirt-g
Richard Henderson wrote:
> On 05/26/2011 01:25 PM, Blue Swirl wrote:
> >> I don't see the point. The C99 implementation defined escape hatch
> >> exists for weird cpus. Which we won't be supporting as a QEMU host.
> >
> > Maybe not, but a compiler with this property could arrive. For
> > example
Venkateswararao Jujjuri wrote:
> This model makes the code simple and also in one shot we can convert
> all v9fs_do_syscalls into asynchronous threads. But as Aneesh raised
> will there be any additional overhead for the additional jumps? We
> can quickly test it out too.
I'm not sure if this is
Stefan Hajnoczi wrote:
> My current plan is to try using sigaltstack(2) instead of
> makecontext()/swapcontext() as a hack since OpenBSD doesn't have
> makecontext()/swapcontext().
sigaltstack() is just a system call to tell the system about an
alternative signal stack - that you have allocated yo
Stefan Hajnoczi wrote:
> On Thu, May 12, 2011 at 10:51 AM, Jan Kiszka wrote:
> > On 2011-05-11 12:15, Stefan Hajnoczi wrote:
> >> From: Kevin Wolf
> >>
> >> Asynchronous code is becoming very complex. At the same time
> >> synchronous code is growing because it is convenient to write.
> >> Somet
Daniel P. Berrange wrote:
> On Wed, May 11, 2011 at 03:45:39PM +0200, Paolo Bonzini wrote:
> > On 05/11/2011 03:05 PM, Anthony Liguori wrote:
> > >>
> > >>A very slow way, too (on Windows at least if you use qemu_cond...).
> > >
> > >That doesn't mean you can't do a fiber implementation for Windows
Stefan Hajnoczi wrote:
> On Mon, May 23, 2011 at 11:49 PM, Jamie Lokier wrote:
> > Being able to override the backing file path would be useful anyway.
> >
> > I've already had problems when moving established qcow2 files between
> > systems, that for historical re
Anthony Liguori wrote:
> On 05/23/2011 06:02 PM, Jamie Lokier wrote:
> >Richard W.M. Jones wrote:
> >>The problem is to be able to send 64 bit memory and disk offsets
> >>faithfully. This doesn't just fail to solve the problem, it's
> >>actually g
Richard W.M. Jones wrote:
> The problem is to be able to send 64 bit memory and disk offsets
> faithfully. This doesn't just fail to solve the problem, it's
> actually going to make it a whole lot worse.
Such offsets would be so much more readable in hexadecimal.
So why not use a string "0x8
Markus Armbruster wrote:
> Anthony Liguori writes:
>
> > On 05/23/2011 05:30 AM, Daniel P. Berrange wrote:
> >> It feels to me that turning the current block driver code which just does
> >> open(2) on files, into something which issues events& asynchronously
> >> waits for a file would potentia
Gleb Natapov wrote:
> On Sun, May 22, 2011 at 10:50:22AM +0300, Avi Kivity wrote:
> > On 05/20/2011 02:25 PM, Gleb Natapov wrote:
> > >>
> > >> A) Removing regions will change significantly. So far this is done by
> > >> setting a region to IO_MEM_UNASSIGNED, keeping truncation. With the new
> >
Blue Swirl wrote:
> On Fri, Apr 8, 2011 at 9:04 AM, Gleb Natapov wrote:
> > On Thu, Apr 07, 2011 at 04:41:03PM -0500, Anthony Liguori wrote:
> >> On 04/07/2011 02:17 PM, Gleb Natapov wrote:
> >> >On Thu, Apr 07, 2011 at 10:04:00PM +0300, Blue Swirl wrote:
> >> >>On Thu, Apr 7, 2011 at 9:51 PM, Gle
Gleb Natapov wrote:
> On Thu, Apr 07, 2011 at 04:39:58PM -0500, Anthony Liguori wrote:
> > On 04/07/2011 01:51 PM, Gleb Natapov wrote:
> > >NMI does not have to generate crash dump on every guest we support.
> > >Actually even for windows guest it does not generate one without
> > >tweaking registr
Chunqiang Tang wrote:
> > >> Moreover, using a host file system not only adds overhead, but
> > >> also introduces data integrity issues. Specifically, if I/Os uses
> O_DSYNC,
> > >> it may be too slow. If I/Os use O_DIRECT, it cannot guarantee data
> > >> integrity in the event of a host crash. S
Chunqiang Tang wrote:
> > Based on my limited understanding, I think FVD shares a
> > lot in common with the COW format (block/cow.c).
> >
> > But I think most of the advantages you mention could be considered as
> > additions to either qcow2 or qed. At any rate, the right way to have
> > that
Chunqiang Tang wrote:
> Doing both fault injection and verification together introduces some
> subtlety. For example, even under the random failure mode, two disk writes
> triggered by one VM-issued write must either fail together or succeed
> together. Otherwise, the truth image and the test im
Stefan Hajnoczi wrote:
> Since there is no ordering imposed between the data write and metadata
> update, the following scenarios may occur on crash:
> 1. Neither data write nor metadata update reach the disk. This is
> fine, qed metadata has not been corrupted.
> 2. Data reaches disk but metadata
Richard W.M. Jones wrote:
> We could demand that OSes write device drivers for more qemu devices
> -- already OS vendors write thousands of device drivers for all sorts
> of obscure devices, so this isn't really much of a demand for them.
> In fact, they're already doing it.
Result: Most OSes not
Anthony Liguori wrote:
> On 07/21/2010 04:58 PM, Daniel P. Berrange wrote:
> >>Yes there is. Use the version number.
> >>
> >The version number is not suitable, because features can be removed at
> >compile time and/or
>
> I don't see any features that libvirt would need to know about that a
Gleb Natapov wrote:
> On Mon, Jul 19, 2010 at 09:40:18AM +0200, Alexander Graf wrote:
> >
> > On 19.07.2010, at 09:33, Gleb Natapov wrote:
> >
> > > On Mon, Jul 19, 2010 at 08:28:02AM +0100, Richard W.M. Jones wrote:
> > >> On Mon, Jul 19, 2010 at 09:23:56AM +0300, Gleb Natapov wrote:
> > >>> Tha
Serge Hallyn wrote:
> The default of qemu-img (of using O_SYNC) is not very sensible
> because anyway, the client (the kernel) uses caches (write-back),
> (and "qemu-nbd -d" doesn't flush those by the way). So if for
> instance qemu-nbd is killed, regardless of whether qemu-nbd uses
> O_SYNC, O_DIR
Markus Armbruster wrote:
> A possible reason why we currently expose format and protocol at the
> user interface is to avoid stacking there.
Pragmatic solution?: A few generic flags in each stacking module
("format/protocol/transport"), which govern which other modules are
allowed to stack on top
Kevin Wolf wrote:
> > The "protocol" parlance breaks down when we move away from the simple
> > stuff. For instance, qcow2 needs two children: the block driver
> > providing the delta bits (in qcow2 format), and the block driver
> > providing the base bits (whose configuration happens to be stored
Christoph Hellwig wrote:
> On Mon, Jun 21, 2010 at 09:51:23AM -0500, Anthony Liguori wrote:
> > I can appreciate the desire to keep protocols and formats as an internal
> > distinction but as a user visible concept, I think your two examples
> > highlight why exposing protocols as formats make se
Natalia Portillo wrote:
>You got the point wrong, I'm talking running WITH 64 bit hardware in a
>32 bit guest.
>This is done in Mac OS X Leopard (kernel is only 32 bit) and Mac OS X
>Snow Leopard (using 32 bit kernel not 64 bit one) by VMWare, Parallels
>and VirtualBox, as well
Paolo Bonzini wrote:
> On 06/19/2010 03:01 PM, Natalia Portillo wrote:
> >VMWare is able to do it, we should be able.
>
> They do it like TCG does it, not like KVM.
I heard rumours VMWare use KVM-style chip virtualisation when running
a 64-bit guest on a 32-bit host kernel on 64-bit hardware.
If
Isaku Yamahata wrote:
> On Fri, Jun 18, 2010 at 03:44:04PM +0300, Michael S. Tsirkin wrote:
> > If we really want the ability to put unrelated devices
> > as functions in a single one, let's just add
> > a 'multifunction' qdev property, and validate that
> > it is set appropriately.
>
> I think "u
Gibbons, Scott wrote:
> My architecture is an Interleaved Multithreading VLIW architecture. One
> bundle (packet) executes per processor cycle, rotating between threads (i.e.,
> thread 0 executes at time 0, thread 1 executes at time 1, then thread 0
> executes at time 2, etc.). Each thread has
Kevin Wolf wrote:
> Am 16.06.2010 18:52, schrieb MORITA Kazutaka:
> > At Wed, 16 Jun 2010 13:04:47 +0200,
> > Kevin Wolf wrote:
> >>
> >> Am 15.06.2010 19:53, schrieb MORITA Kazutaka:
> >>> posix-aio-compat sends a signal in aio operations, so we should
> >>> consider that fgets() could be interrup
Anthony Liguori wrote:
> On 06/16/2010 11:17 AM, Juan Quintela wrote:
> >Consider the example that I showed you:
> >
> >(host A) (host B)
> >launch qemu launch qemu -incoming
> >migrate host B
> > .
> > do your things
> >
Jamie Lokier wrote:
> Anthony Liguori wrote:
> > On 06/16/2010 09:29 AM, Paolo Bonzini wrote:
> > >On 06/16/2010 04:22 PM, Jamie Lokier wrote:
> > >>Paolo Bonzini wrote:
> > >>>These should be (at least for now) block-obj-$(CONFIG_POSIX).
> &g
Anthony Liguori wrote:
> On 06/16/2010 09:29 AM, Paolo Bonzini wrote:
> >On 06/16/2010 04:22 PM, Jamie Lokier wrote:
> >>Paolo Bonzini wrote:
> >>>These should be (at least for now) block-obj-$(CONFIG_POSIX).
> >>>
> >>&
Paolo Bonzini wrote:
> These should be (at least for now) block-obj-$(CONFIG_POSIX).
>
> >+while (QTAILQ_EMPTY(&(queue->request_list))&&
> >+ (ret != ETIMEDOUT)) {
> >+ret = qemu_cond_timedwait(&(queue->cond),
> >+&(queue->lock)
Gleb Natapov wrote:
> On Mon, Jun 14, 2010 at 09:54:25AM -0400, Kevin O'Connor wrote:
> > Could we just have qemu build the hpet tables and pass them through to
> > seabios? Perhaps using the qemu_cfg_acpi_additional_tables() method.
> >
> Possible, and I considered that. I personally prefer to p
Alexander Graf wrote:
> Anthony Liguori wrote:
> > I'd prefer to stick to bug fixes for stable releases. Performance
> > improvements are a good motivation for people to upgrade to 0.13 :-)
>
> In general I agree, but this one looks like a really simple one.
Besides, there are too many reported
Roedel, Joerg wrote:
> On Fri, May 28, 2010 at 02:10:59AM -0400, Jan Kiszka wrote:
> > Erik van der Kouwe wrote:
>
> > > In my experience, if I provide the -enable-kvm switch then the guest VMM
> > > never detects the presence of virtualization support. Does this only
> > > work on AMD hardware? O
Julian Pidancet wrote:
> So after all, why not implementing our own VT switching and using
> directly the fbdev interface.
It's a good idea. VT switching isn't hard to track reliably.
Being able to tell qemu, through the monitor, to attach/detach from a
particular VT might be a nice easy bonus t
Michael Tokarev wrote:
> Anthony Liguori wrote:
> []
> > For the Bug Day, anything is interesting IMHO. My main interest is to
> > get as many people involved in testing and bug fixing as possible. If
> > folks are interested in testing specific things like unusual or older
> > OSes, I'm happy to
Natalia Portillo wrote:
> Hi,
>
> > - We'll try to migrate as many confirmable bugs from the Source Forge
> > tracker to Launchpad.
> I think that part of the bug day should also include retesting OSes that
> appear in OS Support List as having bug and confirming if the bug is still
> present a
Jan Kiszka wrote:
> Jamie Lokier wrote:
> > Anthony Liguori wrote:
> >> Instead of encoding just as a string, it would be a good idea to encode
> >> it as something like:
> >>
> >> {'__class__': 'base64', 'data': ...}
Alexander Graf wrote:
>
> On 17.05.2010, at 18:26, Anthony Liguori wrote:
>
> > On 05/17/2010 11:23 AM, Paul Brook wrote:
> I don't see a difference between the results. Apparently the barrier
> option doesn't change a thing.
>
> >>> Ok. I don't like it, but I can see how i
Blue Swirl wrote:
> On 5/16/10, Jamie Lokier wrote:
> > Blue Swirl wrote:
> > > On 5/16/10, Paolo Bonzini wrote:
> > > > On 05/15/2010 11:49 AM, Blue Swirl wrote:
> > > >
> > > > > In 2/2, A20 logic changes a bit but I doubt any guest
Blue Swirl wrote:
> On 5/16/10, Paolo Bonzini wrote:
> > On 05/15/2010 11:49 AM, Blue Swirl wrote:
> >
> > > In 2/2, A20 logic changes a bit but I doubt any guest would be broken
> > > if A20 line written through I/O port 92 couldn't be read via i8042.
> > > The reverse (write using i8042 and read
Anthony Liguori wrote:
> Instead of encoding just as a string, it would be a good idea to encode
> it as something like:
>
> {'__class__': 'base64', 'data': ...}
Is there a benefit to the class indirection, over simply a keyword?:
{'__base64__': ...}
__class__ seems to suggest much more than i
Jan Kiszka wrote:
> While IO_MEM_ROMD marks an I/O memory region as "read/execute from RAM,
> but write to I/O handler", there is no flag indicating that an I/O
> region which is fully managed by I/O handlers can still be hosting
> executable code. One use case for this are flash device models that
Stefano Stabellini wrote:
> > I think we need to consider only dstpitch for a full invalidate. We
> > might be copying an offscreen bitmap into the screen, and srcpitch is
> > likely to be the bitmap width instead of the screen pitch.
>
> Agreed.
Even when copying on-screen (or partially on-sc
Stefano Stabellini wrote:
> On Wed, 12 May 2010, Avi Kivity wrote:
> > It's useful if you have a one-line horizontal pattern you want to
> > propagate all over.
>
> It might be useful all right, but it is not entirely clear what the
> hardware should do in this situation from the documentation w
Stefan Hajnoczi wrote:
> On Wed, May 12, 2010 at 10:42 AM, Jamie Lokier wrote:
> > Stefan Hajnoczi wrote:
> >> Why add a nop AIO operation instead of setting
> >> BlockDriverState->enable_write_cache to zero? In that case no write
> >> cache would be
Gerhard Wiesinger wrote:
> Can one switch to the old software vmm in VMWare?
Perhaps you can install a very old version of VMWare.
Maybe run it under KVM ;-)
> That was one of the reasons why I was looking for alternatives for
> graphical DOS programs. Overall summary so far:
> 1.) QEMU without
Gerhard Wiesinger wrote:
> On Wed, 21 Apr 2010, Jamie Lokier wrote:
>
> >Gerhard Wiesinger wrote:
> >>Hmmm. I'm very new to QEMU and KVM but at least accessing the virtual HW
> >>of QEMU even from KVM must be possible (e.g. memory and port accesses are
> >
Paul Brook wrote:
> > > Paul Brook wrote:
> > > > cache=none:
> > > > No host caching. Reads and writes both go directly to underlying
> > > > storage.
> > > >
> > > > Useful to avoid double-caching.
> > > >
> > > > cache=writethrough
> > > >
> > > > Reads are cached. Writes go directly to
Stefan Hajnoczi wrote:
> Why add a nop AIO operation instead of setting
> BlockDriverState->enable_write_cache to zero? In that case no write
> cache would be reported to the guest (just like cache=writethrough).
Hmm. If the guest sees write cache absent, that prevents changing the
cache policy
Anthony Liguori wrote:
> QMP should insult users from underlying platform quirks. We should
> translate errnos to appropriate QMP error types.
Fair enough. What should it do when the platform returns an errno
value that qemu doesn't know about, and wants to pass to the QMP caller?
-- Jamie
Anthony Liguori wrote:
> Hi Bruce,
>
> On 05/10/2010 02:07 PM, Bruce Rogers wrote:
> >I know this behavior has worked this way all along, but I wanted to bring
> >up the following concern and float a few ideas about possible solutions.
> >Please provide your perspective, opinion, etc.
> >
> >qem
Anthony Liguori wrote:
> There's got to be a better place to fix this. Disable barriers in your
> guests?
If only it were that easy.
OS installs are the thing that this feature would most help. They
take ages, do a huge amount of writing with lots of seeking, and if
the host fails you're going
Paul Brook wrote:
> cache=none:
> No host caching. Reads and writes both go directly to underlying storage.
> Useful to avoid double-caching.
>
> cache=writethrough
> Reads are cached. Writes go directly to underlying storage. Useful for
> broken guests that aren't aware of drive caches.
T
Anthony Liguori wrote:
> qemu-img create -f raw foo.img 10G
> mkfs.ext3 foo.img
> mount -oloop,rw,barrier=1 -t ext3 foo.img mnt
>
> Works perfectly fine.
Hmm, interesting. Didn't know loop propagated barriers.
So you're suggesting to use qemu with a loop device, and ext2 (bit
faster than ext3)
Anthony Liguori wrote:
> On 05/11/2010 08:12 AM, Paul Brook wrote:
> >>>cache=always (or a more scary name like cache=lie to defend against
> >>>idiots)
> >>>
> >>>Reads and writes are cached. Guest flushes are ignored. Useful for
> >>>dumb guests in non-critical environments.
> >>>
Jan Kiszka wrote:
> Moreover, some of the QObject files are LGPL, some GPL. I bet this was
> also not intended. But what was the idea behind the LGPL? Some libqmp which
> can be used by closed source apps?
I believe LGPL is needed for source apps that have GPLv2-incompatible
licensing. E.g. GPLv3
Michael S. Tsirkin wrote:
> Hi!
> I see this in virtio_ring.c:
>
> /* Put entry in available array (but don't update avail->idx *
> until they do sync). */
>
> Why is it done this way?
> It seems that updating the index straight away would be simpler, while
> this might allow the
Rusty Russell wrote:
> On Wed, 5 May 2010 05:47:05 am Jamie Lokier wrote:
> > Jens Axboe wrote:
> > > On Tue, May 04 2010, Rusty Russell wrote:
> > > > ISTR someone mentioning a desire for such an API years ago, so CC'ing
> > > > the
> > >
Rusty Russell wrote:
> > Seems over-zealous.
> > If the recovery_header held a strong checksum of the recovery_data you would
> > not need the first fsync, and as long as you have two places to write
> > recovery
> > data, you don't need the 3rd and 4th syncs.
> > Just:
> >
> > write_internally
Rusty Russell wrote:
> On Fri, 19 Feb 2010 08:52:20 am Michael S. Tsirkin wrote:
> > I took a stub at documenting CMD and FLUSH request types in virtio
> > block. Christoph, could you look over this please?
> >
> > I note that the interface seems full of warts to me,
> > this might be a first ste
Jens Axboe wrote:
> On Tue, May 04 2010, Rusty Russell wrote:
> > ISTR someone mentioning a desire for such an API years ago, so CC'ing the
> > usual I/O suspects...
>
> It would be nice to have a more fuller API for this, but the reality is
> that only the flush approach is really workable. Even
Daniel P. Berrange wrote:
> > Much better to exact a commitment from libvirt to track all QMP (and
> > command line) capabilities. Instead of adding cleverness to QMP, add
> > APIs to libvirt.
>
> Agreed. Despite adding this monitor / XML passthrough capability, we still
> do not want apps to b
Michael Tokarev wrote:
> 24.04.2010 17:05, Andreas Färber wrote:
> >Am 22.04.2010 um 11:40 schrieb Michael Tokarev:
> >
> >>11.03.2010 18:34, Michael Tokarev wrote:
> >>[]
> On version 0.12.3, -drive serial=XXX option does not work.
> Below patch fixes it. 'serial' is pointer, not array.
>
Alexander Graf wrote:
> They should be atomic. TCG SMP swaps between different vCPUs only
> after translation blocks are done. In fact, the only way I'm aware
> of to stop the execution of a TB mid-way is a page fault.
A page fault would interrupt it if the atomic is implemented as
a read followed
Ian Molton wrote:
> Jamie Lokier wrote:
> > First of all: Why are your egd daemons with open connections dying
> > anyway? Buggy egd?
>
> No, they aren't buggy. but occasionally, the sysadmin of said server
> farms may want to, you know, update the daemon?
M
Ian Molton wrote:
> >You can configure any chardev to be a tcp client. I never do that though
> >as I find it much more convenient to configure it as server.
>
> Perhaps thats because chardev clients are nearly useless right now
> because they just die if the connection drops...
Which is why dro
Yoshiaki Tamura wrote:
> Jamie Lokier wrote:
> >Yoshiaki Tamura wrote:
> >>Dor Laor wrote:
> >>>On 04/21/2010 08:57 AM, Yoshiaki Tamura wrote:
> >>>>Event tapping is the core component of Kemari, and it decides on which
> >>>>event the
&g
Ian Molton wrote:
> > It might make sense to have the reconnect logic in the egd chardev
> > backend then, thereby obsoleting the socket reconnect patch.
>
> Im not sure I agree there... surely there are other things which would
> benefit from generic socket reconnection support (virtio-rng cant b
Yoshiaki Tamura wrote:
> Dor Laor wrote:
> >On 04/21/2010 08:57 AM, Yoshiaki Tamura wrote:
> >>Event tapping is the core component of Kemari, and it decides on which
> >>event the
> >>primary should synchronize with the secondary. The basic assumption
> >>here is
> >>that outgoing I/O operations ar
Gerhard Wiesinger wrote:
> Hmmm. I'm very new to QEMU and KVM but at least accessing the virtual HW
> of QEMU even from KVM must be possible (e.g. memory and port accesses are
> done on nearly every virtual device) and therefore I'm ending in C code in
> the QEMU hw/*.c directory. Therefore also
Avi Kivity wrote:
> On 04/21/2010 09:39 PM, Jamie Lokier wrote:
> >Avi Kivity wrote:
> >
> >>Writes to vga in 16-color mode don't change set a memory location to a
> >>value, instead they change multiple memory locations.
> >>
> >Whil
Gerhard Wiesinger wrote:
> >>Would it be possible to handle these writes through QEMU directly
> >>(without
> >>KVM), because performance is there very well (looking at the code there
> >>is some pointer arithmetic and some memory write done)?
> >
> >I've noticed extremely slow VGA performance too
Avi Kivity wrote:
> Writes to vga in 16-color mode don't change set a memory location to a
> value, instead they change multiple memory locations.
While code is just writing to the VGA memory, not reading(*) and not
touching the VGA I/O register that control the write latches, is it
possible in p
Gerhard Wiesinger wrote:
> I'm using VESA mode 0x101 (640x480 256 colors), but performance is
> there very low (~1MB/s). Test is also WITHOUT any vga window change, so
> there isn't any page switching overhead involved in this test case.
>
> >>Any ideas for improvement?
> >
> >Currently when the
1 - 100 of 417 matches
Mail list logo
