similar to: lldb-mi functionality

Hi, > BTW: is there a tool (or pciutils patch) which can decode the virtio > capabilities? Searched for a patch today, and all google found me was this mail asking for one :-o So I went ahead and coded one up. Attached. While hacking it up I've noticed spec doesn't match reality. The "Virtio Structure PCI Capabilities" section here ...

Hi, > BTW: is there a tool (or pciutils patch) which can decode the virtio > capabilities? Searched for a patch today, and all google found me was this mail asking for one :-o So I went ahead and coded one up. Attached. While hacking it up I've noticed spec doesn't match reality. The "Virtio Structure PCI Capabilities" section here ...

virtio uses vendor-specific capabilities to specify the location of the virtio register ranges. The specification can be found here: http://docs.oasis-open.org/virtio/virtio/v1.0/cs01/virtio-v1.0-cs01.html#x1-690004 This patch adds support for decoding these capabilities to lspci. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- Makefile | 2 +- ls-caps-vendor.c | 59

virtio uses vendor-specific capabilities to specify the location of the virtio register ranges. The specification can be found here: http://docs.oasis-open.org/virtio/virtio/v1.0/cs01/virtio-v1.0-cs01.html#x1-690004 This patch adds support for decoding these capabilities to lspci. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- Makefile | 2 +- ls-caps-vendor.c | 59

Hi, > > While hacking it up I've noticed spec doesn't match reality. The > > "Virtio Structure PCI Capabilities" section here ... > > > > http://docs.oasis-open.org/virtio/virtio/v1.0/cs01/virtio-v1.0-cs01.html#x1-690004 > > > > ... doesn't match what qemu is doing. Huh? > > Thanks a lot for the report, and the tool! pciutils

Hi, > > While hacking it up I've noticed spec doesn't match reality. The > > "Virtio Structure PCI Capabilities" section here ... > > > > http://docs.oasis-open.org/virtio/virtio/v1.0/cs01/virtio-v1.0-cs01.html#x1-690004 > > > > ... doesn't match what qemu is doing. Huh? > > Thanks a lot for the report, and the tool! pciutils

On 09/05/2019 20:26, Halil Pasic wrote: > On Thu, 9 May 2019 14:01:01 +0200 > Pierre Morel <pmorel at linux.ibm.com> wrote: > >> On 08/05/2019 16:31, Pierre Morel wrote: >>> On 26/04/2019 20:32, Halil Pasic wrote: >>>> This will come in handy soon when we pull out the indicators from >>>> virtio_ccw_device to a memory area that is shared with

On 09/05/2019 20:26, Halil Pasic wrote: > On Thu, 9 May 2019 14:01:01 +0200 > Pierre Morel <pmorel at linux.ibm.com> wrote: > >> On 08/05/2019 16:31, Pierre Morel wrote: >>> On 26/04/2019 20:32, Halil Pasic wrote: >>>> This will come in handy soon when we pull out the indicators from >>>> virtio_ccw_device to a memory area that is shared with

virtio uses vendor-specific capabilities to specify the location of the virtio register ranges. The specification can be found here: http://docs.oasis-open.org/virtio/virtio/v1.0/cs01/virtio-v1.0-cs01.html#x1-690004 This patch adds support for decoding these capabilities to lspci. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- Makefile | 2 +- ls-caps-vendor.c | 76

virtio uses vendor-specific capabilities to specify the location of the virtio register ranges. The specification can be found here: http://docs.oasis-open.org/virtio/virtio/v1.0/cs01/virtio-v1.0-cs01.html#x1-690004 This patch adds support for decoding these capabilities to lspci. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- Makefile | 2 +- ls-caps-vendor.c | 76

From: Jiri Pirko <jiri at nvidia.com> Virtio spec introduced a feature VIRTIO_NET_F_GUEST_HDRLEN which when which when set implicates that device benefits from knowing the exact size of the header. For compatibility, to signal to the device that the header is reliable driver also needs to set this feature. Without this feature set by driver, device has to figure out the header size itself.

On 10/05/2019 13:54, Halil Pasic wrote: > On Fri, 10 May 2019 09:43:08 +0200 > Pierre Morel <pmorel at linux.ibm.com> wrote: > >> On 09/05/2019 20:26, Halil Pasic wrote: >>> On Thu, 9 May 2019 14:01:01 +0200 >>> Pierre Morel <pmorel at linux.ibm.com> wrote: >>> >>>> On 08/05/2019 16:31, Pierre Morel wrote: >>>>> On

On 10/05/2019 13:54, Halil Pasic wrote: > On Fri, 10 May 2019 09:43:08 +0200 > Pierre Morel <pmorel at linux.ibm.com> wrote: > >> On 09/05/2019 20:26, Halil Pasic wrote: >>> On Thu, 9 May 2019 14:01:01 +0200 >>> Pierre Morel <pmorel at linux.ibm.com> wrote: >>> >>>> On 08/05/2019 16:31, Pierre Morel wrote: >>>>> On

Nice to see great progress in this area! On Sun, Aug 12, 2018 at 2:49 PM, Александр Поляков via lldb-dev < lldb-dev at lists.llvm.org> wrote: > Hi LLVM folks, > > During this summer I was working on re-implementing of lldb-mi to > correctly use LLDB public API. You are welcome to read my final report > where I describe the contribution and challenges I faced with. > Link

Hi LLVM folks, During this summer I was working on re-implementing of lldb-mi to correctly use LLDB public API. You are welcome to read my final report where I describe the contribution and challenges I faced with. Link to final report: https://apolyakov.github.io/GSoC-2018/ -- Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL:

Can you please list the missing MI commands? This would be very valuable to both future contributors and also to the users of the LLDB MI. Thanks! On Mon, Aug 13, 2018 at 11:28 AM, Александр Поляков <polyakov.alx at gmail.com> wrote: > Thank you, Leonard, > I'm going to keep contributing to LLVM, so I think this is not the end! > > On Mon, Aug 13, 2018 at 8:15 PM Leonard

Hi, Reposting this message, because I never received a response. On the emacs-devel mailing list the question was raised to add support the emacs for lldb. Someone replied stating lldb does support MI, and emacs also support MI, so this should work out-of-the-box. So I took a moment to try it out. I started lldb like this: lldb-mi --interpreter=mi hello (btw, `hello` is written in swift)

On Tue, Mar 6, 2018 at 9:36 AM Daniel Berlin <dberlin at dberlin.org> wrote: > On Tue, Mar 6, 2018 at 9:28 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > >> >> >> On Tue, Mar 6, 2018 at 9:22 AM, David Blaikie <dblaikie at gmail.com> wrote: >> >>> >>> >>> On Tue, Mar 6, 2018 at 8:39 AM Daniel Berlin <dberlin at

On Tue, Mar 6, 2018 at 9:28 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Tue, Mar 6, 2018 at 9:22 AM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> On Tue, Mar 6, 2018 at 8:39 AM Daniel Berlin <dberlin at dberlin.org> wrote: >> >>> On Mon, Mar 5, 2018 at 11:55 PM, Roman Popov <ripopov at gmail.com> wrote:

On Mon, Jan 19, 2015 at 12:07:00PM +0100, Gerd Hoffmann wrote: > Hi, > > > BTW: is there a tool (or pciutils patch) which can decode the virtio > > capabilities? > > Searched for a patch today, and all google found me was this mail asking > for one :-o > > So I went ahead and coded one up. Attached. > > While hacking it up I've noticed spec