Hi,
I modified the protocol so that new message types can be
added easily. It is necessary for control related messages,
such as the hello one (I called it init). A type field has
been added to the header.
I did not include a is_reply (or is_request) field, and
prefered having 2 distinct message
Hi,
Thanks for the feedback, I will modify the previous document
to include the changes you mentionned. I reply here too.
2012/11/22 Stefan Hajnoczi :
> On Wed, Nov 21, 2012 at 03:27:48PM +0100, lementec fabien wrote:
>> usage
>> -
>> PCIEFW devices are instanciated usi
I join you a doc describing the current small protocol implementation.
2012/11/19 Stefan Hajnoczi :
> On Fri, Nov 16, 2012 at 02:05:29PM +0100, lementec fabien wrote:
>> Actually, I wanted to be independant of the QEMU event loop. Plus,
>> some proprietary simulation environment pr
Hi,
As far as I know, all the PCIE devices implemented here
work with 256 bytes config header.
Cheers,
Fabien.
2012/11/20 Jason Baron :
> On Fri, Nov 16, 2012 at 09:39:07AM +0100, lementec fabien wrote:
>> Hi,
>>
>> I am a software engineer who works in an electronic gr
:05:29PM +0100, lementec fabien wrote:
>> Actually, I wanted to be independant of the QEMU event loop. Plus,
>> some proprietary simulation environment provides a closed socket
>> based interface to 'stimulate' the emulated device, at the PCIE level
>> for insta
opted for the socket based approach. Now that it is working,
I can take time to reconsider stuffs according to others need, and ideally
an integration to QEMU.
Fabien.
2012/11/16 Stefan Hajnoczi :
> On Fri, Nov 16, 2012 at 9:39 AM, lementec fabien
> wrote:
>> I am a software en
Hi,
I am a software engineer who works in an electronic group. Using QEMU
to emulate devices allows me to start writing and testing LINUX software
before the device is actually available. In the group, we are mostly
working with XILINX FPGAs, communicating with the host via PCIE. The
devices are i
