The functions which do the core estimation algorithms for the VRSQRTE
and VRECPE instructions should not set floating point exception flags,
so use a local fp status for doing these calculations.
Signed-off-by: Peter Maydell
---
target-arm/helper.c | 12 ++--
1 files changed, 10 insert
On 05/19/2011 04:43 PM, Jan Kiszka wrote:
>
> I feel a lot less comfortable about it since it introduces more
> variables. It also means a full conversion is impossible.
>
> While doing it in one pass reduces the total effort, it increases the
> risk IMO.
If we are sure we can reasonably ev
On 2011-05-19 15:44, Anthony Liguori wrote:
> On 05/19/2011 04:10 AM, Avi Kivity wrote:
>> On 05/19/2011 12:08 PM, Gleb Natapov wrote:
>>> On Wed, May 18, 2011 at 06:42:14PM +0300, Avi Kivity wrote:
On 05/18/2011 06:36 PM, Jan Kiszka wrote:
>>
>> We need to head for the more hardware-l
On 05/19/2011 08:30 AM, Avi Kivity wrote:
On 05/19/2011 04:26 PM, Jan Kiszka wrote:
On 2011-05-19 15:07, Avi Kivity wrote:
And when introducing hierarchical registration, we will have to go
through all of this once again. Plus the API may have to be changed
again if it does not fulfill all re
On 05/19/2011 04:44 PM, Anthony Liguori wrote:
The i440fx may direct VGA accesses to RAM depending on the SMM
registers. By the time the PIIX gets the I/O request, we're past the
memory controller.
This is my biggest concern about this whole notion of "priority".
These sort of issues are
On 05/19/2011 08:47 AM, Jan Kiszka wrote:
On 2011-05-19 15:44, Anthony Liguori wrote:
Well..
The i440fx may direct VGA accesses to RAM depending on the SMM
registers. By the time the PIIX gets the I/O request, we're past the
memory controller.
This is my biggest concern about this whole n
On 05/19/2011 03:30 AM, Jan Kiszka wrote:
On 2011-05-19 10:26, Gleb Natapov wrote:
On Wed, May 18, 2011 at 09:27:55PM +0200, Jan Kiszka wrote:
if an I/O is to the APIC page,
it's handled by the APIC
That's not that simple. We need to tell apart:
- if a cpu issued the request, and which
On 05/19/2011 04:49 PM, Anthony Liguori wrote:
On 05/19/2011 08:30 AM, Avi Kivity wrote:
On 05/19/2011 04:26 PM, Jan Kiszka wrote:
On 2011-05-19 15:07, Avi Kivity wrote:
And when introducing hierarchical registration, we will have to go
through all of this once again. Plus the API may have t
Functions like ldl_be_p and ldl_le_p are currently used only as building
blocks for {ld,st}XX_p. As such, they are in cpu-all.h even though they
have absolutely no dependency on the target.
In order to make them globally available, this series moves them to
bswap.h instead.
An interesting part o
Most definitions in softfloat.h are really target-independent. Split
the few that stand out as target-dependent, to allow including
softfloat.h from files that are not compiled per-target.
Signed-off-by: Paolo Bonzini
---
fpu/softfloat-target.h | 119 +++
This is just code movement, and moving the fpu/ include path from
target-dependent to target-independent Make variables.
Signed-off-by: Paolo Bonzini
---
Makefile.hw |2 +-
bswap.h | 481 +++
configure |7 +-
cpu-all.h | 4
This is not a CPU interface.
Signed-off-by: Paolo Bonzini
---
cpu-common.h |4
qemu-common.h |4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/cpu-common.h b/cpu-common.h
index 151c32c..3a148b8 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -3,10 +3,6 @@
/
On 2011-05-19 15:50, Anthony Liguori wrote:
> On 05/19/2011 08:47 AM, Jan Kiszka wrote:
>> On 2011-05-19 15:44, Anthony Liguori wrote:
>>> Well..
>>>
>>> The i440fx may direct VGA accesses to RAM depending on the SMM
>>> registers. By the time the PIIX gets the I/O request, we're past the
>>>
On ARM the architecture mandates that when an output denormal is flushed to
zero we must set the FPSCR UFC (underflow) bit, so map softfloat's
float_flag_output_denormal accordingly.
Signed-off-by: Peter Maydell
---
target-arm/helper.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
This patch series fixes a number of minor bugs in the ARM target where
we were not correctly setting the cumulative exception flags in the
FPSCR. It includes adding a new flag to softfloat indicating when a
denormal result has been flushed to zero (as discussed previously on
the list.)
Tested with
The helpers for VRECPE.F32, VSQRTE.F32, VRECPS and VRSQRTS handle denormals
as special cases, so we must set the InputDenormal exception flag ourselves.
Signed-off-by: Peter Maydell
---
target-arm/helper.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/targe
On 05/19/2011 04:50 PM, Anthony Liguori wrote:
But the i440fx doesn't register the VGA region. The PIIX3 (ISA bus)
does, so how does it know what the priority of that mapping is?
The PCI bridge also has a say, no?
(and it would be a VGA region over memory, not the other way around).
--
e
On 2011-05-19 15:52, Anthony Liguori wrote:
> On 05/19/2011 03:30 AM, Jan Kiszka wrote:
>> On 2011-05-19 10:26, Gleb Natapov wrote:
>>> On Wed, May 18, 2011 at 09:27:55PM +0200, Jan Kiszka wrote:
> if an I/O is to the APIC page,
> it's handled by the APIC
That's not that simpl
Add a new float_flag_output_denormal which is set when the result
of a floating point operation would be denormal but is flushed to
zero because we are in flush_to_zero mode. This is necessary because
some architectures signal this condition as an underflow and others
signal it as an inexact result
The Neon versions of int-float conversions must use the "standard FPSCR"
rather than the default FPSCR. Implement this by having the helper
functions take a pointer to the appropriate float_status value rather
than simply taking a pointer to the entire CPUState, and making
translate.c pass a pointe
On 05/19/2011 04:52 PM, Anthony Liguori wrote:
So we have a second use case for CPU-local I/O regions?
I wonder if only a single CPU can enter SMM or if all have to.
For the i440fx, it's a chipset register (not a per-CPU register).
Maybe it's per-CPU on more modern chipsets... I'm not really
If the input to a Neon float comparison is a quiet NaN, the ARM ARM
specifies that we should raise InvalidOp if the comparison is GE or GT
but not for EQ. (Signaling NaNs raise InvalidOp regardless). This means
only EQ should use the _quiet version of the comparison function.
We implement this by
On 05/19/2011 03:44 AM, Avi Kivity wrote:
On 05/19/2011 11:30 AM, Jan Kiszka wrote:
>>
>> That's not that simple. We need to tell apart:
>> - if a cpu issued the request, and which one => forward to APIC
> And cpu mode may affect where access is forwarded to. If cpu is in SMM
> mode access to fr
On 05/19/2011 08:57 AM, Jan Kiszka wrote:
On 2011-05-19 15:52, Anthony Liguori wrote:
On 05/19/2011 03:30 AM, Jan Kiszka wrote:
On 2011-05-19 10:26, Gleb Natapov wrote:
On Wed, May 18, 2011 at 09:27:55PM +0200, Jan Kiszka wrote:
if an I/O is to the APIC page,
it's handled by the APIC
T
Amit Shah writes:
> On (Thu) 19 May 2011 [13:37:16], Markus Armbruster wrote:
>> diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
>> index bd3121e..a7d6b2b 100644
>> --- a/hw/virtio-serial-bus.c
>> +++ b/hw/virtio-serial-bus.c
>> @@ -642,6 +642,11 @@ static struct BusInfo virtser_bus_
On 2011-05-19 16:04, Anthony Liguori wrote:
> On 05/19/2011 08:57 AM, Jan Kiszka wrote:
>> On 2011-05-19 15:52, Anthony Liguori wrote:
>>> On 05/19/2011 03:30 AM, Jan Kiszka wrote:
On 2011-05-19 10:26, Gleb Natapov wrote:
> On Wed, May 18, 2011 at 09:27:55PM +0200, Jan Kiszka wrote:
>>
On (Thu) 19 May 2011 [16:05:39], Markus Armbruster wrote:
> Amit Shah writes:
>
> > On (Thu) 19 May 2011 [13:37:16], Markus Armbruster wrote:
> >> diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
> >> index bd3121e..a7d6b2b 100644
> >> --- a/hw/virtio-serial-bus.c
> >> +++ b/hw/virtio
Lluís writes:
> This patch defines the "disable" trace event state to always use the "nop"
> backend.
Ping.
--
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Jus
On 05/19/2011 05:04 PM, Anthony Liguori wrote:
Right, the chipset register is mainly used to program the contents of
SMM.
There is a single access pin that has effectively the same semantics
as setting the chipset register.
It's not a per-CPU setting--that's the point. You can't have one
The following patch includes a memory API proposal (without implementation).
Subject to review comments and endless discussions, my plans are to post
a v2 with an implementation and partial conversion, and v3 with full conversion
and elimination of cpu_register_physical_memory().
Avi Kivity (1):
The memory API separates the attributes of a memory region (its size, how
reads or writes are handled, dirty logging, and coalescing) from where it
is mapped and whether it is enabled. This allows a device to configure
a memory region once, then hand it off to its parent bus to map it according
to
On 05/19/2011 08:53 AM, Avi Kivity wrote:
On 05/19/2011 04:49 PM, Anthony Liguori wrote:
On 05/19/2011 08:30 AM, Avi Kivity wrote:
On 05/19/2011 04:26 PM, Jan Kiszka wrote:
On 2011-05-19 15:07, Avi Kivity wrote:
And when introducing hierarchical registration, we will have to go
through all
My mother always told me to explicitly #include any headers need to compile
a file, instead of relying on other #includes to bring them in. This patch
fixes up targphys.h and cpu-common.h in this regard.
Signed-off-by: Avi Kivity
---
cpu-common.h |4
targphys.h |2 ++
2 files cha
Amit Shah writes:
> On (Thu) 19 May 2011 [13:37:15], Markus Armbruster wrote:
>> Old version looks like this in info qtree (last four lines):
>>
>> dev: virtconsole, id ""
>> dev-prop: is_console = 1
>> dev-prop: nr = 0
>> dev-prop: chardev =
>>
On 2011-05-19 16:15, Anthony Liguori wrote:
> On 05/19/2011 08:53 AM, Avi Kivity wrote:
>> On 05/19/2011 04:49 PM, Anthony Liguori wrote:
>>> On 05/19/2011 08:30 AM, Avi Kivity wrote:
On 05/19/2011 04:26 PM, Jan Kiszka wrote:
> On 2011-05-19 15:07, Avi Kivity wrote:
>>>
> And when intr
On 05/19/2011 05:15 PM, Anthony Liguori wrote:
Except for priorities.
If you've got a hierarchy like:
- CPU:0
- i440fx:1
- PIIX3:2
- ISA:3
- DeviceA
- PCI:2
- DeviceB
In your model, the default priorities are as shown, but nothing stops
DeviceB from registering with a
On 05/18/2011 08:27 PM, Stefano Stabellini wrote:
On Wed, 18 May 2011, Stefan Weil wrote:
The current implementation used stubs for systems without XEN.
This is unusual for QEMU and adds unneeded dependencies.
MinGW32 for example does not provide munmap(), so the XEN
code creates compiler warni
Hello Stefan,
I couldn't find any error when I do consistency check on the image file...
What can be the reason for not starting the VM.
Here I am suspecting when the base server go for reboot lesser image will start
and it cached and larger image will take more time to create the cache...
Was
On (Thu) 19 May 2011 [16:18:29], Markus Armbruster wrote:
> Amit Shah writes:
>
> > On (Thu) 19 May 2011 [13:37:15], Markus Armbruster wrote:
> >> Old version looks like this in info qtree (last four lines):
> >>
> >> dev: virtconsole, id ""
> >> dev-prop: is_console = 1
>
On 05/19/2011 09:20 AM, Jan Kiszka wrote:
On 2011-05-19 16:15, Anthony Liguori wrote:
On 05/19/2011 08:53 AM, Avi Kivity wrote:
On 05/19/2011 04:49 PM, Anthony Liguori wrote:
On 05/19/2011 08:30 AM, Avi Kivity wrote:
On 05/19/2011 04:26 PM, Jan Kiszka wrote:
On 2011-05-19 15:07, Avi Kivity w
On Sun, May 08, 2011 at 10:29:07PM +0100, Stefan Hajnoczi wrote:
> The virtio_queue_notify() function checks that the virtqueue number is
> less than the maximum number of virtqueues. A signed comparison is used
> but the virtqueue number could be negative if a buggy or malicious guest
> is run.
On 2011-05-19 16:25, Anthony Liguori wrote:
> On 05/19/2011 09:20 AM, Jan Kiszka wrote:
>> On 2011-05-19 16:15, Anthony Liguori wrote:
>>> On 05/19/2011 08:53 AM, Avi Kivity wrote:
On 05/19/2011 04:49 PM, Anthony Liguori wrote:
> On 05/19/2011 08:30 AM, Avi Kivity wrote:
>> On 05/19/20
On 05/19/2011 05:28 PM, Jan Kiszka wrote:
>>
>> Priorities would be local, so the normal tree would look like this:
>>
>>- CPU:0
>> - i440fx:0
>>- PIIX3:0
>> - DeviceA
>>- PCI-DeviceB:0
>>
>> If the i440fx would like to map something different over DeviceA (or
On 05/19/2011 09:28 AM, Jan Kiszka wrote:
On 2011-05-19 16:25, Anthony Liguori wrote:
On 05/19/2011 09:20 AM, Jan Kiszka wrote:
On 2011-05-19 16:15, Anthony Liguori wrote:
Priorities would be local, so the normal tree would look like this:
- CPU:0
- i440fx:0
- PIIX3:0
-
On 05/19/2011 05:37 PM, Anthony Liguori wrote:
So do you do:
isa_register_region(ISABus *bus, MemoryRegion *mr, int priority)
{
chipset_register_region(bus->chipset, mr, priority + 1);
}
I don't really understand how you can fold everything into one table
and not allow devices to ove
On 19 May 2011 10:24, Edgar E. Iglesias wrote:
> On the CPU local aspect, I think it is increasingly common in the
> embedded space to see local busses with CPU local peripherals in
> addition to the "system" bus with "global" peripherals.
Yes: newer ARM cores have per-CPU builtin peripherals (ti
BM_STATUS_INT is automatically set during ide_set_irq(), there's no reason to
set it manually in addition.
There is even one case where the interrupt status bit was set, but no IRQ was
raised. This is when the PRD table was reached but there is more data to
transfer. The correct behaviour for this
On 05/19/2011 07:33 AM, Kevin Wolf wrote:
The following changes since commit 96d19bcbf5f679bbaaeab001b572c367fbfb2b03:
ahci: Unbreak bar registration (2011-05-16 10:15:47 -0500)
are available in the git repository at:
git://repo.or.cz/qemu/kevin.git for-anthony
Pulled. Thanks.
Regards
Remove a duplicate #include of sysbus.h.
Signed-off-by: Peter Maydell
---
hw/realview.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/hw/realview.c b/hw/realview.c
index 96fb9da..82f3d82 100644
--- a/hw/realview.c
+++ b/hw/realview.c
@@ -17,7 +17,6 @@
#include "sysemu
On 05/18/2011 10:37 PM, Stefan Hajnoczi wrote:
On Wed, May 18, 2011 at 7:42 PM, Venkateswararao Jujjuri
wrote:
On 05/18/2011 02:43 AM, Stefan Hajnoczi wrote:
On Tue, May 17, 2011 at 8:43 PM, Venkateswararao Jujjuri (JV)
wrote:
Signed-off-by: Venkateswararao Jujjuri "
---
Makefile.objs
On Thu, May 19, 2011 at 4:28 PM, Venkateswararao Jujjuri
wrote:
> On 05/18/2011 10:37 PM, Stefan Hajnoczi wrote:
>>
>> On Wed, May 18, 2011 at 7:42 PM, Venkateswararao Jujjuri
>> wrote:
>>>
>>> On 05/18/2011 02:43 AM, Stefan Hajnoczi wrote:
On Tue, May 17, 2011 at 8:43 PM, Venkateswara
On Thu, May 19, 2011 at 05:40:50PM +0300, Avi Kivity wrote:
> On 05/19/2011 05:37 PM, Anthony Liguori wrote:
> >
> >So do you do:
> >
> >isa_register_region(ISABus *bus, MemoryRegion *mr, int priority)
> >{
> >chipset_register_region(bus->chipset, mr, priority + 1);
> >}
> >
> >I don't rea
On 2011-05-19 18:17, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 05:40:50PM +0300, Avi Kivity wrote:
>> On 05/19/2011 05:37 PM, Anthony Liguori wrote:
>>>
>>> So do you do:
>>>
>>> isa_register_region(ISABus *bus, MemoryRegion *mr, int priority)
>>> {
>>>chipset_register_region(bus->chip
On Thu, May 19, 2011 at 05:40:50PM +0300, Avi Kivity wrote:
> On 05/19/2011 05:37 PM, Anthony Liguori wrote:
> >
> >So do you do:
> >
> >isa_register_region(ISABus *bus, MemoryRegion *mr, int priority)
> >{
> >chipset_register_region(bus->chipset, mr, priority + 1);
> >}
> >
> >I don't rea
On Thu, May 19, 2011 at 06:25:14PM +0200, Jan Kiszka wrote:
> On 2011-05-19 18:17, Gleb Natapov wrote:
> > On Thu, May 19, 2011 at 05:40:50PM +0300, Avi Kivity wrote:
> >> On 05/19/2011 05:37 PM, Anthony Liguori wrote:
> >>>
> >>> So do you do:
> >>>
> >>> isa_register_region(ISABus *bus, Memo
On 2011-05-19 18:28, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 06:25:14PM +0200, Jan Kiszka wrote:
>> On 2011-05-19 18:17, Gleb Natapov wrote:
>>> On Thu, May 19, 2011 at 05:40:50PM +0300, Avi Kivity wrote:
On 05/19/2011 05:37 PM, Anthony Liguori wrote:
>
> So do you do:
>
On 05/19/2011 09:40 AM, Avi Kivity wrote:
On 05/19/2011 05:37 PM, Anthony Liguori wrote:
So do you do:
isa_register_region(ISABus *bus, MemoryRegion *mr, int priority)
{
chipset_register_region(bus->chipset, mr, priority + 1);
}
I don't really understand how you can fold everything into o
On 2011-05-19 18:32, Anthony Liguori wrote:
> On 05/19/2011 09:40 AM, Avi Kivity wrote:
>> On 05/19/2011 05:37 PM, Anthony Liguori wrote:
>>>
>>> So do you do:
>>>
>>> isa_register_region(ISABus *bus, MemoryRegion *mr, int priority)
>>> {
>>> chipset_register_region(bus->chipset, mr, priority +
On 05/19/2011 11:30 AM, Jan Kiszka wrote:
On 2011-05-19 18:28, Gleb Natapov wrote:
On Thu, May 19, 2011 at 06:25:14PM +0200, Jan Kiszka wrote:
On 2011-05-19 18:17, Gleb Natapov wrote:
On Thu, May 19, 2011 at 05:40:50PM +0300, Avi Kivity wrote:
On 05/19/2011 05:37 PM, Anthony Liguori wrote:
On 05/19/2011 11:35 AM, Jan Kiszka wrote:
On 2011-05-19 18:32, Anthony Liguori wrote:
On 05/19/2011 09:40 AM, Avi Kivity wrote:
On 05/19/2011 05:37 PM, Anthony Liguori wrote:
So do you do:
isa_register_region(ISABus *bus, MemoryRegion *mr, int priority)
{
chipset_register_region(bus->chi
On Thu, May 19, 2011 at 06:30:42PM +0200, Jan Kiszka wrote:
> On 2011-05-19 18:28, Gleb Natapov wrote:
> > On Thu, May 19, 2011 at 06:25:14PM +0200, Jan Kiszka wrote:
> >> On 2011-05-19 18:17, Gleb Natapov wrote:
> >>> On Thu, May 19, 2011 at 05:40:50PM +0300, Avi Kivity wrote:
> On 05/19/2011
On 2011-05-19 18:36, Anthony Liguori wrote:
> On 05/19/2011 11:30 AM, Jan Kiszka wrote:
>> On 2011-05-19 18:28, Gleb Natapov wrote:
>>> On Thu, May 19, 2011 at 06:25:14PM +0200, Jan Kiszka wrote:
On 2011-05-19 18:17, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 05:40:50PM +0300, Avi Kivit
On 2011-05-19 18:38, Anthony Liguori wrote:
> On 05/19/2011 11:35 AM, Jan Kiszka wrote:
>> On 2011-05-19 18:32, Anthony Liguori wrote:
>>> On 05/19/2011 09:40 AM, Avi Kivity wrote:
On 05/19/2011 05:37 PM, Anthony Liguori wrote:
>
> So do you do:
>
> isa_register_region(ISAB
On 2011-05-19 18:43, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 06:30:42PM +0200, Jan Kiszka wrote:
>> On 2011-05-19 18:28, Gleb Natapov wrote:
>>> On Thu, May 19, 2011 at 06:25:14PM +0200, Jan Kiszka wrote:
On 2011-05-19 18:17, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 05:40:50PM +
 Currently host page cache setting for a block device cannot be changed
without restarting a running VM. Following patchset [V2] is for enabling
dynamic change of host cache setting for devices through qemu monitor.
Changes from patchset V1:
1. Support of dynamic cache change only for hostcac
Monitor commands "hostcache_set" and "hostcache_get" added for dynamic
host cache change and display of host cache setting respectively.
Signed-off-by: Supriya Kannery
---
block.c | 48
block.h |2 ++
blockdev.c | 48
New errors defined for device insertion and file reopen
Signed-off-by: Supriya Kannery
---
qerror.c |8
qerror.h |6 ++
2 files changed, 14 insertions(+)
Index: qemu/qerror.c
===
--- qemu.orig/qerror.c
+++ qem
On Thu, May 19, 2011 at 06:49:48PM +0200, Jan Kiszka wrote:
> On 2011-05-19 18:36, Anthony Liguori wrote:
> > On 05/19/2011 11:30 AM, Jan Kiszka wrote:
> >> On 2011-05-19 18:28, Gleb Natapov wrote:
> >>> On Thu, May 19, 2011 at 06:25:14PM +0200, Jan Kiszka wrote:
> On 2011-05-19 18:17, Gleb Na
On Wed, 18 May 2011, Paolo Bonzini wrote:
> On 05/18/2011 07:52 PM, stefano.stabell...@eu.citrix.com wrote:
> > From: Stefano Stabellini
> >
> > Introduce qemu_ram_ptr_length that takes an address and a size as
> > parameters rather than just an address.
> >
> > Refactor cpu_physical_memory_map so
On Thu, 19 May 2011, Alexander Graf wrote:
> On 05/18/2011 08:27 PM, Stefano Stabellini wrote:
> > On Wed, 18 May 2011, Stefan Weil wrote:
> >> The current implementation used stubs for systems without XEN.
> >> This is unusual for QEMU and adds unneeded dependencies.
> >>
> >> MinGW32 for example
Hi all,
this patch series introduces a series of fixes and improvements to the
xen mapcache in qemu.
Changes compared to v1:
- remove the two includes from xen-mapcache.h.
The list of patches with a diffstat follows:
Stefano Stabellini (5):
xen: fix qemu_map_cache with size != MCACHE_
From: Stefano Stabellini
There is no need for qemu_map_cache_unlock, just use
qemu_invalidate_entry instead.
Signed-off-by: Stefano Stabellini
---
exec.c |2 +-
xen-mapcache-stub.c |4
xen-mapcache.c | 33 -
xen-mapcache.h |
From: Stefano Stabellini
Fix the implementation of qemu_map_cache: correctly support size
arguments different from 0 or MCACHE_BUCKET_SIZE.
The new implementation supports locked mapcache entries with size
multiple of MCACHE_BUCKET_SIZE. qemu_invalidate_entry can correctly
find and unmap these "l
From: Stefano Stabellini
Replace xen_map_block with qemu_map_cache with the appropriate locking
and size parameters.
Replace xen_unmap_block with qemu_invalidate_entry.
Signed-off-by: Stefano Stabellini
---
exec.c | 19 ---
xen-mapcache-stub.c |4
xen-ma
From: Stefano Stabellini
Use qemu_invalidate_entry in cpu_physical_memory_unmap.
Do not lock mapcache entries in qemu_get_ram_ptr if the address falls in
the ramblock with offset == 0. We don't need to do that because the
callers of qemu_get_ram_ptr either try to map an entire block, other
from
From: Stefano Stabellini
Introduce qemu_ram_ptr_length that takes an address and a size as
parameters rather than just an address.
Refactor cpu_physical_memory_map so that we call qemu_ram_ptr_length only
once rather than calling qemu_get_ram_ptr one time per page.
This is not only more efficien
On Thu, May 19, 2011 at 03:37:58PM +0200, Jan Kiszka wrote:
> On 2011-05-19 15:36, Anthony Liguori wrote:
> > On 05/18/2011 02:40 PM, Jan Kiszka wrote:
> >> On 2011-05-18 15:12, Avi Kivity wrote:
> >>> void cpu_register_memory_region(MemoryRegion *mr, target_phys_addr_t
> >>> addr);
> >>
> >> OK, l
On 05/19/2011 12:39 PM, Gleb Natapov wrote:
On Thu, May 19, 2011 at 03:37:58PM +0200, Jan Kiszka wrote:
On 2011-05-19 15:36, Anthony Liguori wrote:
On 05/18/2011 02:40 PM, Jan Kiszka wrote:
On 2011-05-18 15:12, Avi Kivity wrote:
void cpu_register_memory_region(MemoryRegion *mr, target_phys_ad
On 05/19/2011 08:55 AM, Avi Kivity wrote:
On 05/19/2011 04:50 PM, Anthony Liguori wrote:
But the i440fx doesn't register the VGA region. The PIIX3 (ISA bus)
does, so how does it know what the priority of that mapping is?
The PCI bridge also has a say, no?
For legacy VGA memory? That's a g
On 2011-05-19 19:12, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 06:49:48PM +0200, Jan Kiszka wrote:
>> On 2011-05-19 18:36, Anthony Liguori wrote:
>>> On 05/19/2011 11:30 AM, Jan Kiszka wrote:
On 2011-05-19 18:28, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 06:25:14PM +0200, Jan Kiszk
On 2011-05-19 19:39, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 03:37:58PM +0200, Jan Kiszka wrote:
>> On 2011-05-19 15:36, Anthony Liguori wrote:
>>> On 05/18/2011 02:40 PM, Jan Kiszka wrote:
On 2011-05-18 15:12, Avi Kivity wrote:
> void cpu_register_memory_region(MemoryRegion *mr, tar
On 05/19/2011 09:11 AM, Avi Kivity wrote:
On 05/19/2011 05:04 PM, Anthony Liguori wrote:
Right, the chipset register is mainly used to program the contents of
SMM.
There is a single access pin that has effectively the same semantics
as setting the chipset register.
It's not a per-CPU setting-
On 2011-05-19 20:06, Anthony Liguori wrote:
> On 05/19/2011 08:55 AM, Avi Kivity wrote:
>> On 05/19/2011 04:50 PM, Anthony Liguori wrote:
>>>
>>> But the i440fx doesn't register the VGA region. The PIIX3 (ISA bus)
>>> does, so how does it know what the priority of that mapping is?
>>>
>>
>> The PCI
On Thu, May 19, 2011 at 08:11:39PM +0200, Jan Kiszka wrote:
> On 2011-05-19 19:39, Gleb Natapov wrote:
> > On Thu, May 19, 2011 at 03:37:58PM +0200, Jan Kiszka wrote:
> >> On 2011-05-19 15:36, Anthony Liguori wrote:
> >>> On 05/18/2011 02:40 PM, Jan Kiszka wrote:
> On 2011-05-18 15:12, Avi Kiv
On 2011-05-19 20:22, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 08:11:39PM +0200, Jan Kiszka wrote:
>> On 2011-05-19 19:39, Gleb Natapov wrote:
>>> On Thu, May 19, 2011 at 03:37:58PM +0200, Jan Kiszka wrote:
On 2011-05-19 15:36, Anthony Liguori wrote:
> On 05/18/2011 02:40 PM, Jan Kiszk
On Thu, May 19, 2011 at 01:03:01PM -0500, Anthony Liguori wrote:
> On 05/19/2011 12:39 PM, Gleb Natapov wrote:
> >On Thu, May 19, 2011 at 03:37:58PM +0200, Jan Kiszka wrote:
> >>On 2011-05-19 15:36, Anthony Liguori wrote:
> >>>On 05/18/2011 02:40 PM, Jan Kiszka wrote:
> On 2011-05-18 15:12, Avi
On 05/19/2011 01:28 PM, Gleb Natapov wrote:
On Thu, May 19, 2011 at 01:03:01PM -0500, Anthony Liguori wrote:
On 05/19/2011 12:39 PM, Gleb Natapov wrote:
With the exception of the few regions that the chipset treats
specially, RAM accesses don't get a chance to be intercepted by the
PCI bus.
Mo
On Thu, May 19, 2011 at 08:27:50PM +0200, Jan Kiszka wrote:
> On 2011-05-19 20:22, Gleb Natapov wrote:
> > On Thu, May 19, 2011 at 08:11:39PM +0200, Jan Kiszka wrote:
> >> On 2011-05-19 19:39, Gleb Natapov wrote:
> >>> On Thu, May 19, 2011 at 03:37:58PM +0200, Jan Kiszka wrote:
> On 2011-05-19
On 2011-05-19 20:40, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 08:27:50PM +0200, Jan Kiszka wrote:
>> On 2011-05-19 20:22, Gleb Natapov wrote:
>>> On Thu, May 19, 2011 at 08:11:39PM +0200, Jan Kiszka wrote:
On 2011-05-19 19:39, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 03:37:58PM +
On Thu, May 19, 2011 at 08:45:23PM +0200, Jan Kiszka wrote:
> On 2011-05-19 20:40, Gleb Natapov wrote:
> > On Thu, May 19, 2011 at 08:27:50PM +0200, Jan Kiszka wrote:
> >> On 2011-05-19 20:22, Gleb Natapov wrote:
> >>> On Thu, May 19, 2011 at 08:11:39PM +0200, Jan Kiszka wrote:
> On 2011-05-19
On 2011-05-19 20:18, Anthony Liguori wrote:
> On 05/19/2011 09:11 AM, Avi Kivity wrote:
>> On 05/19/2011 05:04 PM, Anthony Liguori wrote:
>>>
>>> Right, the chipset register is mainly used to program the contents of
>>> SMM.
>>>
>>> There is a single access pin that has effectively the same semanti
On 2011-05-19 20:50, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 08:45:23PM +0200, Jan Kiszka wrote:
>> On 2011-05-19 20:40, Gleb Natapov wrote:
>>> On Thu, May 19, 2011 at 08:27:50PM +0200, Jan Kiszka wrote:
On 2011-05-19 20:22, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 08:11:39PM +
On 05/19/2011 01:50 PM, Jan Kiszka wrote:
On 2011-05-19 20:18, Anthony Liguori wrote:
Well, not really.
kvm.ko has a global mapping of RAM regions and currently only allows
code execution from RAM.
This means the only way for QEMU to enable SMM support is to program the
global RAM regions tabl
On 2011-05-19 20:55, Jan Kiszka wrote:
> Alternatively, you could add a prio offset to all mappings when
> climbing one level up, provided that offset is smaller than the prio
> range locally available to each level.
Err, forget that, wrong analogy. It's more a round up after flattening
the view.
On Thu, May 19, 2011 at 3:24 PM, wrote:
> I couldn't find any error when I do consistency check on the image file...
Good, so there are no problems with your data.
> What can be the reason for not starting the VM.
Did you find any more error messages besides the sound related errors
in /var/lo
On Thu, 2011-05-19 at 10:12 -0400, Avi Kivity wrote:
> The memory API separates the attributes of a memory region (its size, how
> reads or writes are handled, dirty logging, and coalescing) from where it
> is mapped and whether it is enabled. This allows a device to configure
> a memory region on
On 2011-05-19 21:02, Anthony Liguori wrote:
> On 05/19/2011 01:50 PM, Jan Kiszka wrote:
>> On 2011-05-19 20:18, Anthony Liguori wrote:
>>> Well, not really.
>>>
>>> kvm.ko has a global mapping of RAM regions and currently only allows
>>> code execution from RAM.
>>>
>>> This means the only way for
On Thu, 19 May 2011, Ian Campbell wrote:
> On Wed, 2011-05-18 at 18:53 +0100, Stefano Stabellini wrote:
> > From: Stefano Stabellini
> >
> > Match the routing informations built by seabios:
> >
> > - remove i440fx_write_config_xen
> > we don't need to intercept pci config writes to i440FX;
> >
On Thu, 19 May 2011, Isaku Yamahata wrote:
> On Wed, May 18, 2011 at 06:53:40PM +0100, stefano.stabell...@eu.citrix.com
> wrote:
> > From: Stefano Stabellini
> >
> > Match the routing informations built by seabios:
> >
> > - remove i440fx_write_config_xen
> > we don't need to intercept pci conf
On 2011-05-19 16:12, Avi Kivity wrote:
> +/* Sets an offset to be added to MemoryRegionOps callbacks. */
> +void memory_region_set_offset(MemoryRegion *mr, target_phys_addr_t offset);
Please mark this as a legacy helper, ideally to be removed after the
complete conversion to this API. During that
101 - 200 of 221 matches
Mail list logo
