On Thu, Nov 22, 2012 at 11:21:58AM +0100, Paolo Bonzini wrote:
> Il 22/11/2012 09:19, Stefan Hajnoczi ha scritto:
> >> > usage
> >> > -
> >> > PCIEFW devices are instanciated using the following QEMU options:
> >> > -device \
> >> > pciefw,\
> >> > laddr=,\
> >> > lport=,\
> >> > raddr=,\
>
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
Il 22/11/2012 09:19, Stefan Hajnoczi ha scritto:
>> > usage
>> > -
>> > PCIEFW devices are instanciated using the following QEMU options:
>> > -device \
>> > pciefw,\
>> > laddr=,\
>> > lport=,\
>> > raddr=,\
>> > rport=
> Take a look at qemu_socket.h:socket_parse(). It should allow you t
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 using the following QEMU o
On Wed, Nov 21, 2012 at 03:27:48PM +0100, lementec fabien wrote:
> usage
> -
> PCIEFW devices are instanciated using the following QEMU options:
> -device \
> pciefw,\
> laddr=,\
> lport=,\
> raddr=,\
> rport=
Take a look at qemu_socket.h:socket_parse(). It should allow you to
support TC
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 provides a closed
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 group. Using QEMU
>> to emu
On Fri, Nov 16, 2012 at 09:39:07AM +0100, lementec fabien wrote:
> 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
> worki
Hi,
Thanks, it is actually a good idea to start with. I will write a spec
based on an improved version of what I have already implemented.
I think I will have some time this week, I will keep you updated soon.
Best regards,
Fabien.
2012/11/19 Stefan Hajnoczi :
> On Fri, Nov 16, 2012 at 02:05:29
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 provides a closed socket
> based interface to 'stimulate' the emulated device, at the PCIE level
> for instance. These envi
Hi,
Thanks for your reply.
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 instance. These environments are sometimes installed on cluster
On Fri, Nov 16, 2012 at 9:39 AM, lementec fabien
wrote:
> 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 FP
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
13 matches
Mail list logo
