On Wed, Nov 29, 2017 at 3:51 PM, Maxime Coquelin
wrote:
>
>
> On 11/29/2017 03:04 PM, Ladi Prosek wrote:
>>
>> On Wed, Nov 29, 2017 at 2:36 PM, Maxime Coquelin
>> wrote:
>>>
>>>
>>>
>>> On 11/29/2017 02:31 PM, Ladi Prosek wrote:
On Wed, Nov 29, 2017 at 2:36 PM, Maxime Coquelin
wrote:
>
>
> On 11/29/2017 02:31 PM, Ladi Prosek wrote:
>>
>> On Wed, Nov 29, 2017 at 2:06 PM, Maxime Coquelin
>> wrote:
>>>
>>>
>>>
>>> On 11/29/2017 11:42 AM, Ladi Prosek wrote:
On Wed, Nov 29, 2017 at 2:06 PM, Maxime Coquelin
wrote:
>
>
> On 11/29/2017 11:42 AM, Ladi Prosek wrote:
>>
>> On Wed, Nov 29, 2017 at 9:57 AM, Maxime Coquelin
>> wrote:
>>>
>>> Hi Ladi,
>>>
>>> Sorry for the late reply.
>>>
On Wed, Nov 29, 2017 at 9:57 AM, Maxime Coquelin
wrote:
> Hi Ladi,
>
> Sorry for the late reply.
>
> On 11/27/2017 05:01 PM, Ladi Prosek wrote:
>>
>> I think I understand what's going on. DPDK simply won't consider the
>> interface 'ready' unt
gt; Thanks,
> Zoltan
>
> On 11/24/2017 04:01 PM, Ladi Prosek wrote:
>
> On Wed, Nov 22, 2017 at 8:10 PM, Ladi Prosek wrote:
>
> Indeed, "VIRTIO-NET %p tx complete iobuf %p\n" would be printed if the
> TX packets were processed.
>
> I'll try to set up a
On Wed, Nov 22, 2017 at 8:10 PM, Ladi Prosek wrote:
> Indeed, "VIRTIO-NET %p tx complete iobuf %p\n" would be printed if the
> TX packets were processed.
>
> I'll try to set up a local repro to investigate.
Quick update: I was able to set up OVS with DPDK and see th
; The main problem is not with incoming DHCP Replies, but that DHCP Request
> packets cannot be sent out from the VM by the iPXE image: TX errors present.
> And I can see this also when using ovs-tcpdump on the vhost-user socket:
> nothing comes out from the VM trying to pxe boot.
>
> BR,
>
addr=0x7
> -chardev
> file,id=charserial0,path=/var/lib/nova/instances/40f79f06-fd66-47f1-a952-cb1366117c15/console.log
> -device isa-serial,chardev=charserial0,id=serial0 -chardev
> pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device
> usb-tablet
Hi,
On Mon, Nov 13, 2017 at 8:33 AM, Rafael Gellert
wrote:
> Hi,
>
> Could you please help me resolve this issue:
> http://forum.ipxe.org/showthread.php?tid=10521
Can you please post the QEMU command line with and without the
problematic hw_vif_multiqueue_enabled="true" option. Also QEMU version
In fully self-contained deployments it may be desirable to build iPXE
with an empty CROSSCERT source to avoid talking to external services.
This commit adds an explicit check for such a case and makes
validator_start_download fail immediately if the base URI is empty.
Signed-off-by: Ladi Prosek
may execute the 'set trust ...' command to set
the list of trusted root certificates. This can be done only once,
subsequent attempts to set the 'trust' variable will have no effect.
Signed-off-by: Ladi Prosek
---
src/crypto/rootcert.c | 55 ++
This is a simplified version of the series discussed back in March:
http://lists.ipxe.org/pipermail/ipxe-devel/2017-March/005475.html
Instead of allowing only trusted scripts to set the root cert, this
version's only restriction is that the root of trust can be set at
most once, as suggested in:
h
On Fri, Sep 8, 2017 at 2:00 PM, Ladi Prosek wrote:
> Analogous to passing a script to ipxe.lkrn via kernel parameters, this
> patch enables the same on EFI using the EFI command line, available in
> the LoadOptions field of EFI_LOADED_IMAGE_PROTOCOL.
>
> Signed-off-by: Ladi Pros
Analogous to passing a script to ipxe.lkrn via kernel parameters, this
patch enables the same on EFI using the EFI command line, available in
the LoadOptions field of EFI_LOADED_IMAGE_PROTOCOL.
Signed-off-by: Ladi Prosek
---
src/interface/efi/efi_init.c | 92
On Fri, Mar 3, 2017 at 5:20 PM, Ladi Prosek wrote:
> On Fri, Mar 3, 2017 at 2:39 PM, Michael Brown wrote:
>> On 03/03/17 12:37, Ladi Prosek wrote:
>>>
>>> The goal of this series is to make it possible to use iPXE with security
>>> features, such as HTT
> On 18 May 2017 11:41, "Ladi Prosek" wrote:
>>
>> On Sun, Dec 11, 2016 at 2:10 AM, Christian Nilsson
>> wrote:
>> > cmdline part is copied over from pcbios functionallity
>> >
>> > Signed-off-by: Christian Nilsson
>> > ---
>
On Sun, Dec 11, 2016 at 2:10 AM, Christian Nilsson wrote:
> cmdline part is copied over from pcbios functionallity
>
> Signed-off-by: Christian Nilsson
> ---
> src/config/config_efi.c | 2 +
> src/include/ipxe/errfile.h | 1 +
> src/interface/efi/efi_runtime.c | 177
> +
On Fri, Mar 3, 2017 at 2:39 PM, Michael Brown wrote:
> On 03/03/17 12:37, Ladi Prosek wrote:
>>
>> The goal of this series is to make it possible to use iPXE with security
>> features, such as HTTPS, in enterprise environments where rebuilding
>> from sources is not
in build-time config, independently of TRUSTED.
Signed-off-by: Ladi Prosek
---
src/crypto/rootcert.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/crypto/rootcert.c b/src/crypto/rootcert.c
index 40a5271..b1af2ab 100644
--- a/src/crypto/rootcert.c
+++ b/src/crypto/rootcert.c
@@ -32,6
allowed to execute the 'set trust ...' command.
This commit adds a settings applicator which updates the root_certificates
global variable only in response to an explicit update of the 'trust'
setting and only when executing a trusted image.
Signed-off-by: Ladi Prosek
-
settings may have been updated.
Signed-off-by: Ladi Prosek
---
src/core/settings.c | 10 +-
src/crypto/certstore.c | 2 +-
src/crypto/privkey.c| 2 +-
src/include/ipxe/settings.h | 3 ++-
src/net/80211/net80211.c| 4 ++--
src/net/ipv4.c | 2 +-
src
makes initrd, kernel command line, and images embedded in
the iPXE binary trusted in terms of the IMAGE_TRUSTED flag.
Signed-off-by: Ladi Prosek
---
src/arch/x86/core/runtime.c | 4
src/image/embedded.c| 1 +
2 files changed, 5 insertions(+)
diff --git a/src/arch/x86/core/runtime.c
In fully self-contained deployments it may be desirable to build iPXE
with an empty CROSSCERT source to avoid talking to external services.
This commit adds an explicit check for such a case and makes
validator_start_download fail immediately if the base URI is empty.
Signed-off-by: Ladi Prosek
Resending the series from last year. Still wanting to do it, still
looking for feedback.
The goal of this series is to make it possible to use iPXE with security
features, such as HTTPS, in enterprise environments where rebuilding
from sources is not an option and connecting to external services
Thank you!
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/61#issuecomment-274336417___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailma
Friendly ping.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/61#issuecomment-272869711___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https
Three patches discussed and reviewed on the ipxe-devel list. Fixes issues with
virtqueue sizes >256. To reproduce, run QEMU with:
-device virtio-net, ..., disable-modern=off,disable-legacy=on,rx_queue_size=1024
for modern virtio and
-device virtio-net, ..., disable-modern=on,disable-legacy=off,
On Mon, Dec 19, 2016 at 5:49 PM, Gerd Hoffmann wrote:
> On Mo, 2016-12-19 at 17:03 +0100, Ladi Prosek wrote:
>> On Mon, Dec 19, 2016 at 3:54 PM, Stefan Hajnoczi wrote:
>> > On Fri, Dec 16, 2016 at 03:30:03PM +0100, Ladi Prosek wrote:
>> >> QEMU properly reverts que
would help, but no joy there either.
At this point we should engage somebody from Google to help us understand
why the host behaves this way, i.e. why it doesn't let us use the device in
"simple" mode with nothing but VIRTIO_NET_F_MAC.
Thanks,
Ladi
> 2016-12-20
ets for transmission. I'm not sure what guest driver
issue would explain this behavior :(
Could you please help me set up a GCE instance with iPXE? I haven't been
able to make it produce any output. Do you build iPXE with CONSOLE_SERIAL?
How do you create the .tar.gz for GCE to import the i
On Mon, Dec 19, 2016 at 3:54 PM, Stefan Hajnoczi wrote:
> On Fri, Dec 16, 2016 at 03:30:03PM +0100, Ladi Prosek wrote:
>> QEMU properly reverts queue_enable to 0 on device reset as of:
>>
>> commit 75fd6f13af8513f1e14add754549141e415f8704
>> Author: Gerd Hoffmann
t; 1620882783, win 28160, options [mss 1420,sackOK,TS val 77069390 ecr
> 323011,nop,wscale 7], length 0
Thanks for the logs. Can you please try the following patch? It's a
crazy workaround to reinitialize the driver on each transmitted
packet. If it works, we'll go from there and try s
QEMU properly reverts queue_enable to 0 on device reset as of:
commit 75fd6f13af8513f1e14add754549141e415f8704
Author: Gerd Hoffmann
Date: Thu Jan 28 16:08:07 2016 +0100
virtio-pci: call pci reset variant when guest requests reset.
Signed-off-by: Ladi Prosek
---
src/drivers/bus
This commit introduces virtnet_free_virtqueues called on all virtqueue
error and shutdown paths. vpm_find_vqs no longer cleans up after itself
and instead expects virtnet_free_virtqueues to be always called to undo
its effect.
Signed-off-by: Ladi Prosek
---
src/drivers/bus/virtio-pci.c | 9
. Note that virtio
1.0 still uses the MAX_QUEUE_NUM constant to cap the size (unfortunately
this functionality is not available in virtio 0.9).
Signed-off-by: Ladi Prosek
---
src/drivers/bus/virtio-pci.c | 48 ++
src/drivers/net/virtio-net.c | 1 +
src
This series was prompted by the issue reported in:
http://lists.ipxe.org/pipermail/ipxe-devel/2016-December/005317.html
As it turns out, neither legacy nor modern iPXE virtio implementation
currently works well with queue sizes >256.
In patch 1, modern virtio is fixed to correctly negotiate the q
ring.num assignment which is already
handled in vring_init.
Signed-off-by: Ladi Prosek
---
src/drivers/bus/virtio-pci.c | 8 +++-
src/include/ipxe/virtio-ring.h | 6 +++---
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/drivers/bus/virtio-pci.c b/src/drivers/bus/virt
Hi Akihiro,
On Wed, Dec 14, 2016 at 8:51 AM, Akihiro Suda wrote:
> Hi Christian,
>
> Thank you for the suggestion, I'll try to report this to google.
>
> I found that the cause of this issue is because GCE's VIRTIO_PCI_QUEUE_NUM
> is 4096, which is larger than iPXE's MAX_QUEUE_NUM (256).
>
> http
On Wed, Nov 16, 2016 at 2:21 AM, Dan Callaghan wrote:
> iPXE is already assuming a conservative MTU in the TCP transmission code
> path (tcp_xmit_win() is using TCP_PATH_MTU, which is calculated assuming
> a network-layer MTU of 1280).
>
> However, MTU is also used to determine the TCP Maximum Seg
On Mon, Jul 11, 2016 at 7:02 PM, Ladi Prosek wrote:
> iPXE was unable to receive priority tagged packets specified in
> the 802.1Q standard and supported by all major networking stacks.
>
> This commit adds a new function net_pull_tags which is called by
> all consumers of incomin
The goal of this series is to make it possible to use iPXE with security
features, such as HTTPS, in enterprise environments where rebuilding
from sources is not an option and connecting to external services is not
desired. An ideal iPXE binary for this environment:
1) Does not use any cross-cert
in build-time config, independently of TRUSTED.
Signed-off-by: Ladi Prosek
---
src/crypto/rootcert.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/crypto/rootcert.c b/src/crypto/rootcert.c
index 40a5271..b1af2ab 100644
--- a/src/crypto/rootcert.c
+++ b/src/crypto/rootcert.c
@@ -32,6
allowed to execute the 'set trust ...' command.
This commit adds a settings applicator which updates the root_certificates
global variable only in response to an explicit update of the 'trust'
setting and only when executing a trusted image.
Signed-off-by: Ladi Prosek
-
settings may have been updated.
Signed-off-by: Ladi Prosek
---
src/core/settings.c | 10 +-
src/crypto/certstore.c | 2 +-
src/crypto/privkey.c| 2 +-
src/include/ipxe/settings.h | 3 ++-
src/net/80211/net80211.c| 4 ++--
src/net/ipv4.c | 2 +-
src
makes initrd, kernel command line, and images embedded in
the iPXE binary trusted in terms of the IMAGE_TRUSTED flag.
Signed-off-by: Ladi Prosek
---
src/arch/x86/core/runtime.c | 4
src/image/embedded.c| 1 +
2 files changed, 5 insertions(+)
diff --git a/src/arch/x86/core/runtime.c
In fully self-contained deployments it may be desirable to build iPXE
with an empty CROSSCERT source to avoid talking to external services.
This commit adds an explicit check for such a case and makes
validator_start_download fail immediately if the base URI is empty.
Signed-off-by: Ladi Prosek
iPXE was unable to receive priority tagged packets specified in
the 802.1Q standard and supported by all major networking stacks.
This commit adds a new function net_pull_tags which is called by
all consumers of incoming packets after stripping their link-layer
headers.
Signed-off-by: Ladi
oment iPXE does not follow this pattern. It doesn't run into a
> conflict when it installs its EFI_HII_CONFIG_ACCESS_PROTOCOL directly on
> the SNP handle, but that's only because iPXE is the sole driver not
> following the pattern. This behavior seems risky (one might call it a
> "la
I'm fine with dropping this if @marcel-apf doesn't object.
---
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/55#issuecomment-227187705___
ipxe-devel mailing list
ipxe-de
Thanks - virtio devices may be configured to expose both I/O and memory BARs,
with either type being enough to drive the device. It is basically a
back-compat setup where older drivers can still use I/O ports and newer may
choose to use the so called "modern" interface.
We would like to avoid e
On Mon, Jun 13, 2016 at 12:27 PM, Ladi Prosek wrote:
> On Mon, Jun 13, 2016 at 11:04 AM, Michael Brown wrote:
>> On 13/06/16 08:33, Ladi Prosek wrote:
>>>>
>>>> Could you try out
>>>>
>>>>
>>>> http://git.ipxe.org/people/mcb3
On Mon, Jun 13, 2016 at 11:04 AM, Michael Brown wrote:
> On 13/06/16 08:33, Ladi Prosek wrote:
>>>
>>> Could you try out
>>>
>>>
>>> http://git.ipxe.org/people/mcb30/ipxe.git/shortlog/refs/heads/keepalive
>>>
>>> and let me know i
On Fri, Jun 10, 2016 at 6:41 PM, Michael Brown wrote:
> On 09/06/16 15:12, Ladi Prosek wrote:
>>
>> NAT losing state is definitely one plausible case. Another could be
>> some kind of a multi-path setup where failover has just happened and
>> the new path is unaw
On Thu, Jun 9, 2016 at 3:11 PM, Michael Brown wrote:
> On 09/06/16 13:44, Ladi Prosek wrote:
>>>
>>> Do you know what prevents the usual TCP retransmission mechanism from
>>> recovering? ARP discovery should still work even for retransmitted
>>> packets.
&
On Thu, Jun 9, 2016 at 1:14 PM, Michael Brown wrote:
> On 09/06/16 08:58, Ladi Prosek wrote:
>>
>> This keepalive implementation has proven very effective in dealing with
>> freezes. Real-world customer deployments have shown an improvement from
>> 5% to virtually zero
On Thu, Jun 9, 2016 at 2:03 PM, Michael Brown wrote:
> On 09/06/16 12:53, Ladi Prosek wrote:
>>
>> On Thu, Jun 9, 2016 at 1:05 PM, Michael Brown wrote:
>>>
>>> On 09/06/16 11:46, Ladi Prosek wrote:
>>>>
>>>> The UNDI ROM ID structure decl
On Thu, Jun 9, 2016 at 1:05 PM, Michael Brown wrote:
> On 09/06/16 11:46, Ladi Prosek wrote:
>>
>> The UNDI ROM ID structure declares the minimum required stack segment
>> size but the value is not used by iPXE.
>
>
> iPXE doesn't use any meaningful amount
The UNDI ROM ID structure declares the minimum required stack segment
size but the value is not used by iPXE.
This commit adds stack-related logging to undirom_parse_pxeromid and
undi_load to help with UNDI debugging.
Signed-off-by: Ladi Prosek
---
Ideally undi_load would fail if we don't
work aware
of the host's existence.
The functionality is behind a new "tcp-keepalive" config option, defaulting
to off for full backward compatibility.
Signed-off-by: Ladi Prosek
---
src/net/tcp.c | 90 +++
1 file change
Friendly ping.
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/55#issuecomment-224812685___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https
ff1ab8b touches common PCI code but only the virtio-net driver is affected.
Please let me know if there are any questions or concerns.
Thank you,
Ladi
You can view, comment on, or merge this pull request online at:
https://github.com/ipxe/ipxe/pull/55
-- Commit Summary --
* [pci] Add pci_e
Hi all,
Just a quick announcement that there's a new iPXE subtree at
https://github.com/ladipro/ipxe-virtio focused on Virtio networking
and related areas. The plan is to be sending regular pull requests to
ipxe/ipxe with reviewed patches. Any and all Virtio contributions are
welcome and will be r
On Sat, Apr 30, 2016 at 2:54 PM, Mohammad Oslani
wrote:
> Hello,
>
> We are trying to load windows over ipxe and followed over this page :
> http://ipxe.org/wimboot
>
> However I am unable to get it loaded correctly, after everything is
> loaded and server boots up again I get always a blue scree.
Apfelbaum
Signed-off-by: Ladi Prosek
---
src/drivers/bus/virtio-pci.c | 10 ++
src/drivers/net/virtio-net.c | 41 +++--
2 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/src/drivers/bus/virtio-pci.c b/src/drivers/bus/virtio-pci.c
index a1c805a
d' meaning.
Signed-off-by: Ladi Prosek
---
src/include/ipxe/virtio-pci.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/include/ipxe/virtio-pci.h b/src/include/ipxe/virtio-pci.h
index c7452c8..f3c9b17 100644
--- a/src/include/ipxe/virtio-pci.h
+++ b/src/incl
still unconditionally
enables both memory and I/O space access, and makes sure that the PCI
latency timer is set to a minimum value of 32.
Reviewed-by: Marcel Apfelbaum
Signed-off-by: Ladi Prosek
Suggested-by: Michael S. Tsirkin
---
src/drivers/bus/pci.c
This series is a follow-up to our virtio 1.0 discussion. The
first patch adds two new functions as suggested by Michael and
the third one makes virtio-net call them.
Changes v1->v2:
* fixed comment 'busmaster' -> 'bus master'
* renamed functions 'enable_pci_device' -> 'pci_enable_device',
'disa
On Mon, May 2, 2016 at 4:21 PM, Marcel Apfelbaum wrote:
> On 05/02/2016 04:11 PM, Ladi Prosek wrote:
>>
>> Some of the regions may end up being unmapped, either because
>> they are optional or because the attempt to map them has failed.
>> Region types starting at 0
The driver enabled both memory and I/O access even if they were
not usable, e.g. BAR not mapped by BIOS. This commit fixes it by
enabling only the BAR types actually used. The device is also
restored to the original state (in terms of the command PCI
register) on removal.
Signed-off-by: Ladi
still unconditionally
enables both memory and I/O space access, and makes sure that the PCI
latency timer is set to a minimum value of 32.
Signed-off-by: Ladi Prosek
Suggested-by: Michael S. Tsirkin
---
src/drivers/bus/pci.c | 58 +-
src/include
es up by 1.
Signed-off-by: Ladi Prosek
---
src/include/ipxe/virtio-pci.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/include/ipxe/virtio-pci.h b/src/include/ipxe/virtio-pci.h
index c7452c8..ec8efaa 100644
--- a/src/include/ipxe/virtio-pci.h
+++ b/src/include
This series is a follow-up to our virtio 1.0 discussion. The
first patch adds two new functions as suggested by Michael and
the third one makes virtio-net call them.
Changes v1->v2:
* fixed comment 'busmaster' -> 'bus master'
* renamed functions 'enable_pci_device' -> 'pci_enable_device',
'disa
On Mon, May 2, 2016 at 9:58 AM, Marcel Apfelbaum wrote:
> On 05/02/2016 10:39 AM, Ladi Prosek wrote:
>>
>> On Sun, May 1, 2016 at 2:24 PM, Marcel Apfelbaum
>> wrote:
>>>
>>> Hi Ladi,
>>>
>>> On 04/28/2016 06:34 PM, Ladi Prosek wrote:
>
On Sun, May 1, 2016 at 2:41 PM, Michael S. Tsirkin wrote:
> On Sun, May 01, 2016 at 03:25:07PM +0300, Marcel Apfelbaum wrote:
>> On 04/28/2016 06:34 PM, Ladi Prosek wrote:
>> >The driver enabled both memory and I/O access even if they were
>> >not usable, e.g. BAR not
On Sun, May 1, 2016 at 2:24 PM, Marcel Apfelbaum wrote:
> Hi Ladi,
>
> On 04/28/2016 06:34 PM, Ladi Prosek wrote:
>>
>> adjust_pci_device unconditionally enables both memory and I/O space
>> access, which may not be necessary.
>
>
> The above problem is not
The driver enabled both memory and I/O access even if they were
not usable, e.g. BAR not mapped by BIOS. This commit fixes it by
enabling only the BAR types actually used. The device is also
reverted to the original state (in terms of the command PCI
register) on removal.
Signed-off-by: Ladi
This series is a follow-up to our virtio 1.0 discussion. The
first patch adds two new functions as suggested by Michael and
the second one makes virtio-net call them.
CC'ing Marcel who may be interested in this (keywords: BIOS,
PCI, BAR :)
Thanks!
Ladi
[PATCH 1/2] [pci] Add enable_pci_device and
and
disable_pci_device is the shutdown path counterpart.
Signed-off-by: Ladi Prosek
Suggested-by: Michael S. Tsirkin
---
src/drivers/bus/pci.c | 41 +++--
src/include/ipxe/pci.h | 2 ++
2 files changed, 37 insertions(+), 6 deletions(-)
diff --git a/src
ping
On Thu, Apr 21, 2016 at 2:48 PM, Ladi Prosek wrote:
> On Thu, Apr 21, 2016 at 12:18 PM, Michael Brown wrote:
>> On 21/04/16 09:36, Ladi Prosek wrote:
>>>
>>> Following up on our IRC conversation, here's what I get when playing
>>>
On Thu, Apr 21, 2016 at 12:18 PM, Michael Brown wrote:
> On 21/04/16 09:36, Ladi Prosek wrote:
>>
>> Following up on our IRC conversation, here's what I get when playing
>> with a Linux kernel with no VLAN support (!CONFIG_VLAN_8021Q &&
>> !CONFIG_VL
On Sun, Apr 17, 2016 at 6:14 PM, Ladi Prosek wrote:
> Thank you for the quick response.
>
> On Fri, Apr 15, 2016 at 7:03 PM, Michael Brown wrote:
>> On 15/04/16 17:48, Michael Brown wrote:
>>>
>>> On 15/04/16 17:19, Ladi Prosek wrote:
>>>>
>>&g
Thank you for the quick response.
On Fri, Apr 15, 2016 at 7:03 PM, Michael Brown wrote:
> On 15/04/16 17:48, Michael Brown wrote:
>>
>> On 15/04/16 17:19, Ladi Prosek wrote:
>>>
>>> These patches add a small tweak to vlan_rx to make it accept
>>> pri
This commit splits VLAN functionality into protocol / inbound in
vlan_protocol.c and driver / outbound in vlan.c to make adding
support for VLAN 0 priority tagging easier.
Signed-off-by: Ladi Prosek
---
src/include/ipxe/errfile.h | 1 +
src/net/vlan.c | 76
These patches add a small tweak to vlan_rx to make it accept
priority tagged packets. Since this should be supported even
without full VLAN support, extra care is taken to not drag
any unnecessary code into the build if VLAN_CMD is not enabled.
src/config/config.c| 7 +++
src/config/gen
based on the now off-set
EtherType field. For maximum compatibility this is done only
if VLAN 0 has not been explicitly configured.
A new config option VLAN0_PRIORITY is added and enabled in all
builds by default.
Signed-off-by: Ladi Prosek
---
src/config/config.c | 7 +++
src/config
On Mon, Apr 11, 2016 at 3:00 PM, Michael S. Tsirkin wrote:
> On Mon, Apr 11, 2016 at 11:26:58AM +0200, Ladi Prosek wrote:
>> This commit adds support for driving virtio 1.0 PCI devices.
>> In addition to various helpers, a number of vpm_ functions are
>> introduced to be
.
Legacy devices are driven using the old protocol, same as before
this commit.
Signed-off-by: Ladi Prosek
---
src/drivers/net/virtio-net.c | 262 +--
1 file changed, 251 insertions(+), 11 deletions(-)
diff --git a/src/drivers/net/virtio-net.c b/src/drivers/net
This commit adds support for driving virtio 1.0 PCI devices.
In addition to various helpers, a number of vpm_ functions are
introduced to be used instead of their legacy vp_ counterparts
when accessing virtio 1.0 (aka modern) devices.
Signed-off-by: Ladi Prosek
---
src/drivers/bus/virtio-pci.c
Virtio 1.0 introduces new constants and data structures, common to
all devices as well as specific to virtio-net. This commit adds a
subset of these to be able to drive the virtio-net 1.0 network
device.
Signed-off-by: Ladi Prosek
---
src/drivers/net/virtio-net.h | 16 +++
src/include
, PCI_CAP_ID_VNDR);
pos > 0;
pos = pci_find_next_capability(pci, pos, PCI_CAP_ID_VNDR)) {
...
}
Signed-off-by: Ladi Prosek
Reviewed-by: Michael S. Tsirkin
---
src/drivers/bus/pciextra.c | 54 +++---
src/include/ipxe/pci.h | 2 ++
The goal here is to support booting from modern and transitional
virtio-net devices using the new virtio 1.0 protocol. The code
strives to comply with the virtio 1.0 spec and is heavily inspired
by the Linux kernel implementation.
Changes from v3:
* reverted the device initialization change, adju
On Tue, Apr 5, 2016 at 7:52 PM, Michael S. Tsirkin wrote:
> On Tue, Apr 05, 2016 at 05:38:24PM +0200, Ladi Prosek wrote:
>> + /* Enable the PCI device only if we need to */
>> + if ( ( virtnet->vdev.common.flags & VIRTI
This commit adds support for driving virtio 1.0 PCI devices.
In addition to various helpers, a number of vpm_ functions are
introduced to be used instead of their legacy vp_ counterparts
when accessing virtio 1.0 (aka modern) devices.
Signed-off-by: Ladi Prosek
---
src/drivers/bus/virtio-pci.c
.
Legacy devices are driven using the old protocol, same as before
this commit.
Signed-off-by: Ladi Prosek
---
src/drivers/net/virtio-net.c | 271 +--
1 file changed, 260 insertions(+), 11 deletions(-)
diff --git a/src/drivers/net/virtio-net.c b/src/drivers/net
Virtio 1.0 introduces new constants and data structures, common to
all devices as well as specific to virtio-net. This commit adds a
subset of these to be able to drive the virtio-net 1.0 network
device.
Signed-off-by: Ladi Prosek
---
src/drivers/net/virtio-net.h | 16 +++
src/include
, PCI_CAP_ID_VNDR);
pos > 0;
pos = pci_find_next_capability(pci, pos, PCI_CAP_ID_VNDR)) {
...
}
Signed-off-by: Ladi Prosek
Reviewed-by: Michael S. Tsirkin
---
src/drivers/bus/pciextra.c | 54 +++---
src/include/ipxe/pci.h | 2 ++
The goal here is to support booting from modern and transitional
virtio-net devices using the new virtio 1.0 protocol. The code
strives to comply with the virtio 1.0 spec and is heavily inspired
by the Linux kernel implementation.
Changes from v2:
* adjust_pci_device is called only if we actually
On Tue, Apr 5, 2016 at 2:41 PM, Michael S. Tsirkin wrote:
> On Tue, Apr 05, 2016 at 01:15:24PM +0200, Ladi Prosek wrote:
>> On Sun, Apr 3, 2016 at 1:50 PM, Michael S. Tsirkin wrote:
>> > On Mon, Mar 14, 2016 at 03:48:25PM +0100, Ladi Prosek wrote:
>> >> This c
On Sun, Apr 3, 2016 at 1:50 PM, Michael S. Tsirkin wrote:
> On Mon, Mar 14, 2016 at 03:48:25PM +0100, Ladi Prosek wrote:
>> This commit makes virtio-net support devices with VEN 0x1af4
>> and DEV 0x1041, which is how non-transitional (modern-only)
>> virtio-net devices are e
On Sun, Apr 3, 2016 at 1:51 PM, Michael S. Tsirkin wrote:
> On Mon, Mar 14, 2016 at 03:48:24PM +0100, Ladi Prosek wrote:
>> This commit adds support for driving virtio 1.0 PCI devices.
>> In addition to various helpers, a number of vpm_ functions are
>> introduced to be
1 - 100 of 122 matches
Mail list logo
