Avi Kivity wrote:
Either way - then we should make the goal of the project to support those
old boot loaders. IMHO it should contain visibility. Doing theoretical
stuff is just less fun for all parties. Or does that stuff work already?
Mostly those old guests aged beyond usefulness. They
Cam Macdonell wrote:
An irqfd can only trigger a single vector in a guest. Right now I
only have one eventfd per guest.So ioeventfd/irqfd restricts the
current implementation to a single vector that a guest can trigger.
Without irqfd, eventfds can be used like registers a write the number
Avi Kivity wrote:
ioctls encode the buffer size into the ioctl number, so in theory strace
doesn't need to be taught about an ioctl to show its buffer.
Unfortunately ioctl numbers don't always follow that rule :-(
But maybe that's just awful proprietary drivers that I've seen.
Anyway, strace
Mohammed Gamal wrote:
2- With respect to CIFS. I wonder how the shares are supposed to be
exposed to the guest. Should the Samba server be modified to be able
to use unix domain sockets instead of TCP ports and then QEMU
communicating on these sockets. With that approach, how should the
guest
Mohammed Gamal wrote:
Hi Javier,
Thanks for the link. However, I'm still concerned with
interoperability with other operating systems, including non-Windows
ones. I am not sure of how many operating systems actually support 9p,
but I'm almost certain that CIFS would be more widely-supported.
Javier Guerra Giraldez wrote:
On Sat, Apr 10, 2010 at 7:42 AM, Mohammed Gamal m.gamal...@gmail.com wrote:
On Sat, Apr 10, 2010 at 2:12 PM, Jamie Lokier ja...@shareable.org wrote:
To throw a spanner in, the most widely supported filesystem across
operating systems is probably NFS, version 2
Mohammed Gamal wrote:
On Mon, Apr 12, 2010 at 12:29 AM, Jamie Lokier ja...@shareable.org wrote:
Javier Guerra Giraldez wrote:
On Sat, Apr 10, 2010 at 7:42 AM, Mohammed Gamal m.gamal...@gmail.com
wrote:
On Sat, Apr 10, 2010 at 2:12 PM, Jamie Lokier ja...@shareable.org
wrote
Alexander Graf wrote:
Also since -net user does support samba exporting already,
This I'm interested in. Last time I tried to use it, the smb=
option didn't work because Samba refused to run when launched with
qemu's mini config file and launched as a regular user. It needed
access to various
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 step to cleaning them.
One issue I struggled with especially is how
Avi Kivity wrote:
On 04/19/2010 10:14 PM, Gerhard Wiesinger wrote:
Hello,
Finally I got QEMU-KVM to work but video performance under DOS is very
low (QEMU 0.12.3 stable and QEMU GIT master branch is fast, QEMU KVM
is slow)
I'm measuring 2 performance critical video performance
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
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, when
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.
While code is just writing to the VGA memory, not reading
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 the
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 are idempotent,
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
primary should synchronize with the secondary. The basic assumption
here
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 just
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 step to
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:
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
usual I/O suspects...
It would be nice to have a more fuller API
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 host to
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
done on nearly every virtual device) and therefore
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
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 we have,
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-screen),
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 and if
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 see it!
Avi Kivity wrote:
On 10/08/2009 03:49 PM, Anthony Liguori wrote:
Glauber Costa wrote:
This patch provides kvm with an in-kernel ioapic. We are currently
not enabling it.
The code is heavily based on what's in qemu-kvm.git.
It really ought to be it's own file and own device model. Having
Avi Kivity wrote:
On 10/08/2009 06:06 PM, Michael S. Tsirkin wrote:
On Thu, Oct 08, 2009 at 05:29:29PM +0200, Avi Kivity wrote:
On 10/08/2009 04:52 PM, Michael S. Tsirkin wrote:
PCI memory should be disabled at reset, otherwise
we might claim transactions at address 0.
I/O should
Gleb Natapov wrote:
On Thu, Oct 08, 2009 at 06:42:07PM +0200, Avi Kivity wrote:
On 10/08/2009 06:34 PM, Gleb Natapov wrote:
So suppose I have simple watchdog device that required to be poked every
second, otherwise it resets a computer. On migration we have to migrate
time elapsed since
Glauber Costa wrote:
It ensures the two models are compatible. Since they're the same device
from the point of view of the guest, there's no reason for them to have
different representations or to be incompatible.
live migration between something that has in-kernel irqchip and
Michael S. Tsirkin wrote:
More long-term, we have duplication between reset and init
routines. Maybe devices really should have init and cleanup,
and on reset we'd cleanup all devices and then init them again?
It sounds look a good idea to me. That is, after all, what hardware
reset often
Glauber Costa wrote:
On Fri, Oct 09, 2009 at 11:06:41AM +0100, Jamie Lokier wrote:
Glauber Costa wrote:
It ensures the two models are compatible. Since they're the same
device
from the point of view of the guest, there's no reason for them to have
different
Glauber Costa wrote:
On Thu, Oct 08, 2009 at 06:22:48PM +0200, Gleb Natapov wrote:
On Thu, Oct 08, 2009 at 06:17:57PM +0200, Avi Kivity wrote:
On 10/08/2009 06:07 PM, Jamie Lokier wrote:
Haven't we already confirmed that it *isn't* just an ioapic accelerator
because you can't migrate
Anthony Liguori wrote:
We already have the single device model implementation and the
limitations are well known. The best way to move forward is for someone
to send out patches implementing separate device models.
At that point, it becomes a discussion of two concrete pieces of code
Gleb Natapov wrote:
But KVM doesn't support it (memory is always writable).
That seems like something which could be fixed.
-- Jamie
--
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
Michael S. Tsirkin wrote:
On Wed, Oct 14, 2009 at 09:17:15AM -0500, Anthony Liguori wrote:
Michael S. Tsirkin wrote:
Looks like Or has abandoned it. I have an updated version which works
with new APIs, etc. Let me post it and we'll go from there.
I'm generally inclined to oppose
Michael Tokarev wrote:
If you want kvm to behave like this, wrap it into a trivial
shell script that restarts the guest.
True, kvm has enough crash-bugs elsewhere that I already have to deal
with that. It'd be nice to distinguish kvm/qemu bugs from guest
bugs, though :-)
kvm/qemu also has
Avi Kivity wrote:
On 11/03/2009 12:09 AM, Alexander Graf wrote:
When we want to create a full VirtIO based machine, we're still missing
graphics output. Fortunately, Linux provides us with most of the frameworks
to render text and everything, we only need to implement a transport.
So this
Javier Guerra wrote:
there has to be some policy in place to redirect USB devices to each
QEMU instance, maybe at startup it could reserve a node in the USB
device tree (an USB controller, or maybe a port in a hub). when
invoked by udev, some script would consult those reservations and pick
Avi Kivity wrote:
(logically we would copy all of the data of all block devices, but
that's not very practical, so we assume shared storage).
Speaking of that, if the guest RAM were a memory-mapped file, couldn't
that use shared storage too?
You'd have to be careful: it would need a
Ryan Harper wrote:
Addtional work has been done on top of QEMU for KVM and virtio-blk
devices. While virtio-blk is not yet upstream in QEMU, the AIO
changes here provide a tremendous performance improvement (from 7.6%
of native, to 100% of randwrite, and 3.9% of native, to 101.4% of
native
Dor Laor wrote:
Actually this is what happens on mainline qemu with cache=off.
Have I understood right that cache=off on a qcow2 image only uses
O_DIRECT for the leaf image, and the chain of base images don't use
O_DIRECT?
Sometimes on a memory constrained host, where the (collective) guest
Chris Wright wrote:
Either wt or uncached (so host O_DSYNC or O_DIRECT) would suffice to get
it through to host's storage subsytem, and I think that's been the core
of the discussion (plus defaults, etc).
Just want to point out that the storage commitment from O_DIRECT can
be _weaker_ than
Beth Kon wrote:
Clock drift on Linux is in the range of .017% - .019%, loaded and unloaded. I
haven't found a straightforward way to test on Windows and would appreciate
any pointers to existing approaches.
Is there any reason why there should be any clock drift, when the
guest is using a
Dor Laor wrote:
Right, I think if this time drift fix approach is accepted, it should also be
implemented for qemu_irq_pulse too.
I don't think simply injecting timer interrupts is the right approach.
I suspect doing that to compensate for lost ticks can _cause_ drift in
some guests.
Some
Anthony Liguori wrote:
Unlike kqemu, KVM does not use TCG at all when accelerating QEMU. Having TCG
present is not a problem when using KVM on x86. x86 already has TCG host and
target support and it's quite convenient to be able to disable/enable KVM and
compare it to TCG when debugging.
I
Avi Kivity wrote:
Jamie Lokier wrote:
But does the fact KVM doesn't use TCG prevent KVM from running some
x86 modes correctly? E.g. I gather 16-bit code is run by KVM using
VM86 mode, which is not exactly correct. It would be nice to have KVM
acceleration but also complete and correct
Avi Kivity wrote:
But does the fact KVM doesn't use TCG prevent KVM from running some
x86 modes correctly? E.g. I gather 16-bit code is run by KVM using
VM86 mode, which is not exactly correct. It would be nice to have KVM
acceleration but also complete and correct emulation, by switching to
Anthony Liguori wrote:
Let me clarify this a bit more. The problem we're trying to address
today is the encapsulating knowledge of phys_ram_base. We want to
minimize the amount of code that makes any assumptions about
phys_ram_base. Your current API still accesses phys_ram_base directly
Jan Kiszka wrote:
You need CR0.PE to detect if you are in real or protected mode. And then
you need GDTR/LDTR to find the descriptor CS is pointing at, parsing it
to detect if you are running 16, 32 or 64 bit code (by default). Those
extensions would also be useful in order to decode memory
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
john cooper wrote:
{
+.name = Merom,
+.level = 2,
+.vendor1 = CPUID_VENDOR_INTEL_1,
+.vendor2 = CPUID_VENDOR_INTEL_2,
+.vendor3 = CPUID_VENDOR_INTEL_3,
+.family = 6, /* P6 */
+.model = 2,
+.stepping = 3,
+
Avi Kivity wrote:
On 01/05/2010 02:56 PM, Rusty Russell wrote:
Those should be the same for any sane interface. They are for classical
disk devices with larger block sizes (MO, s390 dasd) and also for the
now appearing 4k sector scsi disks. But in the ide world people are
concerned about
Avi Kivity wrote:
Physical block size is the what the logical block size would have been
is software didn't suck. In theory they should be the same, but since
compatibility reaons clamp the logical block size to 512, they have to
differ. A disk may have a physical block size of 4096 and
Anthony Liguori wrote:
On 01/18/2010 10:45 AM, john cooper wrote:
x86 Conroe Intel Celeron_4x0 (Conroe/Merom Class Core 2)
x86 Penryn Intel Core 2 Duo P9xxx (Penryn Class Core 2)
x86 Nehalem Intel Core i7 9xx (Nehalem Class Core i7)
x86
Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
I'm very much against having -cpu Nehalem. The whole point of this is
to make things easier for a user and for most of the users I've
encountered, -cpu Nehalem is just as obscure as -cpu
qemu64,-sse3,+vmx,...
john cooper wrote:
As before a cpu feature 'check' option is added which warns when
feature flags (either implicit in a cpu model or explicit on the
command line) would have otherwise been quietly unavailable to a
guest:
# qemu-system-x86_64 ... -cpu Nehalem,check
warning: host
Anthony Liguori wrote:
On 01/19/2010 02:03 PM, Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
I'm very much against having -cpu Nehalem. The whole point of this is
to make things easier for a user and for most of the users I've
encountered, -cpu Nehalem is just as
john cooper wrote:
kvm itself can modify flags exported from qemu to a guest.
I would hope for an option to request that qemu doesn't run if the
guest won't get the cpuid flags requested on the command line.
-- Jamie
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of
john cooper wrote:
I foresee wanting to iterate over the models and pick the latest one
which a host supports - on the grounds that you have done the hard
work of ensuring it is a reasonably good performer, while probably
working on another host of similar capability when a new host is
john cooper wrote:
I can appreciate the argument above, however the goal was
choosing names with some basis in reality. These were
recommended by our contacts within Intel, are used by VmWare
to describe their similar cpu models, and arguably have fallen
to defacto usage as evidenced by such
Dor Laor wrote:
x86 qemu64
x86 phenom
x86 core2duo
x86kvm64
x86 qemu32
x86 coreduo
x86 486
x86 pentium
x86 pentium2
x86 pentium3
x86 athlon
x86 n270
I wonder if kvm32
Anthony Liguori wrote:
No, basically, the problem will boil down to, the IO thread is
select()'d waiting for an event to occur. However, you've done
something in the VCPU thread that requires the IO thread to run it's
main loop. You need to use qemu_notify_event() to force the IO thread
Paul Brook wrote:
Support an inter-vm shared memory device that maps a shared-memory object
as a PCI device in the guest. This patch also supports interrupts between
guest by communicating over a unix domain socket. This patch applies to
the qemu-kvm repository.
No. All new devices
Alexander Graf wrote:
Or we could put in some code that tells the guest the host shm
architecture and only accept x86 on x86 for now. If anyone cares for
other combinations, they're free to implement them.
Seriously, we're looking at an interface designed for kvm here. Let's
please
Paul Brook wrote:
However, coherence could be made host-type-independent by the host
mapping and unampping pages, so that each page is only mapped into one
guest (or guest CPU) at a time. Just like some clustering filesystems
do to maintain coherence.
You're assuming that a TLB flush
Avi Kivity wrote:
On 03/08/2010 03:03 PM, Paul Brook wrote:
On 03/08/2010 12:53 AM, Paul Brook wrote:
Support an inter-vm shared memory device that maps a shared-memory
object as a PCI device in the guest. This patch also supports
interrupts between guest by communicating over a unix
Paul Brook wrote:
On 03/08/2010 12:53 AM, Paul Brook wrote:
Support an inter-vm shared memory device that maps a shared-memory
object as a PCI device in the guest. This patch also supports
interrupts between guest by communicating over a unix domain socket.
This patch applies to
Paul Brook wrote:
In a cross environment that becomes extremely hairy. For example the x86
architecture effectively has an implicit write barrier before every
store, and an implicit read barrier before every load.
Btw, x86 doesn't have any implicit barriers due to ordinary loads.
Avi Kivity wrote:
On 03/10/2010 11:30 PM, Luiz Capitulino wrote:
2. Do we have kvm-specific projects? Can they be part of the QEMU project
or do we need a different mentoring organization for it?
Something really interesting is kvm-assisted tcg. I'm afraid it's a bit
too
Alex Williamson wrote:
What if the guest will chose the host's mac?
Thinking about it, I don't think we should test that.
A concerned host mgmt app can add ebtables roles for such a case.
Maybe we can optionally allow/deny it?
What's the topology you're thinking of that the
Paul Brook wrote:
What I meant is that if we allow the guest to change his mac address, it
can deliberately
change it to other hosts/guests mac and thus create networking problems.
Although guest can always mangle packets, maybe it worth enforcing these
macs for the guest.
This
Dor Laor wrote:
What I meant is that if we allow the guest to change his mac address, it
can deliberately
change it to other hosts/guests mac and thus create networking problems.
Although guest can always mangle packets, maybe it worth enforcing these
macs for the guest.
Although it can
Anthony Liguori wrote:
Thinking more about this, the difficulty is that poll() only has useful
semantics when you're dealing with a buffered stream of some sort. That
is, poll() is only really capable of asking whether there is data
pending in your read buffer.
With 9P, you have to
Hi,
As you see from the subject, I'm getting qcow2 corruption.
I have a Windows 2000 guest which boots and runs fine in kvm-72, fails
with a blue-screen indicating file corruption errors in kvm-73 through
to kvm-83 (the latest), and succeeds if I replace block-qcow2.c with
the version from
Kevin Wolf wrote:
Jamie Lokier schrieb:
Although there are many ways to make Windows blue screen in KVM, in
this case I've narrowed it down to the difference in
qemu/block-qcow2.c between kvm-72 and kvm-73 (not -83).
This must be one of SVN revisions 5003 to 5008 in upstream qemu. Can
Kevin Wolf wrote:
Jamie Lokier schrieb:
Although there are many ways to make Windows blue screen in KVM, in
this case I've narrowed it down to the difference in
qemu/block-qcow2.c between kvm-72 and kvm-73 (not -83).
This must be one of SVN revisions 5003 to 5008 in upstream qemu. Can
Kevin Wolf wrote:
Besides reviewing the code over and over again, I think the only real
chance is that you can get a non-productive copy of your image and add
some debug code so that we can see at least which code path is causing
problems.
I have a copy of my image to reproduce the bug, so I
Alex Williamson wrote:
TUNSETTXFITLER has only existed since 2.6.26, so the ioctl will fail on
anything older and it will be disabled anyway. The patch will fix .29
and should get rolled into .28 stable, so we're looking at an exposure
of 2 kernel releases. Unfortunately a few community
Alex Williamson wrote:
They don't, but they do need to know whether a filter they previously
applied successfully is no longer in place. If they don't know this,
they have to assume the filter on the other side of the vlan is
transient and always double check it with their own filtering,
David S. Ahern wrote:
Has anyone successfully ported a Windows XP image from vmware server to
kvm/qemu?
My attempt is getting a blue screen that disappears very quickly --
something about a corrupted image. I can attach the disk image as a
second drive to another XP instance -- one created
Paul Brook wrote:
We could use a changed() function, but it would need to know the
direction of the change, which leads back to the same mechanics. If
there's a better way, please suggest it. Thanks,
I still don't see why the device needs to know what's changed. The response
should
Marc Bevand schrieb:
I tested kvm-81 and kvm-83 as well (can't test kvm-80 or older
because of the qcow2 performance regression caused by the default
writethrough caching policy) but it randomly triggers an even worse
bug: the moment I shut down a guest by typing quit in the monitor,
it
Paul Brook wrote:
Well, you do need some way to notify a client that the filter which
used to work has been removed because it's no longer available, for
example when migrating between host kernels.
This is actually more evidence that the add and remove callbacks are
bogus.
I agree,
Paul Brook wrote:
A simple Something changed, please try your filter again callback
automatically covers all these cases.
It doesn't, if tap has no memory of how many clients require a filter.
I'm talking about a callback for devices requesting an inbound
filter. Devices implementing
Dor Laor wrote:
Both qcow2 and vmdk have the ability to keep 'external' snapshots.
I didn't see any mention of this in QEMU's documentation. One of the
most annoying features of qcow2 is savevm storing all VM snapshots
in the same qcow2 file. Is this not true?
In addition to what you wrote,
Kevin Wolf wrote:
By the way and completely off-topic: Have you already tried to use the
VHD patches? I would really like to know if they fix your problems.
Are those patches in kvm-83? I still have the image that was causing
problems way back, and I'm converting it to raw now with
Anthony Liguori wrote:
It's racy with select(). A better fix would be to create a pipe and write
to that pipe in the SIGWINCH handler. You should then register an io
Maybe a bottom half would work? The scheduling of a bh shouldn't
constitute real work.
I think it still suffers
Anthony Liguori wrote:
block-qcow2: keep highest allocated byte (Uri Lublin)
We want to know the highest written offset for qcow2 images.
This gives a pretty good (and easy to calculate) estimation to how
much more allocation can be done for the block device.
It can be
Anthony Liguori wrote:
I still think libvirt should work with versions of QEMU/KVM built from
svn/git though. I think the only way to do that is for libvirt to relax
their version checks to accommodate suffixes in the form
major.minor.stable-foo.
Ok, but try to stick to a well-defined
Paul Brook wrote:
I'm extremely sceptical of anything that claims to need a fine
grained version number. In practice version numbers for open source
projects are fairly arbitrary and meaningless because almost
everyone has their own set of patches and backported fixes anyway.
I find it's
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 work,
Andre Przywara wrote:
So what about: -smp 4,cores=2,threads=2[,sockets=1] to inject 4 vCPUs
in one package (automatically determined if omitted) with two cores and
two threads/core? All parameters except the number of vCPUs would be
optional,
Why is the number of vCPUs required at all?
Kevin Wolf wrote:
Can we at least allow \, instead of ,, in parameter parsing, so that the
backslash has the practical benefit of being a single universal escape
character?
Is there a good reason why we cannot simply use \char to escape
_any_ character, in every context where a user-supplied
Ram Pai wrote:
I have verified with relative paths and it works.
After analyzing the code, i came to the conclusion that call to
realpath() adds no real value.
The logic in bdrv_open2() is something like this
bdrv_open2()
{
if (snapshot) {
backup = realpath(filename);
Ram Pai wrote:
I have successfully verified qcow2 files. But then I may not be trying
out the exact thing that you are talking about. Can you give me a test
case that I can verify.
Commands tried with qemu-0.10.0-1ubuntu1:
$ mkdir unlikely_subdir
$ cd unlikely_subdir
$ qemu-img create -f
Jan Kiszka wrote:
Now, I see one significant hurdle with that: it's quite inconvenient
for Windows users, typing paths like c:\path\to\dir\file, if those
backslashes are stipped.
We could exclude Windows from this (I think to remember that filenames
are more restricted there anyway) or
Jan Kiszka wrote:
Jamie Lokier wrote:
Jan Kiszka wrote:
Now, I see one significant hurdle with that: it's quite inconvenient
for Windows users, typing paths like c:\path\to\dir\file, if those
backslashes are stipped.
We could exclude Windows from this (I think to remember that filenames
Anthony Liguori wrote:
Jan Kiszka wrote:
We would still have to deal with the fact that so far '\' had no special
meaning on Windows - except that is was the well-known path separator.
So redefining its meaning would break a bit...
That's the problem. You will break existing Windows
1 - 100 of 131 matches
Mail list logo
