Why not just bypass the whole config file idea and just use enviornment
variables?
Absolutely not. Environment variables are a horrid way of configuring things.
Paul
-
This SF.net email is sponsored by: Microsoft
Defy
I suggested it because my original plan for the configuration file was
based on this syntax with a strong inspiration from the OpenFirmware
device tree. The idea was that the object name (drive here) had no
hardcoded meaning, except for some predefined object names in order to
keep a kind of
On Wednesday 14 May 2008, Anthony Liguori wrote:
Paul Brook wrote:
the class field is used to select the device model. Then all the other
parameters are used to initialize the device model. That way it is
possible to keep the compatibility with the existing options and add a
provision
+/* Return a new IOVector that's a subset of the passed in IOVector. It
should + * be freed with qemu_free when you are done with it. */
+IOVector *iovector_trim(const IOVector *iov, size_t offset, size_t size);
Using qemu_free directly seems a bad idea. I guess we're likely to want to
As a note, the DMA controllers in the ARM system-on-chip's can
byte-swap, do 90deg rotation of 2D arrays, transparency (probably
intened for image blitting, but still available on any kind of
transfers), etc., and most importantly issue interrupts on reaching
different points of a transfer.
On Saturday 29 March 2008, Anthony Liguori wrote:
This patch introduces a PCI DMA API and some generic code to support other
DMA APIs. Two types are introduced: PhysIOVector and IOVector. A DMA API
maps a PhysIOVector, which is composed of target_phys_addr_t, into an
IOVector, which is
On Saturday 29 March 2008, Anthony Liguori wrote:
+ if ((elem = virtqueue_pop(n-rx_vq)) == NULL) {
+ /* wait until the guest adds some rx bufs */
+ n-can_receive = 0;
+ return;
+ }
Setting can_receive to zero *after* dropping a packet is a bit late.
Not a fatal flaw,
On Sunday 30 March 2008, Anthony Liguori wrote:
Paul Brook wrote:
On Saturday 29 March 2008, Anthony Liguori wrote:
This patch introduces a PCI DMA API and some generic code to support
other DMA APIs. Two types are introduced: PhysIOVector and IOVector. A
DMA API maps a PhysIOVector
On Friday 28 March 2008, Marcelo Tosatti wrote:
On Fri, Mar 28, 2008 at 03:07:03PM +, Jamie Lokier wrote:
Marcelo Tosatti wrote:
Its necessary to guarantee that pending AIO writes have reached stable
storage when the flush request returns.
Also change fsync() to fdatasync(),
Surely you should be using the normal aio notification to wait for the
aio_fsync to complete before reporting success to the device.
qemu_aio_flush() will wait for all pending AIO requests (including
aio_fsync) to complete.
Then why do you need to separate fdatasync?
Paul
That'll depend on what kind of device is emulated. Does the SCSI
emulation handle multiple in-flight commands with any guarantee on
order?
SCSI definitely allows (and we emulate) multiple in flight commands.
I can't find any requirement that writes must complete before a subsequent
On Saturday 29 March 2008, Jamie Lokier wrote:
Paul Brook wrote:
That'll depend on what kind of device is emulated. Does the SCSI
emulation handle multiple in-flight commands with any guarantee on
order?
SCSI definitely allows (and we emulate) multiple in flight commands.
I can't
On Monday 24 March 2008, Avi Kivity wrote:
Paul Brook wrote:
On Sunday 23 March 2008, Dor Laor wrote:
--- a/qemu/hw/irq.c
+++ b/qemu/hw/irq.c
@@ -30,6 +30,8 @@ struct IRQState {
int n;
};
+uint32_t qemu_irq_acked[NR_IRQ_WORDS];
This is absolute rubbish. The whole point
On Sunday 23 March 2008, Dor Laor wrote:
On Sun, 2008-03-23 at 16:19 +, Paul Brook wrote:
On Sunday 23 March 2008, Dor Laor wrote:
--- a/qemu/hw/irq.c
+++ b/qemu/hw/irq.c
@@ -30,6 +30,8 @@ struct IRQState {
int n;
};
+uint32_t qemu_irq_acked[NR_IRQ_WORDS
as far as i remember it was used to address something with
cpu_physical_memory_rw() probably related to TARGET_PAGE_SIZE
or ~TARGET_PAGE_SIZE,
the fact is that i dont know if it ever fixed anything
It fixes TARGET_PAGE_MASK, defined one line downscreen.
That doesn't really answer the
On Sunday 10 February 2008, Avi Kivity wrote:
Paul Brook wrote:
as far as i remember it was used to address something with
cpu_physical_memory_rw() probably related to TARGET_PAGE_SIZE
or ~TARGET_PAGE_SIZE,
the fact is that i dont know if it ever fixed anything
It fixes
I agree with the fact that ram_size should be 64 bit. Maybe each
machine could test the value and emit an error message if it is too
big. Maybe an uint64_t would be better though.
uint64_t is probably more reasonable. I wouldn't begin to know what the
appropriate amount of ram was for
virtio could still be made to work with map cache. You would just have
to change it to be able to map more than one page contiguously. As I
mentioned though, it just starts getting ugly.
That's why you should be using the cpu_physical_memory_rw routines :-)
Anything that assume large linear
On Thursday 31 January 2008, Anthony Liguori wrote:
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS can build
the
-cmos_init(ram_size, above_4g_mem_size, boot_device, hd);
+cmos_init(ram_size, above_4g_mem_size, boot_device, hd, smp_cpus);
smp_cpus is a global variable. Why bother passing it around?
Are the CMOS contents documented anywhere?
Paul
+#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024 * 1024ULL)
This seems fairly arbitrary. Why? Any limit is certainly target specific.
On a 32-bit host, a 2GB limit is pretty reasonable since you're limited
in virtual address space. On a 64-bit host, there isn't this
fundamental limit. If
Are the CMOS contents documented anywhere?
No, but if you have a suggestion of where to document them, I'll add
documentation.
I suggest in or with the BIOS sources.
As we're using a common BIOS it seems a good idea to make sure this kind of
things is coordinated.
Paul
On Sunday 09 September 2007, Jamie Lokier wrote:
Avi Kivity wrote:
Let's start with '-cpu host' as 'cpu host-cpuid' and implement '-cpu
host-os' on the first bug report? I have a feeling we won't ever see it.
In other words, host-os is what _I'd_ implement because I care too
much about
What you really want to do is ask your virtualization module what
features it supports.
Yes, that needs to be an additional filter.
I'd have thought that would be the *only* interesting set for autodetection.
Paul
-
I think qemu-cvs has a -cpu option for non-x86 which could be used for
this. Agree machine types are the wrong approach.
Yep, machine types are already used to switch between a different concept
so using the new -cpu option would make sense. Could perhaps extend the
syntax so that
Yes, good thinking, but this should only be done if it actually impacts
something. Reducing overhead from 0.1% to 0.05% is not worthwhile if it
introduces extra complexity.
If the overhead is that small, why are we touching this code in the first
place?
Paul
26 matches
Mail list logo
