On Mon, 15 Feb 2010, Juergen Lock wrote:
> On Mon, Feb 15, 2010 at 06:16:07AM +0300, malc wrote:
> > On Sun, 14 Feb 2010, Juergen Lock wrote:
> >
> > > Submitted by: Andreas Tobler
> > >
> > > Signed-off-by: Juergen Lock
> > >
> > > --- a/cache-utils.c
> > > +++ b/cache-utils.c
> > > @@ -57,6
On Monday 15 February 2010 07:08:33 Michael S. Tsirkin wrote:
> On Mon, Feb 15, 2010 at 06:58:33AM -0600, Rob Landley wrote:
> > On Monday 15 February 2010 05:19:24 Alexander Graf wrote:
> > > On 15.02.2010, at 12:10, Rob Landley wrote:
> > > > On Sunday 14 February 2010 08:41:00 Alexander Graf wro
On Mon, Feb 15, 2010 at 06:33:59PM +0100, Jes Sorensen wrote:
> Hi,
>
> This is the Seabios part to match my e820 reservation via fw_cfg patch.
This still has 'struct e820_entry' which is too similar to 'struct
e820entry' in memmap.h. Otherwise, it looks good to me.
-Kevin
On Sat, Feb 13, 2010 at 2:33 AM, Arnd Bergmann wrote:
> The original macvtap code has a number of problems
> resulting from the use of RCU for protecting the
> access to struct macvtap_queue from open files.
>
> This includes
> - need for GFP_ATOMIC allocations for skbs
> - potential deadlocks whe
On Mon, Feb 15, 2010 at 06:16:07AM +0300, malc wrote:
> On Sun, 14 Feb 2010, Juergen Lock wrote:
>
> > Submitted by: Andreas Tobler
> >
> > Signed-off-by: Juergen Lock
> >
> > --- a/cache-utils.c
> > +++ b/cache-utils.c
> > @@ -57,6 +57,23 @@
> > }
> > #endif
> >
> > +#if defined(__FreeBSD
On Mon, Feb 15, 2010 at 06:15:41AM +0300, malc wrote:
> On Sun, 14 Feb 2010, Juergen Lock wrote:
>
> > Submitted by: Andreas Tobler
> >
> > Signed-off-by: Juergen Lock
> >
> > --- a/cache-utils.c
> > +++ b/cache-utils.c
> > @@ -57,6 +57,23 @@
> > }
> > #endif
> >
> > +#if defined(__FreeBSD
On Mon, Feb 15, 2010 at 11:17:27PM +0100, Christoph Hellwig wrote:
> On Fri, Feb 12, 2010 at 06:47:55PM +, Richard W.M. Jones wrote:
> > I don't think there's a good solution for this at the qemu level.
> > However I have a working patch for glibc:
> >
> > https://bugzilla.redhat.com/show_bug.
On Fri, Feb 12, 2010 at 06:47:55PM +, Richard W.M. Jones wrote:
> I don't think there's a good solution for this at the qemu level.
> However I have a working patch for glibc:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=563103#c13
Any chance you could just persuade Uli to drop the optimiz
On Fri, Feb 12, 2010 at 11:28:57AM -0600, Anthony Liguori wrote:
> >Yes. The BSDs tend to not play stupid emulation games in the libc, so
> >changes of these kinds of messups to happen are far less.
> >
>
> In all fairness, I seem to recall there being a problem with the kernel
> implementati
On 02/13/2010 02:01 PM, Blue Swirl wrote:
> On Tue, Feb 9, 2010 at 11:37 PM, Richard Henderson wrote:
>> ---
>> tcg/sparc/tcg-target.c | 126
>>
>> 1 files changed, 126 insertions(+), 0 deletions(-)
>
> Something's wrong with the patch...
Oops.
Use TARGET_VIRT_ADDR_SPACE_BITS for the virtual memory map based off
of l1_map. This rewrites page_find_alloc, page_flush_tb, and
walk_memory_regions.
Use TARGET_PHYS_ADDR_SPACE_BITS for the physical memory map based off
of l1_phys_map. This rewrites page_phys_find_alloc and
phys_page_for_each.
Don't return addresses that aren't properly aligned for the guest,
e.g. when the guest has a larger page size than the host. Don't
return addresses that are outside the virtual address space for the
target, by paying proper attention to the h2g/g2h macros.
At the same time, place the default mapp
Changes since v1:
* Sparc virt and phys address range corrections.
* Unrelated changes removed.
* Assertions added for guest address space.
r~
Richard Henderson (7):
Move TARGET_PHYS_ADDR_SPACE_BITS to target-*/cpu.h.
Use TARGET_VIRT_ADDR_SPACE_BITS in h2g_valid.
Fix last page erro
Previously, only 32-bit guests had a proper check for the
validity of the virtual address. Extend that check to 64-bit
guests with a restricted virtual address space.
---
cpu-all.h | 16 +++-
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/cpu-all.h b/cpu-all.h
index
---
linux-user/mmap.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/linux-user/mmap.c b/linux-user/mmap.c
index 25fc0b2..65fdc33 100644
--- a/linux-user/mmap.c
+++ b/linux-user/mmap.c
@@ -80,16 +80,15 @@ void mmap_unlock(void)
void *qemu_vmalloc(size_t size)
{
We don't expect host addresses within page_set_flags or
page_check_range.
---
exec.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/exec.c b/exec.c
index bb712ec..10673fc 100644
--- a/exec.c
+++ b/exec.c
@@ -2327,6 +2327,14 @@ void page_set_flags(target_ulo
The addr < end comparison prevents the last page from being
iterated; an iteration based on length avoids this problem.
---
exec.c | 39 +--
1 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/exec.c b/exec.c
index 766568b..1521ce3 100644
--- a/ex
Removes a set of ifdefs from exec.c.
Introduce TARGET_VIRT_ADDR_SPACE_BITS for all targets other
than Alpha. This will be used for page_find_alloc, which is
supposed to be using virtual addresses in the first place.
---
exec.c | 17 -
target-alpha/cpu.h |
On Mon, 15 Feb 2010, Jes Sorensen wrote:
> Hi,
>
> Kevin and I have agreed on the approach for this one now. So here is
> the latest version of the patch for QEMU, submitting e820 reservation
> entries via fw_cfg.
>
I think the interface is fine and it is perfectly usable by Xen as well.
Cheers
Anthony Liguori writes:
> Hi Markus,
>
> On 02/12/2010 11:48 AM, Markus Armbruster wrote:
>> Our QError conversions were pretty straightforward so far. For example,
>> when we found
>>
>> monitor_printf(mon, "device is not removable\n");
>>
>> in eject_device(), we created the o
Thanks, applied.
On Mon, Feb 15, 2010 at 7:39 PM, Artyom Tarasenko
wrote:
> Don't raise irq when not enabled.
> Raise irq on enabling if DMA_INTR is set
> Don't clear irq unless it was raised by DMA, as there are other irq sources
> Don't set DMA_INTR bit spuriously.
>
> v1->v2:
> - Don't clear
Don't raise irq when not enabled.
Raise irq on enabling if DMA_INTR is set
Don't clear irq unless it was raised by DMA, as there are other irq sources
Don't set DMA_INTR bit spuriously.
v1->v2:
- Don't clear irq unless it was raised by DMA
- Raise irq on enabling if DMA_INTR is set
- Assume rev
Hi,
This is the Seabios part to match my e820 reservation via fw_cfg patch.
Cheers,
Jes
Read optional table of e820 entries from qemu_cfg
Read optional table of e820 entries through qemu_cfg, allowing QEMU to
provide the location of KVM's switch area etc. rather than rely on
hard coded values.
Hi,
Kevin and I have agreed on the approach for this one now. So here is
the latest version of the patch for QEMU, submitting e820 reservation
entries via fw_cfg.
Cheers,
Jes
Use qemu-cfg to provide the BIOS with an optional table of e820 entries.
Notify the BIOS of the location of the TSS+EPT
The current implementation of alloc_refcount_block and grow_refcount_table has
fundamental problems regarding error handling. There are some places where an
I/O error means that the image is going to be corrupted. I have found that the
only way to fix this is to completely rewrite the thing.
In de
Implement some more refcount block related checks
Signed-off-by: Kevin Wolf
---
block/qcow2-refcount.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
index e7fdf64..e50fb2a 100644
--- a/block/qcow2-refcount.c
+
When the refcount table grows, it doesn't only grow by one entry but reserves
some space for future refcount blocks. The algorithm to calculate the number of
entries stays the same with the fixes, so factor it out before replacing the
rest.
Signed-off-by: Kevin Wolf
---
block/qcow2-refcount.c |
The current implementation of alloc_refcount_block and grow_refcount_table has
fundamental problems regarding error handling. There are some places where an
I/O error means that the image is going to be corrupted. I have found that the
only way to fix this is to completely rewrite the thing.
Just
When compiled with CONFIG_DEBUG_TCG, this code looks
for missing, duplicate and wrong entries in the
op definitions.
Errors will raise an assertion at program start
(all checks are done in the initial phase).
The current code contains such errors, at least for
i386 guest on i386 host.
Signed-off
The version 0.13 will be the new default and compatibility options will
be added to the 0.12 version.
Signed-off-by: Amit Shah
---
v2: register the 0.12 version in this patch instead of the next one.
hw/pc.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/hw/pc
From: Michael S. Tsirkin
Since commit 98b19252cf1bd97c54bc4613f3537c5ec0aae263, all
serial devices declare MULTIPORT feature.
To allow 0.12 compatibility, we should clear this when
max_nr_ports is 1.
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Amit Shah
---
hw/virtio-serial-bus.c |6
virtio-serial-pci can support multiple ports in the current development
version that will become 0.13. Add compatibility options for the 0.12
and 0.11 pc machine types.
Signed-off-by: Amit Shah
---
hw/pc.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
di
On (Mon) Feb 15 2010 [16:07:28], Michael S. Tsirkin wrote:
> On Mon, Feb 15, 2010 at 06:51:31PM +0530, Amit Shah wrote:
> > On (Fri) Feb 12 2010 [15:42:14], Michael S. Tsirkin wrote:
> > > Since commit 98b19252cf1bd97c54bc4613f3537c5ec0aae263, all
> > > serial devices declare MULTIPORT feature.
> >
On 02/15/10 16:13, Amit Shah wrote:
The version 0.13 will be the new default and compatibility options will
be added to the 0.12 version.
Whole series looks good now.
Acked-by: Gerd Hoffmann
cheers,
Gerd
On (Mon) Feb 15 2010 [15:36:34], Gerd Hoffmann wrote:
>> @@ -1143,6 +1171,7 @@ static QEMUMachine isapc_machine = {
>> static void pc_machine_init(void)
>> {
>> qemu_register_machine(&pc_machine);
>> +qemu_register_machine(&pc_machine_v0_12);
>> qemu_register_machine(&pc_machine
@@ -1143,6 +1171,7 @@ static QEMUMachine isapc_machine = {
static void pc_machine_init(void)
{
qemu_register_machine(&pc_machine);
+qemu_register_machine(&pc_machine_v0_12);
qemu_register_machine(&pc_machine_v0_11);
qemu_register_machine(&pc_machine_v0_10);
qemu_reg
On Mon, Feb 15, 2010 at 06:51:31PM +0530, Amit Shah wrote:
> On (Fri) Feb 12 2010 [15:42:14], Michael S. Tsirkin wrote:
> > Since commit 98b19252cf1bd97c54bc4613f3537c5ec0aae263, all
> > serial devices declare MULTIPORT feature.
> > To allow 0.12 compatibility, we should clear this when
> > max_nr_
From: Michael S. Tsirkin
Since commit 98b19252cf1bd97c54bc4613f3537c5ec0aae263, all
serial devices declare MULTIPORT feature.
To allow 0.12 compatibility, we should clear this when
max_nr_ports is 1.
Signed-off-by: Michael S. Tsirkin
Signed-off-by: Amit Shah
---
hw/virtio-serial-bus.c |6
virtio-serial-pci can support multiple ports in the current development
version that will become 0.13. Add compatibility options for the 0.12
and 0.11 pc machine types.
Signed-off-by: Amit Shah
---
hw/pc.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
d
The version 0.13 will be the new default and compatibility options will
be added to the 0.12 version.
Signed-off-by: Amit Shah
---
hw/pc.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/hw/pc.c b/hw/pc.c
index 6fbe98b..7c9a24e 100644
--- a/hw/pc.c
+++ b/hw/pc.c
On (Fri) Feb 12 2010 [15:42:14], Michael S. Tsirkin wrote:
> Since commit 98b19252cf1bd97c54bc4613f3537c5ec0aae263, all
> serial devices declare MULTIPORT feature.
> To allow 0.12 compatibility, we should clear this when
> max_nr_ports is 1.
>
> Signed-off-by: Michael S. Tsirkin
Acked-by: Amit S
On 15.02.2010, at 13:58, Rob Landley wrote:
> On Monday 15 February 2010 05:19:24 Alexander Graf wrote:
>> On 15.02.2010, at 12:10, Rob Landley wrote:
>>> On Sunday 14 February 2010 08:41:00 Alexander Graf wrote:
So the only case I can imagine that this breaks anything is that
uClibc re
On Mon, Feb 15, 2010 at 06:58:33AM -0600, Rob Landley wrote:
> On Monday 15 February 2010 05:19:24 Alexander Graf wrote:
> > On 15.02.2010, at 12:10, Rob Landley wrote:
> > > On Sunday 14 February 2010 08:41:00 Alexander Graf wrote:
> > >> So the only case I can imagine that this breaks anything is
On Monday 15 February 2010 05:19:24 Alexander Graf wrote:
> On 15.02.2010, at 12:10, Rob Landley wrote:
> > On Sunday 14 February 2010 08:41:00 Alexander Graf wrote:
> >> So the only case I can imagine that this breaks anything is that
> >> uClibc requires register state to be 0.
> >
> > Yes, r3 (w
On 02/15/10 10:24, Amit Shah wrote:
Is there a qdev property for max_nr_ports? Then simply adding a compat
property will do the trick.
Something like this (I can split it into two patches before submission):
Yep, should be splitted.
diff --git a/hw/pc.c b/hw/pc.c
index 5b29f3b..a975934 100
On 15.02.2010, at 12:10, Rob Landley wrote:
> On Sunday 14 February 2010 08:41:00 Alexander Graf wrote:
>> Am Sun 14 Feb 2010 09:36:27 AM CET schrieb Rob Landley :
>>> On Thursday 11 February 2010 06:32:12 Alexander Graf wrote:
Rob Landley wrote:
> Static binaries that run under the Linu
On Sunday 14 February 2010 08:41:00 Alexander Graf wrote:
> Am Sun 14 Feb 2010 09:36:27 AM CET schrieb Rob Landley :
> > On Thursday 11 February 2010 06:32:12 Alexander Graf wrote:
> >> Rob Landley wrote:
> >> > Static binaries that run under the Linux kernel don't run under
> >> > qemu-ppc. For ex
On Mon, Feb 15, 2010 at 02:54:01PM +0530, Amit Shah wrote:
> On (Mon) Feb 15 2010 [10:03:34], Gerd Hoffmann wrote:
> > On 02/12/10 15:23, Amit Shah wrote:
> >> On (Fri) Feb 12 2010 [15:42:14], Michael S. Tsirkin wrote:
> >>> Since commit 98b19252cf1bd97c54bc4613f3537c5ec0aae263, all
> >>> serial de
Taimoor Mirza wrote:
> Hi all,
>
>
>
> I downloaded version 0.12.2 of QEMU and I am unable to find EHCI support in
> it. Does QEMU support EHCI emulation? Do I need to download some other patch
> for it? QEMU documentation also does not tell anything about EHCI.
>
QEMU does not support USB
On (Mon) Feb 15 2010 [10:03:34], Gerd Hoffmann wrote:
> On 02/12/10 15:23, Amit Shah wrote:
>> On (Fri) Feb 12 2010 [15:42:14], Michael S. Tsirkin wrote:
>>> Since commit 98b19252cf1bd97c54bc4613f3537c5ec0aae263, all
>>> serial devices declare MULTIPORT feature.
>>> To allow 0.12 compatibility, we
On Sunday 14 February 2010, Michael S. Tsirkin wrote:
> > @@ -473,7 +477,7 @@ static struct socket *get_socket(int fd)
> > sock = get_raw_socket(fd);
> > if (!IS_ERR(sock))
> > return sock;
> > - sock = get_tun_socket(fd);
> > + sock = get_tap_socket(fd);
> >
On 02/12/10 15:23, Amit Shah wrote:
On (Fri) Feb 12 2010 [15:42:14], Michael S. Tsirkin wrote:
Since commit 98b19252cf1bd97c54bc4613f3537c5ec0aae263, all
serial devices declare MULTIPORT feature.
To allow 0.12 compatibility, we should clear this when
max_nr_ports is 1.
In addition to this, set
On 15.02.2010, at 07:12, OHMURA Kei wrote:
> dirty-bitmap-traveling is carried out by byte size in qemu-kvm.c.
> But We think that dirty-bitmap-traveling by long size is faster than by byte
"We think"? I mean - yes, I think so too. But have you actually measured it?
How much improvement are we
Paolo Bonzini writes:
> On 02/13/2010 10:40 PM, Stefan Weil wrote:
>> This command used to work, but fails now:
>>
>> $ i386-softmmu/qemu -snapshot /dev/sda
>> qemu: could not open disk image /dev/sda: Permission denied
>>
>> $ ls -l /dev/sda
>> brw-rw-r-- 1 root disk 8, 0 13. Feb 08:55 /dev/sda
54 matches
Mail list logo
