Add support for the VIRTIO_F_SUSPEND feature. When this feature is
negotiated, power management can use it to suspend virtio devices
instead of resorting to resetting the devices entirely.
Signed-off-by: David Stevens
---
drivers/virtio/virtio.c| 60
ead of mdelay.
David Stevens (1):
virtio: Add support for the virtio suspend feature
drivers/virtio/virtio.c| 60 ++
drivers/virtio/virtio_pci_common.c | 34 -
drivers/virtio/virtio_pci_modern.c | 19 ++
include/linux/virti
Add support for the VIRTIO_F_SUSPEND feature. When this feature is
negotiated, power management can use it to suspend virtio devices
instead of resorting to resetting the devices entirely.
Signed-off-by: David Stevens
---
drivers/virtio/virtio.c| 32
].
[1] https://lore.kernel.org/all/20230906081637.32185-3-lingshan@intel.com/
[2] https://lists.oasis-open.org/archives/virtio-comment/202402/msg00088.html
David Stevens (1):
virtio: Add support for the virtio suspend feature
drivers/virtio/virtio.c| 32
From: David Stevens
The virtio_balloon driver uses wakeup sources to allow the guest to
enter system power management sleep states (e.g. s2idle) without running
the risk of becoming unresponsive to cooperative memory management
requests from the host. This series fixes an issue where wakeup
From: David Stevens
Treat stats requests as wakeup events to ensure that the driver responds
to device requests in a timely manner.
Signed-off-by: David Stevens
Acked-by: David Hildenbrand
---
drivers/virtio/virtio_balloon.c | 75 -
1 file changed, 46
From: David Stevens
Wakeup sources don't support nesting multiple events, so sharing a
single object between multiple drivers can result in one driver
overriding the wakeup event processing period specified by another
driver. Have the virtio balloon driver use the wakeup source of the
device
From: David Stevens
Treat stats requests as wakeup events to ensure that the driver responds
to device requests in a timely manner.
Signed-off-by: David Stevens
---
drivers/virtio/virtio_balloon.c | 75 -
1 file changed, 46 insertions(+), 29 deletions(-)
diff
From: David Stevens
Wakeup sources don't support nesting multiple events, so sharing a
single object between multiple drivers can result in one driver
overriding the wakeup event processing period specified by another
driver. Have the virtio balloon driver use the wakeup source of the
device
From: David Stevens
The virtio_balloon driver uses wakeup sources to allow the guest to
enter system power management sleep states (e.g. s2idle) without running
the risk of becoming unresponsive to cooperative memory management
requests from the host. This series fixes an issue where wakeup
From: David Stevens
A virtio_balloon's parent device may be configured so that a
configuration change interrupt is a wakeup event. Extend the processing
of such a wakeup event until the balloon finishes inflating or deflating
by calling pm_stay_awake/pm_relax in the virtio_balloon driver. Note
[ 540.789007]
> kernel: [ 540.791766] lock(>adjustment_lock);
> kernel: [ 540.796014]
> kernel: [ 540.798778] lock(>adjustment_lock);
> kernel: [ 540.803605]
Oh, that's embarrassing, I completely whiffed on interactions with
interrupts. The following patch fixes
On Mon, Dec 18, 2023 at 12:33 PM David Hildenbrand wrote:
>
> On 18.12.23 16:18, David Stevens wrote:
> > From: David Stevens
> >
> > A virtio_balloon's parent device may be configured so that a
> > configuration change interrupt is a wakeup event. Extend the p
On Mon, Dec 18, 2023 at 10:18 AM David Hildenbrand wrote:
>
> On 18.12.23 16:16, David Stevens wrote:
> > On Mon, Dec 18, 2023 at 6:37 AM David Hildenbrand wrote:
> >>
> >> On 14.12.23 05:13, David Stevens wrote:
> >>> On Wed, Dec 13, 2023
From: David Stevens
A virtio_balloon's parent device may be configured so that a
configuration change interrupt is a wakeup event. Extend the processing
of such a wakeup event until the balloon finishes inflating or deflating
by calling pm_stay_awake/pm_relax in the virtio_balloon driver. Note
On Mon, Dec 18, 2023 at 6:37 AM David Hildenbrand wrote:
>
> On 14.12.23 05:13, David Stevens wrote:
> > On Wed, Dec 13, 2023 at 5:44 PM David Hildenbrand wrote:
> >>
> >> On 11.12.23 12:43, David Stevens wrote:
> >>> From: David Stevens
> >>
On Thu, Dec 14, 2023 at 6:47 PM David Hildenbrand wrote:
>
> On 08.12.23 08:07, David Stevens wrote:
> > If a virtio_pci_device supports native PCI power management and has the
> > No_Soft_Reset bit set, then skip resetting and reinitializing the device
> > when
On Wed, Dec 13, 2023 at 5:44 PM David Hildenbrand wrote:
>
> On 11.12.23 12:43, David Stevens wrote:
> > From: David Stevens
> >
>
> Hi David,
>
> > Add a wakeup event for when the balloon is inflating or deflating.
> > Userspace can enable this
From: David Stevens
Add a wakeup event for when the balloon is inflating or deflating.
Userspace can enable this wakeup event to prevent the system from
suspending while the balloon is being adjusted. This allows
/sys/power/wakeup_count to be used without breaking virtio_balloon's
cooperative
that can't simply be re-initialized (e.g. virtio-fs).
Signed-off-by: David Stevens
---
v1 -> v2:
- Check the No_Soft_Reset bit
drivers/virtio/virtio_pci_common.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_pci_common.c
Virtio power management for virtio pci devices is defined on top of PCI
power management, so it mostly works out of the box. All that's needed
is to add suspend/resume callbacks to the virtio core, instead of
reusing the freeze/restore.
Signed-off-by: David Stevens
---
drivers/virtio
Pushing to drm-misc-next works for me. Thanks for the quick responses.
-David
On Thu, Apr 8, 2021 at 6:56 PM Christian König wrote:
>
> Am 08.04.21 um 11:54 schrieb David Stevens:
> > From: David Stevens
> >
> > Allocate a new private stub fence in drm_syncobj_assign_
From: David Stevens
Allocate a new private stub fence in drm_syncobj_assign_null_handle,
instead of using a static stub fence.
When userspace creates a fence with DRM_SYNCOBJ_CREATE_SIGNALED or when
userspace signals a fence via DRM_IOCTL_SYNCOBJ_SIGNAL, the timestamp
obtained when the fence
From: David Stevens
Allocate a new private stub fence in drm_syncobj_assign_null_handle,
instead of using a static stub fence.
When userspace creates a fence with DRM_SYNCOBJ_CREATE_SIGNALED or when
userspace signals a fence via DRM_IOCTL_SYNCOBJ_SIGNAL, the timestamp
obtained when the fence
Sorry, I forgot to checkpatch this, I'll resend it momentarily.
-David
On Thu, Apr 8, 2021 at 6:34 PM David Stevens wrote:
>
> From: David Stevens
>
> Allocate a new private stub fence in drm_syncobj_assign_null_handle,
> instead of using a static stub fence.
>
> When user
From: David Stevens
Allocate a new private stub fence in drm_syncobj_assign_null_handle,
instead of using a static stub fence.
When userspace creates a fence with DRM_SYNCOBJ_CREATE_SIGNALED or when
userspace signals a fence via DRM_IOCTL_SYNCOBJ_SIGNAL, the timestamp
obtained when the fence
On Thu, Apr 8, 2021 at 4:03 PM Christian König wrote:
>
> Am 08.04.21 um 06:59 schrieb David Stevens:
> > From: David Stevens
> >
> > This reverts commit 86bbd89d5da66fe760049ad3f04adc407ec0c4d6.
> >
> > Using the singleton stub fence in drm_syncobj_assign_nul
From: David Stevens
This reverts commit 86bbd89d5da66fe760049ad3f04adc407ec0c4d6.
Using the singleton stub fence in drm_syncobj_assign_null_handle means
that all syncobjs created in an already signaled state or any syncobjs
signaled by userspace will reference the singleton fence when exported
From: David Stevens
Track the range being invalidated by mmu_notifier and skip page fault
retries if the fault address is not affected by the in-progress
invalidation. Handle concurrent invalidations by finding the minimal
range which includes all ranges being invalidated. Although the combined
From: Sean Christopherson
Don't retry a page fault due to an mmu_notifier invalidation when
handling a page fault for a GPA that did not resolve to a memslot, i.e.
an MMIO page fault. Invalidations from the mmu_notifier signal a change
in a host virtual address (HVA) mapping; without a memslot,
bug by skipping prefetch during invalidation
v2 -> v3:
- Added patch to skip check for MMIO page faults
- Style changes
David Stevens (1):
KVM: x86/mmu: Consider the hva in mmu_notifier retry
Sean Christopherson (1):
KVM: x86/mmu: Skip mmu_notifier check when handling MMIO page fault
arch/p
These patches might be responsible for some instability in one of our
stress tests. I'll send an update once I figure out what's going on.
Thanks,
David
On Thu, Jan 28, 2021 at 9:48 PM Paolo Bonzini wrote:
>
> On 28/01/21 07:05, David Stevens wrote:
> > These patches redu
tch to skip check for MMIO page faults
- Style changes
David Stevens (1):
KVM: x86/mmu: Consider the hva in mmu_notifier retry
Sean Christopherson (1):
KVM: x86/mmu: Skip mmu_notifier check when handling MMIO page fault
arch/powerpc/kvm/book3s_64_mmu_hv.c| 2 +-
arch/powerpc/
From: Sean Christopherson
Don't retry a page fault due to an mmu_notifier invalidation when
handling a page fault for a GPA that did not resolve to a memslot, i.e.
an MMIO page fault. Invalidations from the mmu_notifier signal a change
in a host virtual address (HVA) mapping; without a memslot,
From: David Stevens
Track the range being invalidated by mmu_notifier and skip page fault
retries if the fault address is not affected by the in-progress
invalidation. Handle concurrent invalidations by finding the minimal
range which includes all ranges being invalidated. Although the combined
From: David Stevens
Track the range being invalidated by mmu_notifier and skip page fault
retries if the fault address is not affected by the in-progress
invalidation. Handle concurrent invalidations by finding the minimal
range which includes all ranges being invalidated. Although the combined
> > This has the secondary effect of greatly reducing the likelihood of extreme
>
> Out of curiosity, is this really the _secondary_ effect? I would expect this
> change to primarily benefit scenarios where the invalidation has gotten
> waylaid for whatever reason.
Yeah, this is the primary
From: David Stevens
Use the range passed to mmu_notifer's invalidate_range_start to prevent
spurious page fault retries due to changes in unrelated host virtual
addresses. This has the secondary effect of greatly reducing the
likelihood of extreme latency when handing a page fault due to another
://markmail.org/thread/p5d3k566srtdtute
[3] https://markmail.org/thread/j4xlqaaim266qpks
v6 -> v7 changes:
- Fix most strict checkpatch comments
David Stevens (3):
virtio: add dma-buf support for exported objects
virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature
drm/virtio: Support virt
This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.
Signed-off-by: David Stevens
---
include/uapi/linux
This change adds a new flavor of dma-bufs that can be used by virtio
drivers to share exported objects. A virtio dma-buf can be queried by
virtio drivers to obtain the UUID which identifies the underlying
exported object.
Signed-off-by: David Stevens
---
drivers/virtio/Makefile | 2
Add support for UUID-based resource sharing mechanism to virtgpu. This
implements the new virtgpu commands and hooks them up to dma-buf's
get_uuid callback.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 21
> Hmm, checkpatch still complains, full log below.
>
> IIRC "dim checkpatch" runs scripts/checkpatch.pl with --strict
> so it is a bit more picky ...
Ah, I didn't know --strict was being used. I'll send an update
momentarily. Sorry for the churn.
> -:250: CHECK:PREFER_KERNEL_TYPES: Prefer kernel
On Mon, Aug 17, 2020 at 4:12 AM Gerd Hoffmann wrote:
>
> On Mon, Aug 17, 2020 at 12:50:08PM +0200, Gerd Hoffmann wrote:
> > On Tue, Jun 23, 2020 at 10:31:28AM +0900, David Stevens wrote:
> > > Unless there are any remaining objections to these patches, what are
> &g
://markmail.org/thread/p5d3k566srtdtute
[3] https://markmail.org/thread/j4xlqaaim266qpks
v5 -> v6 changes:
- Fix >80 character comment
David Stevens (3):
virtio: add dma-buf support for exported objects
virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature
drm/virtio: Support virtgpu ex
This change adds a new flavor of dma-bufs that can be used by virtio
drivers to share exported objects. A virtio dma-buf can be queried by
virtio drivers to obtain the UUID which identifies the underlying
exported object.
Signed-off-by: David Stevens
---
drivers/virtio/Makefile | 2
Add support for UUID-based resource sharing mechanism to virtgpu. This
implements the new virtgpu commands and hooks them up to dma-buf's
get_uuid callback.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 20
This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.
Signed-off-by: David Stevens
---
include/uapi/linux
10:25:15AM +0900, David Stevens wrote:
> > This patchset implements the current proposal for virtio cross-device
> > resource sharing [1]. It will be used to import virtio resources into
> > the virtio-video driver currently under discussion [2]. The patch
> > unde
On Thu, Jun 18, 2020 at 9:29 PM Guennadi Liakhovetski
wrote:
>
> Hi Michael,
>
> On Thu, Jun 04, 2020 at 03:05:23PM -0400, Michael S. Tsirkin wrote:
> > On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote:
> > > This change adds a new flavor of dma-bufs
This change adds a new flavor of dma-bufs that can be used by virtio
drivers to share exported objects. A virtio dma-buf can be queried by
virtio drivers to obtain the UUID which identifies the underlying
exported object.
Signed-off-by: David Stevens
---
drivers/virtio/Makefile | 2
Add support for UUID-based resource sharing mechanism to virtgpu. This
implements the new virtgpu commands and hooks them up to dma-buf's
get_uuid callback.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 20
This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.
Signed-off-by: David Stevens
---
include/uapi/linux
://markmail.org/thread/p5d3k566srtdtute
[3] https://markmail.org/thread/j4xlqaaim266qpks
v4 -> v5 changes:
- Remove virtio_dma_buf_export_info.
David Stevens (3):
virtio: add dma-buf support for exported objects
virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature
drm/virtio: Support virt
On Mon, Jun 8, 2020 at 6:43 PM Michael S. Tsirkin wrote:
>
> On Fri, May 15, 2020 at 04:26:15PM +0900, David Stevens wrote:
> > > > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) {
> > > > + vgdev
On Mon, Jun 8, 2020 at 6:05 PM Michael S. Tsirkin wrote:
>
> On Mon, Jun 08, 2020 at 05:32:26PM +0900, David Stevens wrote:
> > On Mon, Jun 8, 2020 at 3:00 PM Michael S. Tsirkin wrote:
> > >
> > > On Mon, Jun 08, 2020 at 10:33:09AM +0900, David Stevens wrote:
>
On Mon, Jun 8, 2020 at 3:00 PM Michael S. Tsirkin wrote:
>
> On Mon, Jun 08, 2020 at 10:33:09AM +0900, David Stevens wrote:
> > On Sun, Jun 7, 2020 at 5:04 AM Michael S. Tsirkin wrote:
> > >
> > > On Fri, Jun 05, 2020 at 10:28:42AM +0900, David Stevens wrote:
>
On Sun, Jun 7, 2020 at 5:04 AM Michael S. Tsirkin wrote:
>
> On Fri, Jun 05, 2020 at 10:28:42AM +0900, David Stevens wrote:
> > On Fri, Jun 5, 2020 at 4:05 AM Michael S. Tsirkin wrote:
> > >
> > > On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote:
On Fri, Jun 5, 2020 at 4:05 AM Michael S. Tsirkin wrote:
>
> On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote:
> > This change adds a new flavor of dma-bufs that can be used by virtio
> > drivers to share exported objects. A virtio dma-buf can be queried by
This feature allows the guest to request a UUID from the host for a
particular virtio_gpu resource. The UUID can then be shared with other
virtio devices, to allow the other host devices to access the
virtio_gpu's corresponding host resource.
Signed-off-by: David Stevens
---
include/uapi/linux
Add support for UUID-based resource sharing mechanism to virtgpu. This
implements the new virtgpu commands and hooks them up to dma-buf's
get_uuid callback.
Signed-off-by: David Stevens
---
drivers/gpu/drm/virtio/virtgpu_drv.c | 3 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 20
ted
requirement that get_uuid only be called on attached virtio
dma-bufs is also removed.
- Rebase and add call to virtio_gpu_notify for ASSIGN_UUID.
David Stevens (3):
virtio: add dma-buf support for exported objects
virtio-gpu: add VIRTIO_GPU_F_RESOURCE_UUID feature
drm/virtio: Support virt
This change adds a new flavor of dma-bufs that can be used by virtio
drivers to share exported objects. A virtio dma-buf can be queried by
virtio drivers to obtain the UUID which identifies the underlying
exported object.
Signed-off-by: David Stevens
---
drivers/virtio/Makefile | 2
> > + if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_UUID)) {
> > + vgdev->has_resource_assign_uuid = true;
> > + }
>
>
> Just a question: this relies on DMA bufs so I assume it is
> not really assumed to work when DMA API is bypassed, right?
> Rather than worry what
On Thu, May 14, 2020 at 9:30 PM Daniel Vetter wrote:
> On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote:
> > Sorry for the duplicate reply, didn't notice this until now.
> >
> > > Just storing
> > > the uuid should be doable (assuming this doesn't
Sorry for the duplicate reply, didn't notice this until now.
> Just storing
> the uuid should be doable (assuming this doesn't change during the
> lifetime of the buffer), so no need for a callback.
Directly storing the uuid doesn't work that well because of
synchronization issues. The uuid
On Thu, May 14, 2020 at 12:45 AM Daniel Vetter wrote:
> On Wed, Mar 11, 2020 at 12:20 PM David Stevens wrote:
> >
> > This change adds a new dma-buf operation that allows dma-bufs to be used
> > by virtio drivers to share exported objects. The new operation allows
>
My bad -- I see what it's doing, and it looks ok after all.
I thought I saw an INMSGS (but didn't). These are ICMP errors that
went through icmp_rcv() and were counted correctly before getting
to the protocol error handlers. These are failures due mostly to not
having enough, or the right
I took a look at the DCCP references, and I think they're just
incrementing the wrong MIB variable -- e.g., it's incrementing
ICMP_MIB_INERRORS when the skb length is less than the
header indicates. That's not an ICMP_MIB_INERRORS error,
that's an IPSTATS_MIB_INHDRERRORS error. ICMP_MIB_INERRORS
[EMAIL PROTECTED] wrote on 10/24/2007 12:14:37 PM:
> On Wed, Oct 24, 2007 at 12:07:45PM -0700, David Stevens wrote:
> > [EMAIL PROTECTED] wrote on 10/24/2007 09:24:10 AM:
> >
> > > This patch removes the unused EXPORT_SYMBOL(icmpmsg_statistics).
> > >
> &g
[EMAIL PROTECTED] wrote on 10/24/2007 09:24:10 AM:
> This patch removes the unused EXPORT_SYMBOL(icmpmsg_statistics).
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
> 4ce74657ac0b1bdcb4c7bc359d05643f8cc4a08b
> diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
> index 272c69e..233de06
[EMAIL PROTECTED] wrote on 10/24/2007 09:24:10 AM:
This patch removes the unused EXPORT_SYMBOL(icmpmsg_statistics).
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
4ce74657ac0b1bdcb4c7bc359d05643f8cc4a08b
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index 272c69e..233de06 100644
[EMAIL PROTECTED] wrote on 10/24/2007 12:14:37 PM:
On Wed, Oct 24, 2007 at 12:07:45PM -0700, David Stevens wrote:
[EMAIL PROTECTED] wrote on 10/24/2007 09:24:10 AM:
This patch removes the unused EXPORT_SYMBOL(icmpmsg_statistics).
Signed-off-by: Adrian Bunk [EMAIL PROTECTED
I took a look at the DCCP references, and I think they're just
incrementing the wrong MIB variable -- e.g., it's incrementing
ICMP_MIB_INERRORS when the skb length is less than the
header indicates. That's not an ICMP_MIB_INERRORS error,
that's an IPSTATS_MIB_INHDRERRORS error. ICMP_MIB_INERRORS
My bad -- I see what it's doing, and it looks ok after all.
I thought I saw an INMSGS (but didn't). These are ICMP errors that
went through icmp_rcv() and were counted correctly before getting
to the protocol error handlers. These are failures due mostly to not
having enough, or the right
Dmitry,
Good catch; a couple comments:
> struct ipv6_pinfo *np = inet6_sk(sk);
> int err;
> + int addr_type = ipv6_addr_type(addr);
> +
> + if (addr_type == IPV6_ADDR_MAPPED) {
> + __be32 v4addr = addr->s6_addr32[3];
> + struct ip_mreqn mreq;
> +
Dmitry,
Good catch; a couple comments:
struct ipv6_pinfo *np = inet6_sk(sk);
int err;
+ int addr_type = ipv6_addr_type(addr);
+
+ if (addr_type == IPV6_ADDR_MAPPED) {
+ __be32 v4addr = addr-s6_addr32[3];
+ struct ip_mreqn mreq;
+
I'm not sure why it's using rt_src here, but there are relevant cases that
your description doesn't cover. For example, what happens if the source
is not set in the original packet? Does NAT affect this?
You quote RFC text for ICMP echo and the case where the receiving machine
is the final
I'm not sure why it's using rt_src here, but there are relevant cases that
your description doesn't cover. For example, what happens if the source
is not set in the original packet? Does NAT affect this?
You quote RFC text for ICMP echo and the case where the receiving machine
is the final
Stephen Hemminger <[EMAIL PROTECTED]> wrote on 08/24/2007
08:52:03 AM:
>
> You need hardware support for deferred interrupts. Most devices have it
> (e1000, sky2, tg3)
> and it interacts well with NAPI. It is not a generic thing you want done
by the stack,
> you want the hardware to hold off
Stephen Hemminger [EMAIL PROTECTED] wrote on 08/24/2007
08:52:03 AM:
You need hardware support for deferred interrupts. Most devices have it
(e1000, sky2, tg3)
and it interacts well with NAPI. It is not a generic thing you want done
by the stack,
you want the hardware to hold off
> sockets that join different groups receive messages from the respective
> other group (if they are only bound to the wildcard address). Obviously
> this is handled differently in Linux for IPv4, where the socket matching
> for incoming message is done solely on the 4-tuple of addresses and
sockets that join different groups receive messages from the respective
other group (if they are only bound to the wildcard address). Obviously
this is handled differently in Linux for IPv4, where the socket matching
for incoming message is done solely on the 4-tuple of addresses and
>
> I keep having hopeful dreams that one day netfilter will grow support
> for cross-protocol NAT (IE: NAT a TCPv4 connection over TCPv6 to the
> IPv6-only local web server, or vice versa). It would seem that would
> require a merged "xtables" program.
You don't actually need it (at
Unrelated wishful thinking
I keep having hopeful dreams that one day netfilter will grow support
for cross-protocol NAT (IE: NAT a TCPv4 connection over TCPv6 to the
IPv6-only local web server, or vice versa). It would seem that would
require a merged xtables program.
You don't
I expect this is the failure to join the all-nodes multicast group,
in which case the fix has already been posted to netdev. I
believe the router advertisements are sent to that, and if the
join failed, it wouldn't receive any of them.
I think it's better to add the fix than withdraw this patch,
I expect this is the failure to join the all-nodes multicast group,
in which case the fix has already been posted to netdev. I
believe the router advertisements are sent to that, and if the
join failed, it wouldn't receive any of them.
I think it's better to add the fix than withdraw this patch,
87 matches
Mail list logo
