On 25/03/2015 12:43, Peter Maydell wrote:
> I was trying to avoid leaving us with yet another half-finished
> set of API transitions: because many of our CPUs are in this
> odd-fixes state, it's unlikely anybody will get round to
> updating them in the near future, so we'll be carrying a
> duplic
On 25 March 2015 at 11:34, Paolo Bonzini wrote:
>
>
> On 25/03/2015 00:41, Peter Maydell wrote:
>> On 24 March 2015 at 20:00, Paolo Bonzini wrote:
>>> I agree with that. I just want to keep ld/st*_phys _in addition_ as the
>>> short forms of address_space_ld/st*, and keep ld/st*_phys instead of
On 25/03/2015 00:41, Peter Maydell wrote:
> On 24 March 2015 at 20:00, Paolo Bonzini wrote:
>> I agree with that. I just want to keep ld/st*_phys _in addition_ as the
>> short forms of address_space_ld/st*, and keep ld/st*_phys instead of
>> address_space_ld/st* for those uses that have cs->as
On Mon, 23 Mar 2015 17:32:21 +0100
Andreas Färber wrote:
> Am 23.03.2015 um 16:11 schrieb Peter Maydell:
> > On 23 March 2015 at 14:39, Paolo Bonzini wrote:
> >> On 23/03/2015 13:24, Peter Maydell wrote:
> >>> * cpu_physical_memory_rw are obsolete and should be replaced
> >>>with uses of th
On 24 March 2015 at 20:00, Paolo Bonzini wrote:
> On 24/03/2015 19:06, Peter Maydell wrote:
>> I think this is where we disagree. I see ld/st*_phys as being
>> really generic -- they take an AddressSpace, after all, and
>> part of the same family with address_space_read &c. If you
>> don't leave t
On 24/03/2015 19:06, Peter Maydell wrote:
> On 24 March 2015 at 17:51, Paolo Bonzini wrote:
>> On 24/03/2015 17:35, Peter Maydell wrote:
>>> On 24 March 2015 at 16:23, Paolo Bonzini wrote:
> On 24 March 2015 at 15:08, Paolo Bonzini wrote:
, for those callers
of ld/st*_phys that u
On 24 March 2015 at 17:51, Paolo Bonzini wrote:
> On 24/03/2015 17:35, Peter Maydell wrote:
>> On 24 March 2015 at 16:23, Paolo Bonzini wrote:
On 24 March 2015 at 15:08, Paolo Bonzini wrote:
>>> , for those callers
>>> of ld/st*_phys that use cs->as as the first argument.
>>
>> ...but I don
On 24/03/2015 17:35, Peter Maydell wrote:
> On 24 March 2015 at 16:23, Paolo Bonzini wrote:
>>> On 24 March 2015 at 15:08, Paolo Bonzini wrote:
On 24/03/2015 15:53, Peter Maydell wrote:
>>> In any case, the removal or segregation of ld/st*_phys should be a
>>> separate series for e
On 24 March 2015 at 16:23, Paolo Bonzini wrote:
>> On 24 March 2015 at 15:08, Paolo Bonzini wrote:
>> > On 24/03/2015 15:53, Peter Maydell wrote:
>> >>> > In any case, the removal or segregation of ld/st*_phys should be a
>> >>> > separate series for ease of review.
>> >> Who wants to remove ld/s
> On 24 March 2015 at 15:08, Paolo Bonzini wrote:
> > On 24/03/2015 15:53, Peter Maydell wrote:
> >>> > In any case, the removal or segregation of ld/st*_phys should be a
> >>> > separate series for ease of review.
> >> Who wants to remove ld/st*_phys? Not me...
> >
> > Well, you want to rename th
On 24 March 2015 at 15:08, Paolo Bonzini wrote:
> On 24/03/2015 15:53, Peter Maydell wrote:
>>> > In any case, the removal or segregation of ld/st*_phys should be a
>>> > separate series for ease of review.
>> Who wants to remove ld/st*_phys? Not me...
>
> Well, you want to rename them _and_ add n
On 24/03/2015 15:53, Peter Maydell wrote:
>> > In any case, the removal or segregation of ld/st*_phys should be a
>> > separate series for ease of review.
> Who wants to remove ld/st*_phys? Not me...
Well, you want to rename them _and_ add new arguments. Basically at the
end they don't exist an
On 24 March 2015 at 14:45, Paolo Bonzini wrote:
> On 24/03/2015 14:47, Peter Maydell wrote:
>> On 23 March 2015 at 12:24, Peter Maydell wrote:
>> * no default-to-no-attrs/etc versions of ld/st*_ phys
>>(if in specific devices/buses it's the best thing we should
>>have bus-specific dma ac
On 24/03/2015 14:47, Peter Maydell wrote:
> On 23 March 2015 at 12:24, Peter Maydell wrote:
>> (This is part of the work I'm doing for transaction attributes.)
>
> OK, here's try 2, based on feedback on the first proposal:
>
> * address_space_rw &c remain with their current names, but
>ta
On 23 March 2015 at 12:24, Peter Maydell wrote:
> (This is part of the work I'm doing for transaction attributes.)
OK, here's try 2, based on feedback on the first proposal:
* address_space_rw &c remain with their current names, but
take an extra MemTxAttrs argument and return MemTxResult
On 23 March 2015 at 17:51, Andreas Färber wrote:
> Am 23.03.2015 um 15:39 schrieb Paolo Bonzini:
>> On 23/03/2015 13:24, Peter Maydell wrote:
>>> The point of indicating failure via MemTxResult is that at
>>> some point we need to correct the current broken handling of
>>> the CPUClass do_unassign
Am 23.03.2015 um 15:39 schrieb Paolo Bonzini:
> On 23/03/2015 13:24, Peter Maydell wrote:
>> The point of indicating failure via MemTxResult is that at
>> some point we need to correct the current broken handling of
>> the CPUClass do_unassigned_access hook, because that should
>> only be invoked i
On 23 March 2015 at 16:30, Paolo Bonzini wrote:
> None of them does, uses of ld*_phys(cs->as, ...) are almost all in
> target-* already.
Oh good :-)
Regardless, I don't see why this means that ld*_phys should be
in cpu-common.h or cpu-all.h rather than memory.h ?
> There's just hw/ppc/spapr_hca
Am 23.03.2015 um 16:11 schrieb Peter Maydell:
> On 23 March 2015 at 14:39, Paolo Bonzini wrote:
>> On 23/03/2015 13:24, Peter Maydell wrote:
>>> * cpu_physical_memory_rw are obsolete and should be replaced
>>>with uses of the as_* functions -- we should at least note
>>>this in the header
On 23/03/2015 17:00, Peter Maydell wrote:
> On 23 March 2015 at 15:47, Paolo Bonzini wrote:
>> Ok, so most ld*_phys users are already using cs->as.
>
> But this is only because when the AddressSpace* argument
> to ld*_phys was introduced we made it be cs->as for
> existing callers, to retain th
On 23 March 2015 at 15:47, Paolo Bonzini wrote:
> Ok, so most ld*_phys users are already using cs->as.
But this is only because when the AddressSpace* argument
to ld*_phys was introduced we made it be cs->as for
existing callers, to retain the existing behaviour.
That doesn't mean that callers us
On 23/03/2015 16:39, Peter Maydell wrote:
> > Not necessarily, for example PCI devices can certainly
> > use the short name.
>
> PCI devices should all be using ld*_pci_dma and st*_pci_dma
> so they go through the correct address space for the PCIDevice.
> Any PCI device making direct calls to ld
On 23 March 2015 at 15:27, Paolo Bonzini wrote:
>
>
> On 23/03/2015 16:26, Peter Maydell wrote:
>> > True. But since it's not a new API we can keep the old name for the
>> > simple one.
>>
>> ...except that means that the function you should in
>> general not be using as default is the one with t
On 23 March 2015 at 15:18, Paolo Bonzini wrote:
> On 23/03/2015 16:11, Peter Maydell wrote:
>> On 23 March 2015 at 14:39, Paolo Bonzini wrote:
>>> On 23/03/2015 13:24, Peter Maydell wrote:
* ld/st*_phys to be renamed to as_ld*, eg
ldub_phys -> as_ldub
ldl_be_phys -> as_ldl
On 23/03/2015 16:26, Peter Maydell wrote:
> > True. But since it's not a new API we can keep the old name for the
> > simple one.
>
> ...except that means that the function you should in
> general not be using as default is the one with the short
> name, which is the wrong way round. We should b
On 23/03/2015 16:11, Peter Maydell wrote:
> On 23 March 2015 at 14:39, Paolo Bonzini wrote:
>>
>>
>> On 23/03/2015 13:24, Peter Maydell wrote:
>>> (This is part of the work I'm doing for transaction attributes.)
>>>
>>> Currently we have several APIs used for making physical
>>> memory accesses:
On 23 March 2015 at 14:39, Paolo Bonzini wrote:
>
>
> On 23/03/2015 13:24, Peter Maydell wrote:
>> (This is part of the work I'm doing for transaction attributes.)
>>
>> Currently we have several APIs used for making physical
>> memory accesses:
>>
>> 1. cpu_physical_memory_rw &c
>>
>> 2. address_
On 23/03/2015 13:24, Peter Maydell wrote:
> (This is part of the work I'm doing for transaction attributes.)
>
> Currently we have several APIs used for making physical
> memory accesses:
>
> 1. cpu_physical_memory_rw &c
>
> 2. address_space_rw/read/write/map
>
> 3. ld/st*_phys
>
> These do
On 23 March 2015 at 12:30, Andreas Färber wrote:
> Am 23.03.2015 um 13:24 schrieb Peter Maydell:
>> * address_space_rw &c to be renamed:
>> address_space_rw -> as_rw_buf
>> address_space_read -> as_read_buf
>> address_space_write -> as_write_buf
>> address_space_map -> as_map_buf
Am 23.03.2015 um 13:24 schrieb Peter Maydell:
> * address_space_rw &c to be renamed:
> address_space_rw -> as_rw_buf
> address_space_read -> as_read_buf
> address_space_write -> as_write_buf
> address_space_map -> as_map_buf &c
>This is just so the names line up nicely and we h
On Mon, Oct 29, 2012 at 06:34:37PM +0200, Avi Kivity wrote:
> On 10/29/2012 01:37 AM, John Williams wrote:
>
> >> IMO, an mr per reg would just add a massive overhead for no win.
> >
> > I tend to agree with Edgar here - QEMU has a careful line to walk between
> > being an emulator and an RTL si
On 10/29/2012 01:37 AM, John Williams wrote:
>> IMO, an mr per reg would just add a massive overhead for no win.
>
> I tend to agree with Edgar here - QEMU has a careful line to walk between
> being an emulator and an RTL simulator.
>
> Any WAG on the runtime overhead of a mem region per regist
On 10/27/2012 06:12 AM, Edgar E. Iglesias wrote:
>
> Hi,
>
> If well designed, most hw has a well designed symtery between regs
> that makes things simpler if you can just opencode the decding.
> IMO, an mr per reg would just add a massive overhead for no win.
> And also, hw implemented decoders
> -Original Message-
> From: Edgar E. Iglesias [mailto:edgar.igles...@gmail.com]
> Sent: Saturday, 27 October 2012 2:12 PM
> To: Peter Crosthwaite
> Cc: qemu-devel@nongnu.org Developers; Avi Kivity; Peter Maydell; John
> Williams
> Subject: Re: [Qemu-devel] [RFC
On Fri, Oct 26, 2012 at 05:03:04PM +1000, Peter Crosthwaite wrote:
> In my recent USB series Avi mentioned he wanted to do some work with
> the memory API and encourage devices to use the memory API to do
> fine-grained register decoding, i.e. each register is its own
> MemoryRegion. This has the a
Hi,
> For actually writing into the device registers, its just uses an array
> index, no need to switch (ret = s->regs[addr]). However for my side
> effects I will need to populate that switch. If we convert to fine
> grained memory regions then the switch goes away and my side effect
> become p
Gleb Natapov wrote:
> On Sun, May 22, 2011 at 10:50:22AM +0300, Avi Kivity wrote:
> > On 05/20/2011 02:25 PM, Gleb Natapov wrote:
> > >>
> > >> A) Removing regions will change significantly. So far this is done by
> > >> setting a region to IO_MEM_UNASSIGNED, keeping truncation. With the new
> >
On Sun, May 22, 2011 at 02:29:27PM +0300, Avi Kivity wrote:
> On 05/22/2011 01:53 PM, Jan Kiszka wrote:
> >On 2011-05-22 10:41, Gleb Natapov wrote:
> >>> The chipset knows about the priorities. How to communicate them to
> >>> the core?
> >>>
> >>> - at runtime, with hierarchical dispatch of ->
On 05/22/2011 02:38 AM, Avi Kivity wrote:
On 05/20/2011 06:59 PM, Jan Kiszka wrote:
>
> Jan had mentioned previously about registering a new temporary window.
> I assume the registration always gets highest_priority++, or do you
have
> to explicitly specify that PCI container gets priority=1?
T
On 05/22/2011 11:59 AM, Gleb Natapov wrote:
> There is no problem. If the PCI bus priority is higher than RAM
> priority, then PCI BARs will override RAM.
>
So if memory region has no subregion that covers part of the region
lower prio region is used? Now the same with the pictures:
-- root
On 05/22/2011 01:53 PM, Jan Kiszka wrote:
On 2011-05-22 10:41, Gleb Natapov wrote:
>> The chipset knows about the priorities. How to communicate them to
>> the core?
>>
>> - at runtime, with hierarchical dispatch of ->read() and ->write():
>> slow, and doesn't work at all for RAM.
>> - usin
On 2011-05-22 10:41, Gleb Natapov wrote:
>> The chipset knows about the priorities. How to communicate them to
>> the core?
>>
>> - at runtime, with hierarchical dispatch of ->read() and ->write():
>> slow, and doesn't work at all for RAM.
>> - using registration order: fragile
>> - using prioriti
On Sun, May 22, 2011 at 11:09:08AM +0300, Avi Kivity wrote:
> On 05/22/2011 11:06 AM, Gleb Natapov wrote:
> >On Sun, May 22, 2011 at 10:37:48AM +0300, Avi Kivity wrote:
> >> On 05/20/2011 02:57 PM, Gleb Natapov wrote:
> >> >On Fri, May 20, 2011 at 11:59:58AM +0300, Avi Kivity wrote:
> >> >> On
On Sun, May 22, 2011 at 10:50:22AM +0300, Avi Kivity wrote:
> On 05/20/2011 02:25 PM, Gleb Natapov wrote:
> >>
> >> A) Removing regions will change significantly. So far this is done by
> >> setting a region to IO_MEM_UNASSIGNED, keeping truncation. With the new
> >> API that will be a true remo
On 05/22/2011 11:06 AM, Gleb Natapov wrote:
On Sun, May 22, 2011 at 10:37:48AM +0300, Avi Kivity wrote:
> On 05/20/2011 02:57 PM, Gleb Natapov wrote:
> >On Fri, May 20, 2011 at 11:59:58AM +0300, Avi Kivity wrote:
> >> On 05/19/2011 07:27 PM, Gleb Natapov wrote:
> >> >>Think of how a w
On Sun, May 22, 2011 at 10:37:48AM +0300, Avi Kivity wrote:
> On 05/20/2011 02:57 PM, Gleb Natapov wrote:
> >On Fri, May 20, 2011 at 11:59:58AM +0300, Avi Kivity wrote:
> >> On 05/19/2011 07:27 PM, Gleb Natapov wrote:
> >> >> Think of how a window manager folds windows with priorities onto a
>
On 05/20/2011 03:08 PM, Gleb Natapov wrote:
On Fri, May 20, 2011 at 12:10:22PM +0300, Avi Kivity wrote:
> On 05/19/2011 09:22 PM, Gleb Natapov wrote:
> >>
> >> BARs may overlap with other BARs or with RAM. That's well-known, so PCI
> >> bridged need to register their regions with the _ove
On 05/20/2011 02:25 PM, Gleb Natapov wrote:
>
> A) Removing regions will change significantly. So far this is done by
> setting a region to IO_MEM_UNASSIGNED, keeping truncation. With the new
> API that will be a true removal which will additionally restore hidden
> regions.
>
And what proble
On 05/20/2011 06:59 PM, Jan Kiszka wrote:
>
> Jan had mentioned previously about registering a new temporary window.
> I assume the registration always gets highest_priority++, or do you have
> to explicitly specify that PCI container gets priority=1?
The latter.
And I really prefer to have
On 05/20/2011 02:57 PM, Gleb Natapov wrote:
On Fri, May 20, 2011 at 11:59:58AM +0300, Avi Kivity wrote:
> On 05/19/2011 07:27 PM, Gleb Natapov wrote:
> >> Think of how a window manager folds windows with priorities onto a
> >> flat framebuffer.
> >>
> >> You do a depth-first walk of th
On 05/20/2011 05:51 PM, Anthony Liguori wrote:
Of course there is overlap. PCI BARs overlap each other, the VGA windows
and ROM overlap RAM.
Here's what I'm still struggling with:
If children normally overlap their parents, but child priorities are
always less than their parents, then what's
On 05/20/2011 08:30 PM, Blue Swirl wrote:
Another case would be the cache-as-ram mode for some x86 CPUs, which
Coreboot people would like to see IIRC.
That's probably best handled as a cache emulation layer, as this is not
associated with any specific address range.
--
I have a truly marvell
On 05/20/2011 11:43 AM, Olivier Galibert wrote:
On Fri, May 20, 2011 at 09:51:41AM -0500, Anthony Liguori wrote:
Is there a use-case for a priority above 1 and if so, what does it mean?
In a modern northbridge mmconfig has priority over external access,
and other internal registers (apic for i
On Thu, May 19, 2011 at 11: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
On Fri, May 20, 2011 at 09:51:41AM -0500, Anthony Liguori wrote:
> Is there a use-case for a priority above 1 and if so, what does it mean?
In a modern northbridge mmconfig has priority over external access,
and other internal registers (apic for instance) have priority over
mmconfig. Bios someti
On 2011-05-20 17:33, Anthony Liguori wrote:
> On 05/20/2011 04:01 AM, Avi Kivity wrote:
>> On 05/19/2011 07:32 PM, Anthony Liguori wrote:
Think of how a window manager folds windows with priorities onto a flat
framebuffer.
You do a depth-first walk of the tree. For each child li
On 05/20/2011 04:01 AM, Avi Kivity wrote:
On 05/19/2011 07:32 PM, Anthony Liguori wrote:
Think of how a window manager folds windows with priorities onto a flat
framebuffer.
You do a depth-first walk of the tree. For each child list, you iterate
it from the lowest to highest priority, allowing
On 05/20/2011 03:56 AM, Avi Kivity wrote:
On 05/19/2011 07:36 PM, Anthony Liguori wrote:
There are no global priorities. Priorities are only used inside each
level of the memory region hierarchy to generate a resulting, flattened
view for the next higher level. At that level, everything imported
On Fri, May 20, 2011 at 12:10:22PM +0300, Avi Kivity wrote:
> On 05/19/2011 09:22 PM, Gleb Natapov wrote:
> >>
> >> BARs may overlap with other BARs or with RAM. That's well-known, so PCI
> >> bridged need to register their regions with the _overlap variant
> >> unconditionally. In contrast to t
On Fri, May 20, 2011 at 11:59:58AM +0300, Avi Kivity wrote:
> On 05/19/2011 07:27 PM, Gleb Natapov wrote:
> >> Think of how a window manager folds windows with priorities onto a
> >> flat framebuffer.
> >>
> >> You do a depth-first walk of the tree. For each child list, you
> >> iterate it fro
On Fri, May 20, 2011 at 09:40:13AM +0200, Jan Kiszka wrote:
> On 2011-05-20 09:23, Gleb Natapov wrote:
> > On Thu, May 19, 2011 at 08:55:49PM +0200, Jan Kiszka wrote:
> >> Because we should catch accidental overlaps in all those non PCI
> >> devices
> >> with hard-wired addressing. Tha
On 05/19/2011 07:27 PM, Gleb Natapov wrote:
> Think of how a window manager folds windows with priorities onto a
> flat framebuffer.
>
> You do a depth-first walk of the tree. For each child list, you
> iterate it from the lowest to highest priority, allowing later
> subregions override ear
On 05/19/2011 09:18 PM, 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 semantics
as setting th
On 05/19/2011 09:22 PM, Gleb Natapov wrote:
>
> BARs may overlap with other BARs or with RAM. That's well-known, so PCI
> bridged need to register their regions with the _overlap variant
> unconditionally. In contrast to the current PhysPageDesc mechanism, the
With what priority?
It doesn't
On 05/19/2011 07:38 PM, Anthony Liguori wrote:
You can always create a new memory region with higher priority, pointing
to the RAM window you want to have above VGA. That's what we do today as
well, just with different effects on the internal representation.
But then we're no better than we ar
On 05/19/2011 07:32 PM, Anthony Liguori wrote:
Think of how a window manager folds windows with priorities onto a flat
framebuffer.
You do a depth-first walk of the tree. For each child list, you iterate
it from the lowest to highest priority, allowing later subregions
override earlier subregion
On 05/19/2011 07:49 PM, Jan Kiszka wrote:
>
> If you have overlapping BARs, the PCI bus will always send the request
> to a single device based on something that's implementation specific.
> This works because each PCI device advertises the BAR locations and
> sizes in it's config space.
Tha
On 05/19/2011 07:36 PM, Anthony Liguori wrote:
There are no global priorities. Priorities are only used inside each
level of the memory region hierarchy to generate a resulting, flattened
view for the next higher level. At that level, everything imported from
below has the default prio again, ie.
On 2011-05-20 09:23, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 08:55:49PM +0200, Jan Kiszka wrote:
>> Because we should catch accidental overlaps in all those non PCI devices
>> with hard-wired addressing. That's a bug in the device/machine model and
>> should be reported as such by
On Thu, May 19, 2011 at 08:55:49PM +0200, Jan Kiszka wrote:
> Because we should catch accidental overlaps in all those non PCI devices
> with hard-wired addressing. That's a bug in the device/machine model and
> should be reported as such by QEMU.
> >>> Why should we complicate API t
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 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 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: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 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 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: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: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 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 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 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 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: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 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 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 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 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 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 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 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 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 +
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: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 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 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 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 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 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: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 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
1 - 100 of 222 matches
Mail list logo
