Hello, everyone.
Was added missed "trace.h"
Best regards.
On Mon, Apr 22, 2024 at 5:17 PM Andrew Melnychenko wrote:
>
> There was an issue with Qemu build with "--disable-system".
> The traces could be generated and the build fails.
> The traces were 'cut out' for previous patches, and overall,
Hi all,
I've reviewed and checked - this patch is necessary!
Acked-by: and...@daynix.com
On Thu, Mar 28, 2024 at 11:39 AM Yuri Benditovich
wrote:
>
> Hi Andrew,
> Can you please check the indirection table copy and ack on the patch
> if the fix is correct
>
> Thanks,
> Yuri
>
> On Wed, Mar 27,
Hi all,
I've checked - apparently, qapi/ebpf.json should be added to
MAINTAINERS - I'll fix it.
On Fri, Mar 8, 2024 at 10:14 AM Jason Wang wrote:
>
> On Tue, Feb 6, 2024 at 12:55 AM Andrew Melnychenko wrote:
> >
> > Now, the binary objects may be retrieved by id.
> > It would require for future
Mon, Feb 26, 2024 at 6:23 PM Andrew Melnichenko
> > wrote:
> > >
> > > Hi all,
> > > Jason, can you please review the patch set, thank you.
> >
> > Queued.
> >
> > Thanks
>
> This seems to fail CI at:
>
> https://gitlab.com/jasowang/qemu/-/jobs/6348725269
>
> Please fix this.
>
> Thanks
>
Hi all,
Jason, can you please review the patch set, thank you.
On Mon, Feb 5, 2024 at 6:54 PM Andrew Melnychenko wrote:
>
> This series of patches provides the ability to retrieve eBPF program
> through qmp, so management application may load bpf blob with proper
> capabilities.
> Now,
Hi all,
I'll revert the license changes and leave SPDX ids only for new files.
On Tue, Jan 30, 2024 at 12:38 PM Daniel P. Berrangé wrote:
>
> On Thu, Jan 25, 2024 at 03:06:50PM +0200, Andrew Melnychenko wrote:
> > Changed eBPF map updates through mmaped array.
> > Mmaped arrays provide direct
Hi Jason,
According to our previous conversation, I've added checks to the meson script.
Please confirm that everything is correct.
On Thu, Aug 31, 2023 at 9:52 AM Andrew Melnychenko wrote:
>
> Updated section name, so libbpf should init/gues proper
> program type without specifications during
Hi all,
On Wed, Aug 16, 2023 at 4:16 AM Jason Wang wrote:
>
> On Mon, Aug 14, 2023 at 4:36 PM Andrew Melnichenko wrote:
> >
> > Hi, all.
> >
> > I've researched an issue a bit. And what can we do?
> > In the case of an "old" kernel 5.4, we ne
k,
If we really want to support eBPF on old kernels.
On Wed, Aug 9, 2023 at 5:21 AM Jason Wang wrote:
>
> On Wed, Aug 9, 2023 at 7:15 AM Andrew Melnichenko wrote:
> >
> > Hi all,
> >
> > On Tue, Aug 8, 2023 at 5:39 AM Jason Wang wrote:
> > >
> >
Hi all,
On Tue, Aug 8, 2023 at 5:39 AM Jason Wang wrote:
>
> On Thu, Aug 3, 2023 at 5:01 AM Andrew Melnychenko wrote:
> >
> > Changed eBPF map updates through mmaped array.
> > Mmaped arrays provide direct access to map data.
> > It should omit using bpf_map_update_elem() call,
> > which may
Hi all,
Thanks for the comments - I'll update and send new patches.
On Sat, Aug 5, 2023 at 10:34 AM Markus Armbruster wrote:
>
> Andrew Melnychenko writes:
>
> > Now, the binary objects may be retrieved by id.
> > It would require for future qmp commands that may require specific
> > eBPF blob.
Hi all,
On Fri, Jul 7, 2023 at 2:45 PM Markus Armbruster wrote:
>
> Andrew Melnychenko writes:
>
> > Added command "request-ebpf". This command returns
> > eBPF program encoded base64. The program taken from the
> > skeleton and essentially is an ELF object that can be
> > loaded in the future
Hi all,
Thank you for your comments. I'll check the error/warning.
On Fri, Jun 30, 2023 at 11:55 AM Daniel P. Berrangé wrote:
>
> On Fri, Jun 30, 2023 at 04:21:02PM +0800, Jason Wang wrote:
> > On Fri, Jun 30, 2023 at 4:04 PM Daniel P. Berrangé
> > wrote:
> > >
> > > On Fri, Jun 30, 2023 at
Hi all,
On Mon, May 15, 2023 at 12:38 PM Daniel P. Berrangé wrote:
>
> On Fri, May 12, 2023 at 03:28:59PM +0300, Andrew Melnychenko wrote:
> > eBPF RSS program and maps may now be passed during initialization.
> > Initially was implemented for libvirt to launch qemu without permissions,
> > and
Hi all,
Also, a possible solution for libvirt may look like this:
https://github.com/daynix/libvirt/tree/RSS_eBPF (WIP)
On Fri, May 12, 2023 at 3:47 PM Andrew Melnychenko wrote:
>
> This series of patches provides the ability to retrieve eBPF program
> through qmp, so management application may
Hi all,
On Wed, May 3, 2023 at 2:09 PM Daniel P. Berrangé wrote:
>
> On Mon, May 01, 2023 at 10:21:00AM +0300, Andrew Melnychenko wrote:
> > Added command "request-ebpf". This command returns
> > eBPF program encoded base64. The program taken from the
> > skeleton and essentially is an ELF
Hi all,
On Wed, May 3, 2023 at 2:07 PM Daniel P. Berrangé wrote:
>
> On Mon, May 01, 2023 at 10:20:57AM +0300, Andrew Melnychenko wrote:
> > Changed eBPF map updates through mmaped array.
> > Mmaped arrays provide direct access to map data.
> > It should omit using bpf_map_update_elem() call,
>
Hi all,
Thank you for your comments. I'll update it in the next patch version.
On Wed, May 3, 2023 at 2:03 PM Daniel P. Berrangé wrote:
>
> On Mon, May 01, 2023 at 10:20:58AM +0300, Andrew Melnychenko wrote:
> > eBPF RSS program and maps may now be passed during initialization.
> > Initially
Hi all,
On Wed, May 3, 2023 at 11:22 AM Daniel P. Berrangé wrote:
>
> On Mon, May 01, 2023 at 10:20:56AM +0300, Andrew Melnychenko wrote:
> > This series of patches provides the ability to retrieve eBPF program
> > through qmp, so management application may load bpf blob with proper
> >
Hi all,
Also, for those changes to have an effect, a new eBPF skeleton must be
generated.
On Fri, Apr 28, 2023 at 1:58 PM Andrew Melnichenko wrote:
>
> Hi all,
> I don't think that checking DF flag is a case for figuring out that
> the packet is a fragment of some
Hi all,
I don't think that checking DF flag is a case for figuring out that
the packet is a fragment of some big datagram.
For nonfragmented packets, DF may not be set.
We need to check that the fragment offset is 0.
Actually, it's a good idea to check that MF flag is not set too. So we
can find
Hi all,
On Thu, Mar 30, 2023 at 10:10 AM Daniel P. Berrangé wrote:
>
> On Thu, Mar 30, 2023 at 02:53:16PM +0800, Jason Wang wrote:
> > On Thu, Mar 30, 2023 at 8:33 AM Andrew Melnychenko
> > wrote:
> > >
> > > Changed eBPF map updates through mmaped array.
> > > Mmaped arrays provide direct
Hi all,
On Thu, Mar 30, 2023 at 11:33 AM Daniel P. Berrangé wrote:
>
> On Thu, Mar 30, 2023 at 03:15:20AM +0300, Andrew Melnychenko wrote:
> > Now, the binary objects may be retrieved by id/name.
> > It would require for future qmp commands that may require specific
> > eBPF blob.
> >
> >
On Thu, Mar 30, 2023 at 9:57 AM Jason Wang wrote:
>
> On Thu, Mar 30, 2023 at 8:33 AM Andrew Melnychenko wrote:
> >
> > This series of patches provides the ability to retrieve eBPF program
> > through qmp, so management application may load bpf blob with proper
> > capabilities.
> > Now,
Hi all,
On Thu, Mar 30, 2023 at 11:39 AM Daniel P. Berrangé wrote:
>
> On Thu, Mar 30, 2023 at 03:15:21AM +0300, Andrew Melnychenko wrote:
> > Added command "request-ebpf". This command returns
> > eBPF program encoded base64. The program taken from the
> > skeleton and essentially is an ELF
Hi all,
I've researched an issue a bit. The solution with passing eBPF blob
and loading in the Libvirt looks promising.
Overall, the possible solution looks like this:
* Libvirt checks virtio-net properties and understands that eBPF
steering may be required.
* Libvirt requests eBPF blob through
Hi,
On Mon, Feb 20, 2023 at 11:54 AM Daniel P. Berrangé wrote:
>
> On Sun, Feb 19, 2023 at 06:20:59PM +0200, Andrew Melnychenko wrote:
> > Helper program. Loads eBPF RSS program and maps and passes them through
> > unix socket.
> > Libvirt may launch this helper and pass eBPF fds to qemu
Hi all,
On Mon, Feb 20, 2023 at 11:50 AM Daniel P. Berrangé wrote:
>
> On Sun, Feb 19, 2023 at 06:20:58PM +0200, Andrew Melnychenko wrote:
> > Added a function to check the stamp in the helper.
> > eBPF helper should have a special symbol that generates during the build.
> > QEMU checks the
Hi, all.
In the future, there would be eBPF RSS + the helper for Libvirt interaction.
And those patches are required for future work. Technically they are
required for the current builds with linked libbpf 1.01.
Can we apply this patch?
On Wed, Dec 28, 2022 at 6:19 PM Andrew Melnichenko wrote
Hi, it's a good idea to update the skeleton generation. Technically
skeleton generation is not a part of Qemu building. The skeleton is
already presented in the Qemu tree, so we skip dependencies from
clang/bpftool.
It's a good idea to have an updated bpf program and simplified
Makefile with Qemu
Hi all,
Nice idea.
It would be great if future patches would add the BPF map support(if
uBPF allows it).
On Fri, Jun 17, 2022 at 10:51 AM Zhang Chen wrote:
>
> Hi All,
>
> The goal of this series is to bring the power of ebpf to QEMU.
> It makes QEMU have the ability to extend the
Hi all,
The ebpf/rss.bpf.skeleton.h is generetad by bpftool from tools/ebpf/rss.bpf.c.
To generate the skeleton - would require dependencies of llvm and bpftool.
RSS eBPF solution, for now, is only for Linux hosts.
> Andrew, want to post a patch to explain this?
I am all in for clarification. And
, Oct 21, 2021 at 5:16 AM Jason Wang wrote:
> Hi Andrew:
>
> On Thu, Oct 21, 2021 at 6:27 AM Andrew Melnichenko
> wrote:
> >
> > Hi,
> > I've used this manual(
> https://www.intel.com/content/dam/www/public/us/en/documents/manuals/pcie-gbe-controllers-open-source-m
Hi,
> Ther first two are bogus. /work/armbru/tmp/inst-qemu/... is where "make
> install" would put things. I last ran "make install" almost three
> months ago.
>
The stamp check is implemented only for the RSS helper. Qemu looks for a
helper first in HelpDir, then next to the binary.
Bridge/PR
Hi,
> I think it's for back-compatibility.
>
> E.g current codes works without mmap(), and user will surprise that it
> wont' work after upgrading their qemu.
>
Well, the current code would require additional capabilities with
"kernel.unprivileged_bpf_disabled=1", which may be possible on RedHat
Hi,
> Got something I could git-pull?
>
I can share some links for tests:
https://github.com/daynix/qemu/tree/HelperEBPFv3 - qemu with helper
https://github.com/daynix/libvirt/tree/RSS_RFC_v1 - libvirt with RSS
On Tue, Aug 31, 2021 at 6:00 PM Markus Armbruster wrote:
> Yuri Benditovich
Hi,
Yes, the stamp check was added.
So the qemu emulator should return a suitable RSS BPF helper or nothing.
Each qemu emulator may have a different helper that suits it.
So, the idea is to ask for the helper from qemu.
On Tue, Aug 24, 2021 at 9:41 AM Markus Armbruster wrote:
> And
Hi,
> I wonder if this can be done as helper for TAP/bridge.
>
Well, it does already, libvirt may create TAP device and pass it in command
line or using getfd qmp command.
E.g it's the qemu to launch those helper with set-uid.
>
Then libvirt won't even need to care about that?
Yea, we may think
Hi,
> I wonder if it's better to use separated properties instead of implying
> an order here?
>
Not really, technically RSS BPF interface may be changed (it's already
changed after RFC).
And libvirt should use something unified, so it's better to use fd array.
If any changes occur - those
Hi,
Yes - to make the bpf() syscall capabilities are required, which libvirt
have no intentions to give.
Does it make any sense to leave syscall if mmap works?
On Fri, Aug 20, 2021 at 6:34 AM Jason Wang wrote:
>
> 在 2021/7/13 下午11:37, Andrew Melnychenko 写道:
> > -static bool
Hi,
> The helper may or may not be installed at the path compiled into QEMU.
>
Yes, so the helper will not be called - QEMU will try to initiate eBPF RSS
or use "in-qemu" RSS.
What happens when you use the wrong helper?
>
UB - in most cases, eBPF program will work with wrong configurations.
ping
On Tue, Jul 13, 2021 at 6:38 PM Andrew Melnychenko
wrote:
> Libvirt usually launches qemu with strict permissions.
> To enable eBPF RSS steering, qemu-ebpf-rss-helper was added.
>
> Added property "ebpf_rss_fds" for "virtio-net" that allows to
> initialize eBPF RSS context with passed
QEMU_HELPER_STAMP) so the
helper should not be dependent on qemu module feature.
I think is more preferable to write ELF parser and also it should be more
secure(no .so constructors or launching unknown helper).
What do you think people?
On Wed, Jun 16, 2021 at 2:16 AM Andrew Melnichenko
wrote
rites:
> >>>>>
> >>>>>> 在 2021/6/22 上午11:29, Yuri Benditovich 写道:
> >>>>>>> On Mon, Jun 21, 2021 at 12:20 PM Jason Wang
> wrote:
> >>>>>>>> 在 2021/6/19 上午4:03, Andrew Melnichenko 写道:
> >>
; >> Jason Wang writes:
> >>
> >> > 在 2021/6/22 上午11:29, Yuri Benditovich 写道:
> >> >> On Mon, Jun 21, 2021 at 12:20 PM Jason Wang
> wrote:
> >> >>>
> >> >>> 在 2021/6/19 上午4:03, Andrew Melnichenko 写道:
>
Hi Jason,
I've checked "kernel.unprivileged_bpf_disabled=0" on Fedora, Ubuntu, and
Debian - no need permissions to update BPF maps.
On Wed, Jun 16, 2021 at 1:18 AM Andrew Melnichenko
wrote:
> Hi,
>
>> I may miss something.
>>
>> But RSS requires to update the
Hi all,
> Seems like this function is duplicating what glib should already be
> able to do.
>
Yea, but it's required a Linux specific header - without it, qemu builds
but crashes.
Could we use a compile-time determination of where we were (supposed)
> to be installed, and therefore where our
leged_bpf_disabled=1" - setting maps will fail(without
CAP_BPF) and "in-qemu" RSS will be used.
On Tue, Jun 15, 2021 at 12:13 PM Jason Wang wrote:
>
> 在 2021/6/12 上午12:49, Andrew Melnichenko 写道:
> > Hi,
> >
> > So I think the series is for unprivileged_bpf
Hi,
> So I think the series is for unprivileged_bpf disabled. If I'm not
> wrong, I guess the policy is to grant CAP_BPF but do fine grain checks
> via LSM.
>
The main idea is to run eBPF RSS with qemu without any permission.
Libvirt should handle everything and pass proper eBPF file
Hi,
I've checked the issue. Apparently, libbpf can't work with a skeleton on
Debian.
Version check would not help - versioning differs at different distros.
I've added a small check:
diff --git a/meson.build b/meson.build
> index ca551dd15d..4a51a25643 100644
> --- a/meson.build
> +++
The skeleton is generated file. Style issues with rss.bpf.c would be fixed
in upcoming patches.
On Thu, Mar 25, 2021 at 5:58 PM wrote:
> Patchew URL:
> https://patchew.org/QEMU/20210325153529.75831-1-and...@daynix.com/
>
>
>
> Hi,
>
> This series seems to have some coding style problems. See
Hi,
The issue is in LSC clearing. So, after "link up"(during initialization),
the next LSC event is masked and can't be processed.
Technically, the event should be 'cleared' during ICR read.
On Windows guest, everything works well, mostly because of different
interrupt routines(ICR clears during
Good point.
I'll add checks during initialization.
On Tue, Dec 8, 2020 at 8:37 PM Michael S. Tsirkin wrote:
> On Thu, Dec 03, 2020 at 01:07:13PM +0200, and...@daynix.com wrote:
> > From: Andrew
> >
> > Added AER capability for virtio-pci devices.
> > Also added property for devices, by
enditov...@daynix.com> wrote:
>
>
> On Sat, Nov 21, 2020 at 5:24 PM Yuri Benditovich <
> yuri.benditov...@daynix.com> wrote:
>
>>
>>
>> On Fri, Nov 20, 2020 at 2:58 PM Markus Armbruster
>> wrote:
>>
>>> Andrew Melnichenko writes:
&
Ping
On Thu, Jul 16, 2020 at 6:26 AM wrote:
> From: Andrew Melnychenko
>
> There is an issue, that netdev can't be removed if it was added using hmp.
> The bug appears after 08712fcb851034228b61f75bd922863a984a4f60 commit.
> It happens because of unclear QemuOpts that was created during
>
Ok,
Main motivation:
> According to Microsoft driver\device certification requirements for next
> version of Window Server, PCIe device must support AER.
> The exact quote of Microsoft certification requirements:
> "Windows Server PCI Express devices are required to support Advanced
> Error
yes
> DEFINE_PROP_BIT("aer", VirtIOPCIProxy, flags,
> VIRTIO_PCI_FLAG_AER_BIT, *false*),
>
On Mon, Oct 5, 2020 at 1:08 PM Michael S. Tsirkin wrote:
> On Mon, Oct 05, 2020 at 12:01:40PM +0300, and...@daynix.com wrote:
> > From: Andrew
> >
> > Buglink:
Hi,
Also, as far as I can tell, qemu doesn't support segmentation(if there is
no vheader) - performs fragmentation.
And also check
https://www.mail-archive.com/qemu-devel@nongnu.org/msg717496.html - there
was an issue with IPv6 CSO.
Those patches provide basic IPv6 fragmentation, for now, qemu
As I understand it, the e1000e.c was implemented by 82574L spec(
https://www.intel.com/content/dam/doc/datasheet/82574l-gbe-controller-datasheet.pdf
).
In the same spec there is 10.2.4 paragraph which provides more details when
ICR should be cleared.
> • Case 1 - Interrupt Mask register equals
>
> Please introduce a separate patch to do this.
Ok, I'll split the patch.
> Did you mean the headeroom might not be enough?
>
Technically, yes - extensions increase L3 header size. If there are a lot
of them, total packet len may be greater then MTU after adding
fragmentation extension. Qemu
driver(writing to ICR at interrupt
routine).
I've asked intel guys, does Linux driver works with a device(I don't have
real one). Thay said that it works and suggested to check 8257x spec. I'll
forward the message to you.
On Sat, May 9, 2020 at 9:02 AM Jason Wang wrote:
>
> On 2020/5/9 上
Yo, I've used OpenSDM_8257x-18.pdf specification.
This document was recommended by Intel guys(Also, they referenced to that
note).
I've made a fast fix and it works. Before that I had a fix for Linux e1000e
driver.
Overall, the issue was in pending interrupts that can't be cleared by
reading ICR
Ok, later - I'll prepare a new patch with length fix, segmentation and
checks.
For now, the current patch can be discarded.
On Fri, Apr 10, 2020 at 5:28 AM Jason Wang wrote:
>
> On 2020/4/9 下午9:35, Andrew Melnichenko wrote:
> > > Do we support ip
> Do we support ipv6 segmentation then?
No, but - if the backend supports big frames there is an issue that IPv6
plen doesn't have valid value.
Actually, It's a good idea to add IPv6 fragmentation - I would do it later.
On Thu, Apr 9, 2020 at 6:15 AM Jason Wang wrote:
>
> On 2020/4/6 上午3:19,
64 matches
Mail list logo
