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
12 matches
Mail list logo
