Am 28.08.2011 um 23:34 schrieb Andreas Färber :
> Hi Alex,
>
> Am 26.07.2011 um 14:50 schrieb Alexander Graf:
>
>> Andreas, you're the only person I know who knows 68k :). Could you please
>> take a look at this code (and the split version later) and give it your
>> Acked-by if you think it's
> From: Marcelo Tosatti
> Sent: Tuesday, August 23, 2011 6:47 PM
>
> > >+ if (!apic->lapic_timer.tscdeadline)
> > >+ return;
> > >+
> > >+ tsc_target = kvm_x86_ops->
> > >+ guest_to_host_tsc(apic->lapic_timer.tscdeadline);
> > >+ rdtscll
On Mon, Aug 29, 2011 at 09:15:40AM +0300, Avi Kivity wrote:
> On 08/29/2011 09:00 AM, Edgar E. Iglesias wrote:
> >>
> >> It does bite, as I saw with gdb. You can even see that from the
> >> qemu error - it complains about unimplemented command 0xf0, that
> >> comes from pflash_write() later on.
On 08/29/2011 09:00 AM, Edgar E. Iglesias wrote:
>
> It does bite, as I saw with gdb. You can even see that from the
> qemu error - it complains about unimplemented command 0xf0, that
> comes from pflash_write() later on.
I wasn't clear enough maybe, the code in question is running, but the
On Mon, Aug 29, 2011 at 08:36:14AM +0300, Avi Kivity wrote:
> On 08/28/2011 10:33 PM, Edgar E. Iglesias wrote:
> >On Sun, Aug 28, 2011 at 06:43:36PM +0300, Avi Kivity wrote:
> >> cfi02 is annoying in that is ignores some address bits; we probably
> >> want explicit support in the memory API for t
On Mon, Aug 29, 2011 at 08:36:14AM +0300, Avi Kivity wrote:
> On 08/28/2011 10:33 PM, Edgar E. Iglesias wrote:
> >On Sun, Aug 28, 2011 at 06:43:36PM +0300, Avi Kivity wrote:
> >> cfi02 is annoying in that is ignores some address bits; we probably
> >> want explicit support in the memory API for t
On Mon, Aug 29, 2011 at 08:38:26AM +0300, Avi Kivity wrote:
> On 08/28/2011 11:37 PM, Edgar E. Iglesias wrote:
> >On Sun, Aug 28, 2011 at 06:43:36PM +0300, Avi Kivity wrote:
> >> cfi02 is annoying in that is ignores some address bits; we probably
> >> want explicit support in the memory API for t
On 08/27/2011 07:22 PM, Blue Swirl wrote:
> +
> +static void test_device_irq_line(void *opaque, uint32_t addr, uint32_t data)
> +{
> +qemu_set_irq(isa_get_irq(addr - 0x2000), !!data);
Where does 0x2000 come from?
The base address of this range.
> +
> +static uint32_t test_iomem_rea
On 08/27/2011 01:26 AM, Jan Kiszka wrote:
> +
> +static void test_device_irq_line(void *opaque, uint32_t addr, uint32_t data)
> +{
> +qemu_set_irq(isa_get_irq(addr - 0x2000), !!data);
Note that qemu-kvm retrieves (due to a hack) GSIs via isa_get_irq while
QEMU is and will remain confined
On 08/27/2011 01:07 PM, Edgar E. Iglesias wrote:
> >+
> >+static ISADeviceInfo testdev_info = {
> >+.qdev.name = "testdev",
> >+.qdev.size = sizeof(struct testdev),
> >+.init = init_test_device,
> >+.qdev.props = (Property[]) {
> >+DEFINE_PROP_CHR("chardev",
On 08/27/2011 12:22 AM, Anthony Liguori wrote:
I think I posted patches at some point for kvm unittests to use a
standard UART. Was there any reason not to do use a UART?
No.
+static void test_device_exit(void *opaque, uint32_t addr, uint32_t
data)
+{
+exit(data);
+}
Port 501 can
On 08/28/2011 11:37 PM, Edgar E. Iglesias wrote:
On Sun, Aug 28, 2011 at 06:43:36PM +0300, Avi Kivity wrote:
> cfi02 is annoying in that is ignores some address bits; we probably
> want explicit support in the memory API for that.
>
> In order to get the correct opaque into the MemoryRegion ob
On 08/28/2011 10:33 PM, Edgar E. Iglesias wrote:
On Sun, Aug 28, 2011 at 06:43:36PM +0300, Avi Kivity wrote:
> cfi02 is annoying in that is ignores some address bits; we probably
> want explicit support in the memory API for that.
>
> In order to get the correct opaque into the MemoryRegion ob
On 08/28/2011 09:14 PM, Edgar E. Iglesias wrote:
On Sun, Aug 28, 2011 at 06:43:36PM +0300, Avi Kivity wrote:
> cfi02 is annoying in that is ignores some address bits; we probably
> want explicit support in the memory API for that.
>
> In order to get the correct opaque into the MemoryRegion ob
On 08/29/2011 01:14 AM, Kevin O'Connor wrote:
On Sun, Aug 28, 2011 at 10:42:49PM +0200, Jan Kiszka wrote:
> On 2011-08-28 20:54, Alexander Graf wrote:
> >
> > On 28.08.2011, at 02:42, Avi Kivity wrote:
> >
> >> On 08/26/2011 08:32 AM, ya su wrote:
> >>> hi,Avi:
> >>>
> >>> I met t
Am 28.08.2011 22:47, schrieb Andreas Färber:
Am 28.08.2011 um 22:43 schrieb Stefan Weil:
A packed struct needs different gcc attributes for compilations
with MinGW compilers because glib-2.0 adds compiler flag
-mms-bitfields which modifies the packing algorithm.
Is that algorithm actually nee
On Fri, 26 Aug 2011 15:40:08 +1000, David Gibson
wrote:
> Near the top of hw/virtio.c we have this:
>
> /* QEMU doesn't strictly need write barriers since everything runs in
> * lock-step. We'll leave the calls to wmb() in though to make it
> obvious for
> * KVM or if kqemu gets SMP support.
Am 28.08.2011 23:43, schrieb Blue Swirl:
On Sun, Aug 28, 2011 at 8:43 PM, Stefan Weil wrote:
These patches fix the packing of structures which were affected by
the new compiler attribute -mms-bitfields (which is needed for glib-2.0).
I compiled qemu.exe with and without -mms-bitfields and comp
Allow overriding the location of Samba's smbd.
Pretty much every OS I look at has some means of
changing this path (patching) so lets just make
it easier for OS developers creating packages
and/or end users to override the location.
Signed-off-by: Brad Smith
---
Makefile.objs |2 ++
conf
On Sun, Aug 28, 2011 at 10:42:49PM +0200, Jan Kiszka wrote:
> On 2011-08-28 20:54, Alexander Graf wrote:
> >
> > On 28.08.2011, at 02:42, Avi Kivity wrote:
> >
> >> On 08/26/2011 08:32 AM, ya su wrote:
> >>> hi,Avi:
> >>>
> >>> I met the same problem, tons of hpet vm_exits(vector 209, fault
>
On Sun, Aug 28, 2011 at 8:43 PM, Stefan Weil wrote:
> These patches fix the packing of structures which were affected by
> the new compiler attribute -mms-bitfields (which is needed for glib-2.0).
>
> I compiled qemu.exe with and without -mms-bitfields and compared
> the resulting struct alignment
I don't think GDB can help us very much on that, as it's only working with
virtual addresses. You can't set a physical address breakpoint because the
protocol doesn't allow it. So I guess it can be only done in the monitor.
So, for you that you know very well the QEMU code, and suppose that I want
Hi Alex,
Am 26.07.2011 um 14:50 schrieb Alexander Graf:
Andreas, you're the only person I know who knows 68k :). Could you
please take a look at this code (and the split version later) and
give it your Acked-by if you think it's ok? I'll try and see that we
can get it in then.
My m68k ex
These patches fix the packing of structures which were affected by
the new compiler attribute -mms-bitfields (which is needed for glib-2.0).
I compiled qemu.exe with and without -mms-bitfields and compared
the resulting struct alignment using pahole and codiff.
The patches are split for different
Use QEMU_PACKED to eliminate the effects of compiler option
-mms-bitfields.
Cc: Isaku Yamahata
Signed-off-by: Stefan Weil
---
hw/acpi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/acpi.c b/hw/acpi.c
index d04b965..1cf35e1 100644
--- a/hw/acpi.c
+++ b/hw/acpi.c
@
Use QEMU_PACKED to eliminate the effects of compiler option
-mms-bitfields.
Cc: Gerd Hoffmann
Signed-off-by: Stefan Weil
---
hw/usb-ccid.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/hw/usb-ccid.c b/hw/usb-ccid.c
index 66aeb21..c2f9241 100644
--- a/
On Sun, Aug 28, 2011 at 6:13 PM, Lluís wrote:
> Blue Swirl writes:
>
>> On Sat, Aug 27, 2011 at 5:56 PM, Lluís wrote:
> I sent a patch that should fix it for everybody linking with the tracing
> objects:
>
> http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg03150.html
>>>
>>
Use QEMU_PACKED to eliminate the effects of compiler option
-mms-bitfields.
Cc: Anthony Liguori
Signed-off-by: Stefan Weil
---
hw/virtio-balloon.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/virtio-balloon.h b/hw/virtio-balloon.h
index e20cf6b..73300dd 100644
--
Am 28.08.2011 um 22:43 schrieb Stefan Weil:
A packed struct needs different gcc attributes for compilations
with MinGW compilers because glib-2.0 adds compiler flag
-mms-bitfields which modifies the packing algorithm.
Is that algorithm actually needed anywhere? If not, is there no GCC
option
Use QEMU_PACKED to eliminate the effects of compiler option
-mms-bitfields.
Cc: Jan Kiszka
Signed-off-by: Stefan Weil
---
slirp/slirp.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/slirp/slirp.h b/slirp/slirp.h
index dcf99d5..28a5c03 100644
--- a/slirp/slirp.h
+++ b
A packed struct needs different gcc attributes for compilations
with MinGW compilers because glib-2.0 adds compiler flag
-mms-bitfields which modifies the packing algorithm.
Attribute gcc_struct reverses the negative effects of -mms-bitfields.
QEMU_PACKED sets this attribute and must be used for a
Use QEMU_PACKED to eliminate the effects of compiler option
-mms-bitfields.
Cc: Kevin Wolf
Signed-off-by: Stefan Weil
---
block/vvfat.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/block/vvfat.c b/block/vvfat.c
index d6a07ef..ae1c03d 100644
--- a/block/v
Use QEMU_PACKED to eliminate the effects of compiler option
-mms-bitfields.
Cc: Alexander Graf
Signed-off-by: Stefan Weil
---
hw/hpet_emul.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/hpet_emul.h b/hw/hpet_emul.h
index 8bf312a..6128702 100644
--- a/hw/hpet_em
On 2011-08-28 20:54, Alexander Graf wrote:
>
> On 28.08.2011, at 02:42, Avi Kivity wrote:
>
>> On 08/26/2011 08:32 AM, ya su wrote:
>>> hi,Avi:
>>>
>>> I met the same problem, tons of hpet vm_exits(vector 209, fault
>>> address is in the guest vm's hpet mmio range), even I disable hpet
>>> de
On Sun, Aug 28, 2011 at 06:43:36PM +0300, Avi Kivity wrote:
> cfi02 is annoying in that is ignores some address bits; we probably
> want explicit support in the memory API for that.
>
> In order to get the correct opaque into the MemoryRegion object, the
> allocation scheme is changed so that the
Am 28.08.2011 um 21:45 schrieb Stefan Weil:
Signed-off-by: Stefan Weil
Reviewed-by: Andreas Färber
Thanks,
Andreas
---
docs/qapi-code-gen.txt |2 +-
libcacard/vscclient.c |2 +-
qemu-ga.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/docs/qap
Signed-off-by: Stefan Weil
---
docs/qapi-code-gen.txt |2 +-
libcacard/vscclient.c |2 +-
qemu-ga.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/docs/qapi-code-gen.txt b/docs/qapi-code-gen.txt
index b7befb5..f345866 100644
--- a/docs/qapi-code-ge
On Sun, Aug 28, 2011 at 06:43:36PM +0300, Avi Kivity wrote:
> cfi02 is annoying in that is ignores some address bits; we probably
> want explicit support in the memory API for that.
>
> In order to get the correct opaque into the MemoryRegion object, the
> allocation scheme is changed so that the
On 28.08.2011, at 02:42, Avi Kivity wrote:
> On 08/26/2011 08:32 AM, ya su wrote:
>> hi,Avi:
>>
>> I met the same problem, tons of hpet vm_exits(vector 209, fault
>> address is in the guest vm's hpet mmio range), even I disable hpet
>> device in win7 guest vm, it still produce a larget amoun
On 27.08.2011, at 04:12, Daniel Verkamp wrote:
> Implement an I/O space index-data register pair as defined by the AHCI
> spec, including the corresponding SATA PCI capability and BAR.
>
> This allows real-mode code to access the AHCI registers; real-mode
> code cannot address the memory-mapped
On Sun, Aug 28, 2011 at 8:14 PM, Edgar E. Iglesias wrote:
> On Sun, Aug 28, 2011 at 06:43:36PM +0300, Avi Kivity wrote:
> > cfi02 is annoying in that is ignores some address bits; we probably
> > want explicit support in the memory API for that.
> >
> > In order to get the correct opaque into the
Prepares for uint32 replacement.
Signed-off-by: Andreas Färber
---
fpu/softfloat.c | 20 ++--
fpu/softfloat.h |4 ++--
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/fpu/softfloat.c b/fpu/softfloat.c
index be1206d..2b20085 100644
--- a/fpu/softfloat.c
+++
Prepares for uint16 replacement.
Signed-off-by: Andreas Färber
---
fpu/softfloat.c |8
fpu/softfloat.h |4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fpu/softfloat.c b/fpu/softfloat.c
index 7951a0e..be1206d 100644
--- a/fpu/softfloat.c
+++ b/fpu/softfloa
Blue Swirl writes:
> On Sat, Aug 27, 2011 at 5:56 PM, Lluís wrote:
I sent a patch that should fix it for everybody linking with the tracing
objects:
http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg03150.html
>>
>>> With your patch, there are warnings from linker:
>>>
On Sun, Aug 28, 2011 at 06:43:36PM +0300, Avi Kivity wrote:
> cfi02 is annoying in that is ignores some address bits; we probably
> want explicit support in the memory API for that.
>
> In order to get the correct opaque into the MemoryRegion object, the
> allocation scheme is changed so that the
This patchset is primarily features and bugfixes for the
omap_gpmc device from the Meego tree.
We start by adding a new sysbus function to get the MemoryRegion*
for a sysbus MMIO region. This was discussed in
http://www.mail-archive.com/kvm@vger.kernel.org/msg59535.html
and as noted there can als
From: Juha Riihimäki
Minor whitespace-only cleanup (separated out from the qdevifying
patch for clarity).
Signed-off-by: Juha Riihimäki
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by: Pe
Signed-off-by: Peter Maydell
---
hw/omap.h |3 ++-
hw/omap2.c |3 ++-
hw/omap_gpmc.c |5 -
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/hw/omap.h b/hw/omap.h
index 81f5544..d9ab006 100644
--- a/hw/omap.h
+++ b/hw/omap.h
@@ -119,7 +119,8 @@ void omap_sdrc
This patchset is primarily features and bugfixes for the
omap_gpmc device from the Meego tree.
We start by adding a new sysbus function to get the MemoryRegion*
for a sysbus MMIO region. This was discussed in
http://www.mail-archive.com/kvm@vger.kernel.org/msg59535.html
and as noted there can als
Support accesses to NAND devices, both by mapping them into
the GPMC address space, and via the NAND_COMMAND, NAND_ADDRESS
and NAND_DATA GPMC registers.
Signed-off-by: Peter Maydell
---
hw/omap.h |1 +
hw/omap_gpmc.c | 219 ---
2 file
The OMAP3 TRM is inconsistent about whether the GPMC FIFOTHRESHOLDSTATUS
bit should be set when FIFOPOINTER > FIFOTHRESHOLD or when it is >=
FIFOTHRESHOLD. Apparently the underlying functional spec from which
the TRM was created states that the behaviour is ">=", and this also
makes more conceptual
Refactor the omap_gpmc_cs_map/unmap functions:
* take the omap_gpmc_s* and a chipselect id rather than the
omap_gpmc_cs_file_s*, so they have access to the general gpmc
member fields
* extract the base and mask from the config registers in the functions
rather than at every callsite
* c
Refactor the gpmc state structure so items relating to
the prefetch engine are in their own sub-struct and have
more useful names.
Signed-off-by: Peter Maydell
---
hw/omap_gpmc.c | 52
1 files changed, 28 insertions(+), 24 deletions(-)
diff
Whitespace-only change fixing indentation.
Signed-off-by: Peter Maydell
---
hw/omap_gpmc.c | 96
1 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/hw/omap_gpmc.c b/hw/omap_gpmc.c
index 5c1365c..c569aa1 100644
--- a/hw/omap
From: Juha Riihimäki
Signed-off-by: Juha Riihimäki
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by: Peter Maydell
---
hw/omap_gpmc.c |4 +++-
1 files changed, 3 insertions(+), 1 dele
Now that all callers of omap_gpmc_attach pass in a MemoryRegion*,
we can remove the base_update and unmap function pointer arguments,
and the opaque pointer that was passed into these callbacks.
We can also remove the base and size fields from omap_gpmc_cs_file_s
as these are no longer necessary (
The omap_gpmc wasn't actually wiring up its IRQ, so
anything that provoked an interrupt would be using
uninitialised data for its IRQ number.
Signed-off-by: Peter Maydell
---
hw/omap_gpmc.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/hw/omap_gpmc.c b/hw/omap_gpmc.c
i
This commit implements the prefetch engine feature of the GPMC
which can be used for NAND devices. This includes both interrupt
driven and DMA-filling modes.
Signed-off-by: Peter Maydell
---
hw/omap_gpmc.c | 257 +--
1 files changed, 247 inser
Fix a bug in the handling of writes to GPMC_IRQSTATUS:
it behaves as "write one to clear, writing zero is ignored".
Signed-off-by: Peter Maydell
---
hw/omap_gpmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/omap_gpmc.c b/hw/omap_gpmc.c
index d16b28b..ff4d485 100
From: Juha Riihimäki
Refactor onenand_command() -- since it is essentially a method of
the device object, it doesn't make sense to pass in something as
an argument which is one of the object's own member fields.
Signed-off-by: Juha Riihimäki
[Riku Voipio: Fixes and restructuring patchset]
Signe
From: Juha Riihimäki
Take a pointer to the omap mpu state struct in omap_gpmc_init.
Some details of GPMC behaviour depend on the OMAP version we
are a part of.
Signed-off-by: Juha Riihimäki
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio
[Peter Maydell: More fixes an
From: Juha Riihimäki
Qdevify the ONENAND device.
Signed-off-by: Juha Riihimäki
[Riku Voipio: Fixes and restructuring patchset]
Signed-off-by: Riku Voipio
[Peter Maydell: More fixes and cleanups for upstream submission]
Signed-off-by: Peter Maydell
---
hw/flash.h |7 +---
hw/nseries.c
Add the OMAP 3630 to the omap_mpu_model enumeration, and add the
corresponding cpu_is_omap3630() function.
(OMAP3 isn't supported yet but this is useful in upgrading common
components to be "OMAP3 ready". We already have this for OMAP3430.)
Signed-off-by: Peter Maydell
---
hw/omap.h |5
Add a sysbus_mmio_get_region() which allows users of sysbus
devices to turn a (SysBusDevice*, mmioidx) tuple into a
MemoryRegion*. This enables some useful simplifications of
devices which pass through another device's mmio region
(either directly or by implementing some kind of memory
controller d
From: Juha Riihimäki
OMAP3630 adds an extra bit of address masking, so a mask of
0xb is valid. Unfortunately the GPMC_REVISION is the same as
on the OMAP3430 which only has three bits of address masking, so
we have to derive this feature directly from the OMAP revision
rather than from the GP
On 28.08.2011, at 09:08, Peter Maydell wrote:
> On 28 August 2011 14:47, Alexander Graf wrote:
>> Well, if we want host machine dependent types we should use host
>> dependent types.
>
> ...we couldn't decide what we wanted :-)
>
>> Apparently uint16 is expected to be uint32_t in the code IIU
Anthony, please pull from
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/core
to receive fixes for the rom/device API - initialize ->ops and a new
->opaque.
Avi Kivity (2):
memory: fix memory_region_init_rom_device() not initializing ->ops
memory: add opaque parameter
I'm trying to integrate OpenBIOS to general rom building framework in
QEMU but I have some problems with 'make'.
For some reason, build succeeds if run 'make' in
'obj-amd64/pc-bios/openbios' but fails in top level 'obj-amd64'. Maybe
some QEMU makefile variables leak to OpenBIOS make? Using a shell
cfi02 is annoying in that is ignores some address bits; we probably
want explicit support in the memory API for that.
In order to get the correct opaque into the MemoryRegion object, the
allocation scheme is changed so that the flash emulation code allocates
memory, instead of the caller. This cl
Anthony, please pull from
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/urgent
to receive a fix for boundless recursion in the sh target, due to a bug
in the memory API conversion.
Avi Kivity (1):
sh_pci: Fix sh_pci memory alias confusion
hw/sh_pci.c |2 +-
1 files c
On 08/11/2011 01:28 AM, Richard Henderson wrote:
The only non-obvious part is pic_poll_read which used
"addr1>> 7" to detect whether one referred to either
the master or slave PIC. Instead, test this directly.
Crashes mipsel-test from qemu.org immediately:
/* XXX: add generic master/slave
On Sun, Aug 28, 2011 at 02:21:29PM +0100, Peter Maydell wrote:
> On 27 August 2011 18:38, Edgar E. Iglesias wrote:
> > On Thu, Aug 25, 2011 at 09:04:56PM +0100, Peter Maydell wrote:
> >> @@ -659,7 +713,7 @@ static void onenand_write(void *opaque,
> >> target_phys_addr_t addr,
> >> if (s-
On 28 August 2011 14:47, Alexander Graf wrote:
> Well, if we want host machine dependent types we should use host
> dependent types.
...we couldn't decide what we wanted :-)
>Apparently uint16 is expected to be uint32_t in the code IIUC.
If the softfloat code relies on uint16 being exactly 32 b
On 08/28/2011 04:56 PM, Joerg Roedel wrote:
On Sun, Aug 28, 2011 at 04:14:00PM +0300, Avi Kivity wrote:
> On 08/26/2011 12:24 PM, Roedel, Joerg wrote:
>> The biggest problem with this approach is that it has to happen in the
>> context of the given process. Linux can't really modify an mm whi
On Sun, Aug 28, 2011 at 04:14:00PM +0300, Avi Kivity wrote:
> On 08/26/2011 12:24 PM, Roedel, Joerg wrote:
>> The biggest problem with this approach is that it has to happen in the
>> context of the given process. Linux can't really modify an mm which
>> which belong to another context in a safe w
On 08/28/2011 04:42 PM, Michael S. Tsirkin wrote:
On Sun, Aug 28, 2011 at 04:10:14PM +0300, Avi Kivity wrote:
> On 08/28/2011 02:41 PM, Michael S. Tsirkin wrote:
> >>
> >> If it really matters, you can add a prefetchability attribute to
> >> MemoryRegions. Does it though?
> >
> >Well,
On 28.08.2011, at 08:34, Andreas Färber wrote:
> Am 28.08.2011 um 15:02 schrieb Alexander Graf:
>
>> On 28.08.2011, at 07:09, Andreas Färber wrote:
>>
>>> Any thoughts on how to proceed? My previous approach for Haiku, to replace
>>> non-standard uint16 with POSIX uint_fast16_t etc., was rejec
On Sun, Aug 28, 2011 at 04:10:14PM +0300, Avi Kivity wrote:
> On 08/28/2011 02:41 PM, Michael S. Tsirkin wrote:
> >>
> >> If it really matters, you can add a prefetchability attribute to
> >> MemoryRegions. Does it though?
> >
> >Well, its another one of these things that
> >guests *probably* wo
Am 28.08.2011 um 15:02 schrieb Alexander Graf:
On 28.08.2011, at 07:09, Andreas Färber wrote:
Any thoughts on how to proceed? My previous approach for Haiku, to
replace non-standard uint16 with POSIX uint_fast16_t etc., was
rejected to avoid system-dependent widths. I'd really like to get
On 28 August 2011 14:02, Alexander Graf wrote:
> On 28.08.2011, at 07:09, Andreas Färber wrote:
>> Any thoughts on how to proceed? My previous approach for Haiku,
>> to replace non-standard uint16 with POSIX uint_fast16_t etc.,
>> was rejected to avoid system-dependent widths. I'd really like
>> t
On 27 August 2011 18:38, Edgar E. Iglesias wrote:
> On Thu, Aug 25, 2011 at 09:04:56PM +0100, Peter Maydell wrote:
>> @@ -659,7 +713,7 @@ static void onenand_write(void *opaque,
>> target_phys_addr_t addr,
>> if (s->intstatus & (1 << 15))
>> break;
>> s->command = v
On 08/26/2011 12:24 PM, Roedel, Joerg wrote:
>
> As I see it there are two options: (a) make subsequent accesses from
> userspace or the guest result in either a SIGBUS that userspace must
> either deal with or die, or (b) replace the mapping with a dummy RO
> mapping containing 0xff, with an
On 08/28/2011 02:41 PM, Michael S. Tsirkin wrote:
>
> If it really matters, you can add a prefetchability attribute to
> MemoryRegions. Does it though?
Well, its another one of these things that
guests *probably* won't in practice use.
But I don't see a way to be sure.
If the guest puts a pr
On 28.08.2011, at 07:09, Andreas Färber wrote:
> Hello,
>
> The unresolved softfloat uint* conversion business bites us again: This time,
> the previously working Cocoa frontend stopped compiling:
>
> In file included from /Users/andreas/QEMU/qemu/bswap.h:14,
> from /Users/andr
Hello,
The unresolved softfloat uint* conversion business bites us again:
This time, the previously working Cocoa frontend stopped compiling:
In file included from /Users/andreas/QEMU/qemu/bswap.h:14,
from /Users/andreas/QEMU/qemu/qemu-common.h:103,
from /Use
Fixed by 67494323f2c782fe3e65c60529fe9dfa613fc500.
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/818647
Title:
Getting segmentation fault w
The bug is real but it can only be fixed in OpenBIOS.
** Changed in: qemu
Status: New => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/818645
Title:
Unhandled OF service in FreeBSD
QEMU video devices need no changes, this can only be fixed in OpenBIOS.
** Changed in: qemu
Status: New => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/813788
Title:
PowerPC video
On Sun, Aug 28, 2011 at 10:50:49AM +0300, Avi Kivity wrote:
> On 08/26/2011 12:43 PM, Michael S. Tsirkin wrote:
> >On Thu, Aug 18, 2011 at 08:15:43AM -0700, Avi Kivity wrote:
> >> It's correct but insufficient, the filtering code
> >> (pci_bridge_filter) needs to be updated to use the memory API.
Thanks, applied. I added the comment myself.
On Mon, Jul 25, 2011 at 5:22 PM, Artyom Tarasenko wrote:
> clear interrupt request if the interrupt priority < CPU pil
> clear hardware interrupt request if interrupts are disabled
>
> Signed-off-by: Artyom Tarasenko
> ---
> hw/sun4u.c | 6 --
On Fri, Aug 26, 2011 at 01:29:23PM -0500, Ryan Harper wrote:
> * Michael S. Tsirkin [2011-08-25 05:11]:
> > When the vhost notifier is disabled, the userspace handler runs
> > immediately: virtio_pci_set_host_notifier_internal might
> > call virtio_queue_notify_vq.
> > Since the VQ state and the t
Am 20.07.2011 um 20:56 schrieb Stefan Weil:
cppcheck reports this error:
qemu/hw/sh_intc.c:390: error: Possible null pointer dereference:
s - otherwise it is redundant to check if s is null at line 385
If s were NULL, the printf() statement would crash.
Setting braces fixes this bug.
Signed-o
On 2011-08-28 09:10, Blue Swirl wrote:
> On Sat, Aug 27, 2011 at 2:16 PM, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> The master PIC is connected to the LINTIN0 of the APICs. As the APIC
>> currently does not track the state of that line, we have to ask the PIC
>> to re-inject its IRQ after the C
On Thu, Aug 25, 2011 at 09:04:54PM +0100, Peter Maydell wrote:
> This patchset is primarily features and bugfixes for the
> omap_gpmc device from the Meego tree.
>
> We start by adding a new sysbus function to get the MemoryRegion*
> for a sysbus MMIO region. This was discussed in
> http://www.ma
On 08/23/2011 05:10 PM, Jan Kiszka wrote:
On 2011-08-23 16:02, Anthony Liguori wrote:
> On 08/23/2011 08:02 AM, Jan Kiszka wrote:
>> On 2011-08-23 14:40, Anthony Liguori wrote:
>>> You should be able to just use an eventfd or pipe.
>>>
>>> Better yet, we should look at using GThreadPool to re
Fix install(1) usage to be compatible with OpenBSD's install(1).
When creating a directory via the -d flag the -p flag cannot be
used at the same time. Also in the context of installing QEMU it
doesn't make sense to use the -p flag anyway so use the [default]
-c flag instead.
Signed-off-by: Brad
On 08/26/2011 01:21 AM, Edgar E. Iglesias wrote:
Hi,
This converts most of the Xilinx devices to MemoryRegion.
I dont have a little endian image with axi dma& enet readily available,
so I'll do those later.
Avi, if you want to keep your queue short, just Ack and I'll apply this.
But feel free
On 08/26/2011 12:43 PM, Michael S. Tsirkin wrote:
On Thu, Aug 18, 2011 at 08:15:43AM -0700, Avi Kivity wrote:
> It's correct but insufficient, the filtering code
> (pci_bridge_filter) needs to be updated to use the memory API.
>
> Basically it gets simpler and correcter.
I've been struggling
On Sat, Aug 27, 2011 at 5:56 PM, Lluís wrote:
> Blue Swirl writes:
>
>> On Fri, Aug 26, 2011 at 7:12 PM, Lluís wrote:
>>> Blue Swirl writes:
>>>
957f1f99f263d57612807a9535f75ca4473f05f0 didn't consider
that qemu-timer-common.o is needed by simpletrace.
>>>
Fix by adding it to qga o
On Sat, Aug 27, 2011 at 2:16 PM, Jan Kiszka wrote:
> From: Jan Kiszka
>
> The master PIC is connected to the LINTIN0 of the APICs. As the APIC
> currently does not track the state of that line, we have to ask the PIC
> to re-inject its IRQ after the CPU picked up an event from the APIC.
>
> Adds
100 matches
Mail list logo
