On Thu, Mar 7, 2013 at 2:26 AM, Peter Maydell wrote:
> On 7 March 2013 10:00, Peter Crosthwaite wrote:
>> Not 100% accurate. My goal here it to control (or wrap) only guest
>> accesses, in the first instance via the Memory API, but other forms of
>> guest access are perfectly valid as well, and P
On 7 March 2013 10:00, Peter Crosthwaite wrote:
> Not 100% accurate. My goal here it to control (or wrap) only guest
> accesses, in the first instance via the Memory API, but other forms of
> guest access are perfectly valid as well, and PCI config space, would
> be a good example. If we are going
Hi All,
I have brought myself up to speed with this PCI stuff. First of all I
am assuming you are talking about the PCI Config space only? This
(hw/pci.h):
struct PCIDevice {
DeviceState qdev;
/* PCI config space */
uint8_t *config;
[snip]
/* Used to implement RW1C(Write 1 t
On Tue, Mar 05, 2013 at 03:17:13PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> We also need uint8_t, uint16_t and uint64_t versions for some devices.
> Perhaps it would be better to implement a uint64_t device which can be
> used with shorter widths or even stronger connection with memo
Hi,
We also need uint8_t, uint16_t and uint64_t versions for some devices.
Perhaps it would be better to implement a uint64_t device which can be
used with shorter widths or even stronger connection with memory API.
>>>
>>> Why not uint8_t for everyone?
>>
>> That would be simple,
On Mon, Mar 04, 2013 at 08:52:33PM +, Blue Swirl wrote:
> On Mon, Mar 4, 2013 at 9:44 AM, Michael S. Tsirkin wrote:
> > On Sun, Mar 03, 2013 at 09:01:11AM +, Blue Swirl wrote:
> >> On Sun, Mar 3, 2013 at 6:13 AM, Peter Crosthwaite
> >> wrote:
> >> > This struct and functions provide some
On Mon, Mar 4, 2013 at 9:44 AM, Michael S. Tsirkin wrote:
> On Sun, Mar 03, 2013 at 09:01:11AM +, Blue Swirl wrote:
>> On Sun, Mar 3, 2013 at 6:13 AM, Peter Crosthwaite
>> wrote:
>> > This struct and functions provide some encapsulation of the uint32_t type
>> > to
>> > make it more friendly
On Mon, Mar 4, 2013 at 1:37 AM, Peter Crosthwaite
wrote:
> Hi Blue,
>
> Thanks for the review. Comments in-line below. Are you on the IRC much
> and what timezone? I'd like to ask a few questions about how you see
> this fitting with the memory API, that would probably go much faster
> in live dis
On Sun, Mar 03, 2013 at 09:01:11AM +, Blue Swirl wrote:
> On Sun, Mar 3, 2013 at 6:13 AM, Peter Crosthwaite
> wrote:
> > This struct and functions provide some encapsulation of the uint32_t type to
> > make it more friendly for use as guest accessible device state. Bits of
> > device
> > stat
Hi,
>>> + * @nw0: bits that cant be written with a 0 by the guest (sticky 1)
>>> + * @nw1: bits that cant be written with a 1 by the guest (sticky 0)
>>
>> Why these?
>>
>> reset=0 + ro=1 equals nw1=1
>> reset=1 + ro=1 equals nw0=1
>>
>
> Some bits in my devices can only be written one-way they
Hi,
>> For maximum flexibility, a callback could be specified but then we
>> overlap memory API.
>
> I think this is a good idea, but continuing on the theme of what this
> API is trying to achieve I think there should be capability for
> per-bit function definitions. On the topic I think Gerd
Hi Gerd,
On Mon, Mar 4, 2013 at 4:55 PM, Gerd Hoffmann wrote:
>> +/**
>> + * A descriptor for a Uint32 that is part of guest accessible device state
>> + * @ro: whether or not the bit is read-only state comming out of reset
>> + * @w1c: bits with the common write 1 to clear semantic.
>
>> + * @nw
> +/**
> + * A descriptor for a Uint32 that is part of guest accessible device state
> + * @ro: whether or not the bit is read-only state comming out of reset
> + * @w1c: bits with the common write 1 to clear semantic.
> + * @nw0: bits that cant be written with a 0 by the guest (sticky 1)
> + * @n
Hi Blue,
Thanks for the review. Comments in-line below. Are you on the IRC much
and what timezone? I'd like to ask a few questions about how you see
this fitting with the memory API, that would probably go much faster
in live discussion. I've commented on the issue below with my current
thoughts.
On Sun, Mar 3, 2013 at 6:13 AM, Peter Crosthwaite
wrote:
> This struct and functions provide some encapsulation of the uint32_t type to
> make it more friendly for use as guest accessible device state. Bits of device
> state (usually MMIO registers), often have all sorts of access restrictions
> a
This struct and functions provide some encapsulation of the uint32_t type to
make it more friendly for use as guest accessible device state. Bits of device
state (usually MMIO registers), often have all sorts of access restrictions
and semantics associated with them. This struct allow you to define
16 matches
Mail list logo