On Thu, Mar 7, 2013 at 2:26 AM, Peter Maydell peter.mayd...@linaro.org wrote:
On 7 March 2013 10:00, Peter Crosthwaite peter.crosthwa...@xilinx.com 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
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
On 7 March 2013 10:00, Peter Crosthwaite peter.crosthwa...@xilinx.com 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
On Mon, Mar 04, 2013 at 08:52:33PM +, Blue Swirl wrote:
On Mon, Mar 4, 2013 at 9:44 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Mar 03, 2013 at 09:01:11AM +, Blue Swirl wrote:
On Sun, Mar 3, 2013 at 6:13 AM, Peter Crosthwaite
peter.crosthwa...@xilinx.com wrote:
This
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, but then modeling
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 memory API.
Why
On Sun, Mar 03, 2013 at 09:01:11AM +, Blue Swirl wrote:
On Sun, Mar 3, 2013 at 6:13 AM, Peter Crosthwaite
peter.crosthwa...@xilinx.com 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
On Mon, Mar 4, 2013 at 1:37 AM, Peter Crosthwaite
peter.crosthwa...@xilinx.com 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
On Mon, Mar 4, 2013 at 9:44 AM, Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Mar 03, 2013 at 09:01:11AM +, Blue Swirl wrote:
On Sun, Mar 3, 2013 at 6:13 AM, Peter Crosthwaite
peter.crosthwa...@xilinx.com wrote:
This struct and functions provide some encapsulation of the uint32_t type
On Sun, Mar 3, 2013 at 6:13 AM, Peter Crosthwaite
peter.crosthwa...@xilinx.com 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
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.
+/**
+ * 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)
+ * @nw1:
Hi Gerd,
On Mon, Mar 4, 2013 at 4:55 PM, Gerd Hoffmann kra...@redhat.com 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.
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 has
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 are either
stuck
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
16 matches
Mail list logo
