Re: polling SSL kerberos and srp support

2014-04-29 Thread Stefan Fritsch
Am Montag, 28. April 2014, 21:40:30 schrieb Ted Unangst: Also note that I'm not really interested in rumors or whispers. You don't need to tell me that it's possible somebody else uses Kerberos. I know it's possible, that's why I'm asking. I'd like to know who. One data point: Apache HTTPD

Re: 9p

2014-05-30 Thread Stefan Fritsch
On Thursday 29 May 2014 19:17:25, M Farkas-Dyck wrote: On 29/05/2014, Ted Unangst t...@tedunangst.com wrote: The first question is why not use fuse? I think it's better to have one userland filesystem interface than two. We already have 2: fuse, nfs. • 9p can operate over arbitrary

Paravirtualized optimizations for KVM

2014-07-08 Thread Stefan Fritsch
Hi, I have been trying to increase fork performance of openbsd/amd64 on KVM. It turns out that when I increase the number of CPUs of a VM from 1 to 3, a fork+exit micro benchmark is slowed down by a factor of 7. The main reason for this seems to be a very large number of cross-CPU TLB flushes

Re: Paravirtualized optimizations for KVM

2014-07-09 Thread Stefan Fritsch
On Tuesday 08 July 2014 23:53:21, Mark Kettenis wrote: Are these paravirtualization APIs stable? Are they (properly) documented somewhere? Mostly. So far, I am using three things: 1) the paravirtualized EOI. Documented in Documentation/virtual/kvm/msr.txt in linux source. 2) the MSR to write

Re: [portable] OpenPGP signatures on release checksums (#12)

2014-07-20 Thread Stefan Fritsch
On Monday 14 July 2014 12:45:35, Bob Beck wrote: $ wc -l *.c 29 crypto_api.c 143 mod_ed25519.c 327 mod_ge25519.c 806 signify.c 1305 total Signify is 1305 *lines* of C code. and it's included in our development platform. It is not that difficult to install, and

Re: Paravirtualized optimizations for KVM

2014-08-17 Thread Stefan Fritsch
On Saturday 16 August 2014 23:51:46, Philip Guenther wrote: Yes, code patching may be useful. I haven't noticed it used in openbsd before, but I will take a look at sparc64. Code patching is used currently on i386 and amd64 for the SMAP support. Grep for _copyin_stac, for example. Thanks.

Improving amd64 pmap for MP

2014-08-17 Thread Stefan Fritsch
Hi, I found some patch by Art from 2008 that removes the APTE stuff. The patch was for i386 but I have adapted it to amd64. Instead of mapping the ptes of an inactive pmap in the APTE range, and then doing an unconditional remote TLB-flush on all CPUs, we just switch to the other pmap

minphys woes

2014-08-28 Thread Stefan Fritsch
Hi, while debugging some problems on a virtio host that supports only few dma segments per request, I noticed that the minphys function is not called in all code paths. It is only used for physio but not for other (cached) disk operations. An example trace is below. Am I missing something or

Re: minphys woes

2014-08-28 Thread Stefan Fritsch
On Friday 29 August 2014 10:34:20, David Gwynne wrote: are you expecting minphys to appear in that backtrace? No. In that trace minphys should have limited the transfer size and I had put an KASSERT() into vioblk_scsi_cmd() which verified that xs- datalen is not larger than that limit. A call

Re: minphys woes

2014-08-29 Thread Stefan Fritsch
Gwynne wrote: is it something msdos isnt doing that ffs does? On 29 Aug 2014, at 15:55, Stefan Fritsch s...@sfritsch.de wrote: On Friday 29 August 2014 10:34:20, David Gwynne wrote: are you expecting minphys to appear in that backtrace? No. In that trace minphys should have

Re: minphys woes

2014-08-29 Thread Stefan Fritsch
On Fri, 29 Aug 2014, Miod Vallat wrote: +++ b/sys/dev/pci/vioblk.c @@ -63,6 +63,7 @@ #include scsi/scsi_disk.h #include scsi/scsiconf.h +#define MINPHYS(20*1024) This makes no sense. If you want to override MINPHYS, you need to override for the whole kernel, not

Re: minphys woes

2014-08-29 Thread Stefan Fritsch
On Fri, 29 Aug 2014, Miod Vallat wrote: sc-sc_xfer_max is computed according to the host's capabilities. What I want to simulate with this diff is a host adapter that can only cope with transfers 64k == MAXPHYS. Back to your original problem, you might want to print the sc_link struct

Re: minphys woes

2014-08-29 Thread Stefan Fritsch
On Fri, 29 Aug 2014, Mike Belopuhov wrote: On 29 August 2014 11:26, Stefan Fritsch s...@sfritsch.de wrote: On Fri, 29 Aug 2014, Miod Vallat wrote: sc-sc_xfer_max is computed according to the host's capabilities. What I want to simulate with this diff is a host adapter that can only cope

Re: minphys woes

2014-09-01 Thread Stefan Fritsch
On Mon, 1 Sep 2014, Mike Belopuhov wrote: On 29 August 2014 22:39, Stefan Fritsch s...@sfritsch.de wrote: Yes, that seems to be what happens. But if every adapter needs to support transfers of MAXBSIZE == MAXPHYS anyway, there would be no need for the adapter to be able to override

Re: minphys woes

2014-09-01 Thread Stefan Fritsch
On Mon, 1 Sep 2014, David Gwynne wrote: Yes, that seems to be what happens. But if every adapter needs to support transfers of MAXBSIZE == MAXPHYS anyway, there would be no need for the adapter to be able to override the default minphys function with its own. And adapters that only

Re: minphys woes

2014-09-02 Thread Stefan Fritsch
On Monday 01 September 2014 22:24:16, David Gwynne wrote: i haven't found a controller that does less than MAXPHYS. perhaps they meant to improve the situation but stopped short. if we wanted to raise MAXPHYS, we'd have to support older controllers that cant do greater than 64k with some

Re: minphys woes

2014-09-02 Thread Stefan Fritsch
On Tuesday 02 September 2014 13:15:19, Philip Guenther wrote: On Tue, Sep 2, 2014 at 12:51 PM, Stefan Fritsch s...@sfritsch.de wrote: On Monday 01 September 2014 22:24:16, David Gwynne wrote: i haven't found a controller that does less than MAXPHYS. perhaps they meant to improve

Re: minphys woes

2014-09-03 Thread Stefan Fritsch
On Tuesday 02 September 2014 15:22:16, Philip Guenther wrote: From physio(9): minphys A device specific routine called to determine the maximum transfer size that the device's strategy routine can handle. Since we have seen that the driver must be able to handle 64k

Re: minphys woes

2014-09-05 Thread Stefan Fritsch
On Wednesday 03 September 2014 15:23:13, Philip Guenther wrote: IMO, the problem that you're hitting with your vioblk device isn't a problem with MAXPHYS, physio(), or minphys, but rather with MAXBSIZE. Back in the 1990's, the fact that you want to be able to configure a device with minphys

Re: sparc64: fledgling QEMU support

2014-09-09 Thread Stefan Fritsch
On Tuesday 09 September 2014 21:27:37, Mark Cave-Ayland wrote: Could the PCI virtio stuff be adapted to non-x86 architectures? QEMU already has a virtio PCI device that can be plugged into qemu-system-sparc64 (see Artyom's blog at

Speeding up openbsd on amd64 MP

2014-09-14 Thread Stefan Fritsch
Hi, I have improved my amd64 pmap patches a bit and finally got around to doing some benchmarks with them. Systems: - core-i7 is an Intel Core i7-860 with 4 cores / 8 threads - core2duo is an Intel Core 2 Duo T8100 with 2 cores - KVM is a VM with 4 vcpus running on qemu 2.1/Linux 3.16 on the

Speeding up openbsd on amd64 MP - patch 1/2

2014-09-14 Thread Stefan Fritsch
Simple cleanups for amd64 pmap - use __func__ in panics/printfs (fixes some out of sync function names) - tell the compiler that code paths where we print diagnostics are unlikely - use pmap_valid_entry() in some places - KERNSPACE is not used anywhere diff --git

Speeding up openbsd on amd64 MP - patch 2/2

2014-09-14 Thread Stefan Fritsch
Optimize pmap on amd64 based on a patch for i386 by Art from 2008 that removes the APTE stuff. Some additional bits were taken from a patch by Art for amd64 from 2005. Instead of mapping the ptes of an inactive pmap in the APTE range, and then doing an unconditional remote TLB-flush on all

Re: Speeding up openbsd on amd64 MP

2014-09-14 Thread Stefan Fritsch
On Sun, 14 Sep 2014, Job Snijders wrote: On Sun, Sep 14, 2014 at 02:54:54PM +0200, Stefan Fritsch wrote: I would like people to test the diffs on other machines. In particular on non-Intel CPUs. The only AMD system I could get hold of did not run reliably with openbsd even without

Re: Speeding up openbsd on amd64 MP

2014-09-14 Thread Stefan Fritsch
On Sunday 14 September 2014 12:13:44, Brent Cook wrote: Results for an old Athlon (hmm, I don't remember it running at 10.8 Ghz before) cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+, 10823.06 MHz forktest 0m19.23s real 0m0.72s user 0m22.46s system forktest+0m16.33s

Re: Speeding up openbsd on amd64 MP - patch 2/2

2014-10-06 Thread Stefan Fritsch
This is now in -current. If anyone notices problems, give noise. Cheers, Stefan

Removing -Wno-format from kernel makefiles, 1/16

2013-07-03 Thread Stefan Fritsch
add support for %td for ptrdiff_t in kernel this also adds support in gcc 4.x kprintf --- gnu/gcc/gcc/c-format.c |7 --- sys/kern/subr_prf.c|6 ++ 2 files changed, 10 insertions(+), 3 deletions(-) diff --git gnu/gcc/gcc/c-format.c gnu/gcc/gcc/c-format.c index

Removing -Wno-format from kernel makefiles, 06/16

2013-07-04 Thread Stefan Fritsch
Use %z* for size_t while there, fix a few %d into %u --- sys/arch/i386/pci/pcibios.c |2 +- sys/dev/ic/bwi.c|4 ++-- sys/dev/ic/pgt.c|6 +++--- sys/dev/ic/ti.c |4 ++-- sys/dev/pci/amdiic.c|4 ++-- sys/dev/pci/amdpm.c |

Re: Removing -Wno-format from kernel makefiles, 3/16

2013-07-04 Thread Stefan Fritsch
On Wed, 3 Jul 2013, Mark Kettenis wrote: diff --git sys/arch/i386/i386/db_interface.c sys/arch/i386/i386/db_interface.c index 85c1ff5..c75fd89 100644 --- sys/arch/i386/i386/db_interface.c +++ sys/arch/i386/i386/db_interface.c @@ -197,11 +197,11 @@ db_sysregs_cmd(db_expr_t addr, int

Re: Removing -Wno-format from kernel makefiles, 4/16

2013-07-04 Thread Stefan Fritsch
On Wed, 3 Jul 2013, Mark Kettenis wrote: diff --git sys/arch/i386/i386/esm.c sys/arch/i386/i386/esm.c index c90b2c4..3dff69e 100644 --- sys/arch/i386/i386/esm.c +++ sys/arch/i386/i386/esm.c @@ -880,7 +880,7 @@ esm_make_sensors(struct esm_softc *sc, struct esm_devmap *devmap,

Removing -Wno-format from kernel makefiles, 07/16

2013-07-04 Thread Stefan Fritsch
fix: %x instead of %p for int --- sys/dev/pci/musycc_obsd.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git sys/dev/pci/musycc_obsd.c sys/dev/pci/musycc_obsd.c index 25a58d8..0844136 100644 --- sys/dev/pci/musycc_obsd.c +++ sys/dev/pci/musycc_obsd.c @@ -215,7 +215,7 @@

Removing -Wno-format from kernel makefiles, 10/16

2013-07-04 Thread Stefan Fritsch
fix: pointer to long --- sys/arch/i386/pci/pci_addr_fixup.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git sys/arch/i386/pci/pci_addr_fixup.c sys/arch/i386/pci/pci_addr_fixup.c index 59880eb..40f7918 100644 --- sys/arch/i386/pci/pci_addr_fixup.c +++

Removing -Wno-format from kernel makefiles, 09/16

2013-07-04 Thread Stefan Fritsch
paddr_t is long --- sys/arch/i386/i386/machdep.c |4 ++-- sys/arch/i386/pci/pci_addr_fixup.c |2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git sys/arch/i386/i386/machdep.c sys/arch/i386/i386/machdep.c index 7924386..1a26e7d 100644 --- sys/arch/i386/i386/machdep.c

Removing -Wno-format from kernel makefiles, 08/16

2013-07-04 Thread Stefan Fritsch
%hu/%hd for uint16_t, %u/%d/%x for uint32_t despite the name, ntohl returns uint32_t also fix some %d into %u --- sys/arch/i386/i386/bios.c|4 ++-- sys/arch/i386/i386/ioapic.c |2 +- sys/arch/i386/pci/pcibios.c |4 ++-- sys/kern/vfs_cluster.c |2 +-

Re: Removing -Wno-format from kernel makefiles, V2

2013-07-04 Thread Stefan Fritsch
On Wednesday 03 July 2013, Stefan Fritsch wrote: I haven't done any signedness fixes so far, only the size fixes. But I will look over the patches again and try to fix the signedness issues in the touched code lines, too. There are quite a few I guess. For people prefering to review by source

Re: virtio MSI

2013-09-22 Thread Stefan Fritsch
Am Mittwoch, 18. September 2013, 07:19:30 schrieb Chris Cappuccio: Here's a simple and obvious change that would be necessary to support virtio under bhyve. But it is only acceptable if other virtio implementations either 1. don't claim to support MSI or 2. also work with MSI. Qemu does not

Re: virtio MSI

2013-09-23 Thread Stefan Fritsch
Out of interest, does openbsd run on bhyve with this patch, or are there other problems? On Sun, 22 Sep 2013, Stefan Fritsch wrote: Am Mittwoch, 18. September 2013, 07:19:30 schrieb Chris Cappuccio: Here's a simple and obvious change that would be necessary to support virtio under bhyve

Snapshot install54.iso does not boot under qemu/kvm

2014-01-02 Thread Stefan Fritsch
Hi, the 2013-12-31 snapshot iso images don't work for me under qemu 1.7.0 / linux 3.12.6. They get this far and then reboot: loadrandom: cd0a:/etc/random.seed cannot open cd0a:/etc/random.seed loadrandom: error -1 booting cd0a:/5.4/i386/bsd.rd: 6038744+426300 [72+233616+222178]=0x699c6c entry

Virtio drivers for OpenBSD

2012-07-11 Thread Stefan Fritsch
Hi, I have been working on porting NetBSD's virtio drivers to OpenBSD. I am not finished yet, but in order to prevent duplicate work, I thought I'd publish the current state (attached as diff to OpenBSD 5.1). It adds a virtio block device driver (viod) and a virtio network interface

Re: Virtio drivers for OpenBSD

2012-07-11 Thread Stefan Fritsch
On Wed, 11 Jul 2012, Otto Moerbeek wrote: On Wed, Jul 11, 2012 at 02:07:00PM +0200, Stefan Fritsch wrote: [demime 1.01d removed an attachment of type TEXT/x-diff which had a name of openbsd-virtio-v1.diff] Diff got stripped. I have put it at http://www.sfritsch.de/~stf/openbsd-virtio

Re: Virtio drivers for OpenBSD

2012-07-11 Thread Stefan Fritsch
On Wed, 11 Jul 2012, Gleydson Soares wrote: could you resubmit a new diff against -current ? please, attach it inline here. ok, will do (but it will take a bit until I have my machine set up)

Re: Virtio drivers for OpenBSD

2012-07-11 Thread Stefan Fritsch
On Wed, 11 Jul 2012, Ted Unangst wrote: We are consolidating and reducing the number of disk types. I think this would be better if it attached as scsi disks, which is what all the cool virtual disks do these days. There is a virtio-scsi device, too, but this is only supported in very recent

Re: Virtio drivers for OpenBSD

2012-07-11 Thread Stefan Fritsch
On Wed, 11 Jul 2012, Theo de Raadt wrote: There are quite a few pretendy-SCSI drivers in the tree, but most of them deal with fairly complicated hardware so they're not good reference points. sparc64's vdsk(4) driver is probably the best reference point, since it's also for a virtual disk

Re: Virtio drivers for OpenBSD

2012-07-12 Thread Stefan Fritsch
On Thu, 12 Jul 2012, Jiri B wrote: On Thu, Jul 12, 2012 at 11:02:54AM +0200, Stefan Fritsch wrote: On Wed, 11 Jul 2012, Matthew Dempsky wrote: There are quite a few pretendy-SCSI drivers in the tree, but most of them deal with fairly complicated hardware so they're not good reference points

Re: [Patch] Virtio drivers for OpenBSD V5

2012-08-13 Thread Stefan Fritsch
On Monday 13 August 2012 17:07:41 you wrote:  * Note: the i386 does not currently require barriers, but we must  * provide the flags to MI code. This is not correct for virtio. We need a memory barrier. sure, copy it from amd64. OK. A slight complication: sfence/mfence/lfence do not

Re: [Patch] Virtio drivers for OpenBSD V5

2012-08-14 Thread Stefan Fritsch
On Monday 13 August 2012 17:00:56 Mike Belopuhov wrote: you're calling MCLGETI and provide an interface pointer but you forget to set watermarks via m_clsetwms. OK. The MCLGETI man page should probably get a pointer to m_clsetwms(). -- genua Gesellschaft fuer Netzwerk- und Unix-Administration

Re: Virtio network interface driver

2012-08-20 Thread Stefan Fritsch
I have been working on porting virtio devices too. Actually for now only networking driver complete The main difference between Stefen's version is virtio devices attaches directly to pci bus. I don't think this is a good idea. There are other transports for virtio than pci, e.g. virtio-mmio.

Re: [Patch] Virtio drivers for OpenBSD V6

2012-08-20 Thread Stefan Fritsch
On Fri, 17 Aug 2012, Mike Belopuhov wrote: On Fri, Aug 17, 2012 at 1:17 PM, Stefan Fritsch s...@sfritsch.de wrote: On Thursday 16 August 2012, Mike Belopuhov wrote: could you please tell me if you're using tx interrupt or not? if yes, why do you need to have a watchdog code implement a txeof

Re: [Patch] Virtio drivers for OpenBSD V6

2012-08-20 Thread Stefan Fritsch
On Mon, 20 Aug 2012, Mike Belopuhov wrote: Always using the tx interrupt decreases performance significantly. On my test system (in MBytes/s): Sending UDP from 75 to 55 Sending TCP from 34 to 25 Why? Because the interrupt load increases by approx. 7000 per second. I think the problem is

Re: [Patch] Virtio drivers for OpenBSD V6

2012-08-20 Thread Stefan Fritsch
On Mon, 20 Aug 2012, Mike Belopuhov wrote: On Mon, Aug 20, 2012 at 1:42 PM, Stefan Fritsch s...@sfritsch.de wrote: Because the interrupt load increases by approx. 7000 per second. I think the problem is that the backend sends packets faster than openbsd can enqueue them. This means that the tx

Re: [Patch] Virtio drivers for OpenBSD V6

2012-08-21 Thread Stefan Fritsch
On Mon, 20 Aug 2012, Mike Belopuhov wrote: Because the interrupt load increases by approx. 7000 per second. I think the problem is that the backend sends packets faster than openbsd can enqueue them. This means that the tx queue will be empty often, and each time an tx interrupt will be

Small memcpy optimization

2012-08-21 Thread Stefan Fritsch
On x86, the xchg operation between reg and mem has an implicit lock prefix, i.e. it is a relatively expensive atomic operation. This is not needed here. --- a/sys/arch/i386/i386/locore.s +++ b/sys/arch/i386/i386/locore.s @@ -802,8 +802,9 @@ ENTRY(bcopy) */ ENTRY(memcpy) movl

Re: [Patch] Virtio drivers for OpenBSD V8

2012-09-02 Thread Stefan Fritsch
On Saturday 01 September 2012, LEVAI Daniel wrote: I've just started to test this with an OpenBSD guest on a Linux host. vio0 NIC and the virtio disk work like a charm. I have a slightly (~10%) better performance with the ide emulation than with virtio, but nevertheless it works. Thanks

Reduce false cache line sharing in page tables

2012-09-02 Thread Stefan Fritsch
Since the Pentium 4, cachelines are 64 byte on x86, not 32 byte. The pmap optimization should be adjusted accordingly: --- sys/arch/i386/i386/pmapae.c +++ sys/arch/i386/i386/pmapae.c @@ -516,10 +516,10 @@ typedef u_int64_t pd_entry_t; /* PDE */ typedef u_int64_t pt_entry_t; /* PTE */ /*

Possible bug in timecounter code

2012-09-02 Thread Stefan Fritsch
tc_windup() calls ntp_update_second() up to 200 times: /* * A large step happens on boot. This constant detects such steps. * It is relatively small so that ntp_update_second gets called enough * in the typical 'missed a couple of seconds' case, but doesn't loop * forever when the time

Re: Possible bug in timecounter code

2012-09-03 Thread Stefan Fritsch
On Sunday 02 September 2012, s...@sfritsch.de wrote: But it may still be a problem the other way round. If adjtimedelta would go to zero during the lost ticks, there will be some over-compensation that is not detected. After some more hints from Mark (thanks), I think this is very unlikely

Re: Possible bug in timecounter code

2012-09-04 Thread Stefan Fritsch
On Monday 03 September 2012, Stefan Fritsch wrote: On Sunday 02 September 2012, s...@sfritsch.de wrote: But it may still be a problem the other way round. If adjtimedelta would go to zero during the lost ticks, there will be some over-compensation that is not detected. After some more

Re: [Patch] Virtio drivers for OpenBSD V9

2012-09-05 Thread Stefan Fritsch
On Tuesday 04 September 2012, LEVAI Daniel wrote: On v, szept 02, 2012 at 12:13:33 +0200, Stefan Fritsch wrote: On Saturday 01 September 2012, LEVAI Daniel wrote: I've just started to test this with an OpenBSD guest on a Linux host. vio0 NIC and the virtio disk work like a charm. I

Re: Scheduler improvements, take 1001, Patch 2/5

2012-10-15 Thread Stefan Fritsch
On Monday 15 October 2012, Stuart Henderson wrote: Best to send the diff, with the accompanying text, in the same email, and make sure they still all apply, I tried testing some of these but didn't manage to get them to apply (either some conflicting change, or they were in the wrong order and

vio(4) Large MTU support

2012-11-01 Thread Stefan Fritsch
Hi, here is a patch to support large MTUs in if_vio. It adds support for the VIRTIO_NET_F_MRG_RXBUF feature, i.e. allows to chain several rx buffers when receiving large packets. To make this work, it has to put the rx meta data headers at the beginning of the mbuf cluster instead of dedicated

Re: Small memcpy optimization

2012-11-01 Thread Stefan Fritsch
On Tuesday 21 August 2012, Stefan Fritsch wrote: On x86, the xchg operation between reg and mem has an implicit lock prefix, i.e. it is a relatively expensive atomic operation. This is not needed here. OKs, anyone? --- a/sys/arch/i386/i386/locore.s +++ b/sys/arch/i386/i386/locore.s

Re: Small memcpy optimization

2012-11-10 Thread Stefan Fritsch
On Thu, 8 Nov 2012, Mark Kettenis wrote: On Tuesday 21 August 2012, Stefan Fritsch wrote: On x86, the xchg operation between reg and mem has an implicit lock prefix, i.e. it is a relatively expensive atomic operation. This is not needed here. OKs, anyone? What you say makes sense, although

Re: ##@!#@# gnu tools

2012-11-16 Thread Stefan Fritsch
On Thursday 15 November 2012, Reyk Floeter wrote: On Thu, Nov 15, 2012 at 5:11 PM, Marc Espie es...@nerim.net wrote: external people regularly ask but why you don't want to use GNU/m4 GNU/make GNU/whatever ? External people seem to ask weird questions. I just had to dig into

[PATCH] Support for virtio random device

2013-01-25 Thread Stefan Fritsch
: $ +.\ +.\ Copyright (c) 2013 Stefan Fritsch s...@sfritsch.de +.\ +.\ Permission to use, copy, modify, and distribute this software for any +.\ purpose with or without fee is hereby granted, provided that the above +.\ copyright notice and this permission notice appear in all copies. +.\ +.\ THE SOFTWARE

Re: [PATCH] Support for virtio random device

2013-01-26 Thread Stefan Fritsch
On Saturday 26 January 2013, Mark Kettenis wrote: As the entropy reserve of the host may not be unlimited, the OpenBSD guest should only ask for entropy when it actually needs it. If qemu really allows the guest to consume the complete entropy reserve of the host then that's a bug in

Re: [PATCH] Support for virtio random device

2013-01-28 Thread Stefan Fritsch
On Sun, 27 Jan 2013, Damien Miller wrote: On Fri, 25 Jan 2013, Stefan Fritsch wrote: Hi, qemu 1.3 has added a virtio entropy device. Here is a driver for it. Comments? OKs? As the entropy reserve of the host may not be unlimited, the OpenBSD guest should only ask for entropy when

[Patch] Fix subr_disk.c to allow compiling with -Wno-error=format

2013-04-06 Thread Stefan Fritsch
The log(pri, ) triggers a 'zero-length kprintf format string' warning which causes gcc to error out despite -Wno-error=format. OK to commit this patch? --- sys/kern/subr_disk.c +++ sys/kern/subr_disk.c @@ -761,13 +761,14 @@ diskerr(struct buf *bp, char *dname, char *what, int pri, int

Re: Removing -Wno-format from kernel makefiles

2013-04-14 Thread Stefan Fritsch
On Saturday 06 April 2013, Stefan Fritsch wrote: That wasn't clear from Miod's response. So the policy is to assume that char/short/int/long long are 8/16/32/64 bits and that intptr_t is long? Should that be added to style(9), then? I assume that the lack of a response means yes

Re: Removing -Wno-format from kernel makefiles

2013-04-15 Thread Stefan Fritsch
On Sun, 14 Apr 2013, Theo de Raadt wrote: That wasn't clear from Miod's response. So the policy is to assume that char/short/int/long long are 8/16/32/64 bits and that intptr_t is long? We only run on C8S16I32L32P32 and C8S16I32L64P64 architectures. Short names ILP32 and I32LP64. The

Re: Removing -Wno-format from kernel makefiles

2013-04-20 Thread Stefan Fritsch
On Sun, 14 Apr 2013, Theo de Raadt wrote: Since the kernel's printf does not support %td for ptrdiff_t, I have used %ld instead. %zd would also work. Is there a preferred way? Or try to add %td support to kernel printf? The patch below seems to do the trick for gcc 4.2. I can't see that we

Re: Removing -Wno-format from kernel makefiles

2013-04-21 Thread Stefan Fritsch
Moved ptrdiff_t definition to types.h with proper guards. Assume ptrdiff_t is long in subr_prf.c OK? --- a/gnu/gcc/gcc/c-format.c +++ b/gnu/gcc/gcc/c-format.c @@ -325,6 +325,7 @@ static const format_length_info kprintf_length_specs[] = { l, FMT_LEN_l, STD_C89, ll, FMT_LEN_ll, STD_C9L },

Re: Removing -Wno-format from kernel makefiles

2013-04-21 Thread Stefan Fritsch
On Sunday 21 April 2013, Mark Kettenis wrote: +++ b/sys/sys/types.h @@ -177,6 +177,11 @@ typedef__clockid_t clockid_t; typedef __size_tsize_t; #endif +#ifndef_PTRDIFF_T_DEFINED_ +#define_PTRDIFF_T_DEFINED_ +typedef__ptrdiff_t

Re: Removing -Wno-format from kernel makefiles

2013-04-21 Thread Stefan Fritsch
On Sunday 21 April 2013, Philip Guenther wrote: On Sun, Apr 21, 2013 at 12:15 PM, Stefan Fritsch s...@sfritsch.de wrote: On Sunday 21 April 2013, Mark Kettenis wrote: ... You can't put ptrdiff_t in sys/types.h either. Why not? POSIX only speaks about at least the following types

Re: Removing -Wno-format from kernel makefiles

2013-04-28 Thread Stefan Fritsch
On Sun, 21 Apr 2013, Stefan Fritsch wrote: On Sunday 21 April 2013, Philip Guenther wrote: Maybe this should be handled the bool bits in sys/types.h, wrapping them in #ifdef _KERNEL ? #ifdef _KERNEL is fine with me. OK for the patch below? --- a/gnu/gcc/gcc/c-format.c +++ b/gnu/gcc/gcc/c

Re: Removing -Wno-format from kernel makefiles

2013-04-28 Thread Stefan Fritsch
On Sunday 28 April 2013, Mark Kettenis wrote: Just drop the sys/types.h ptrdiff_t bit completely please. I don't think it should be used in the kernel; there always is a more appropriate kernel type to use. Does it then still make sense to use %td in printf for differences of pointers, or

Re: Removing -Wno-format from kernel makefiles

2013-04-28 Thread Stefan Fritsch
On Sun, 28 Apr 2013, Stefan Fritsch wrote: On Sun, 21 Apr 2013, Stefan Fritsch wrote: On Sunday 21 April 2013, Philip Guenther wrote: Maybe this should be handled the bool bits in sys/types.h, wrapping them in #ifdef _KERNEL ? #ifdef _KERNEL is fine with me. OK for the patch

Compile time assert macro

2013-05-03 Thread Stefan Fritsch
Hi, I think a CTASSERT macro like in FreeBSD would be nice. It could be used to verify assumptions about type and struct sizes. This should work on gcc 2.9.5, too, but I haven't tested it. --- sys/lib/libkern/libkern.h +++ sys/lib/libkern/libkern.h @@ -138,6 +138,9 @@ abs(int j) #endif

Re: Compile time assert macro

2013-05-17 Thread Stefan Fritsch
On Fri, 3 May 2013, Stefan Fritsch wrote: I think a CTASSERT macro like in FreeBSD would be nice. It could be used to verify assumptions about type and struct sizes. Ariane suggested making the syntax compatible to the C11 variant. OKs for this version? --- a/sys/lib/libkern/libkern.h +++ b

Binary code patching and paravirtualization

2014-12-09 Thread Stefan Fritsch
(-) === diff --git a/sys/arch/amd64/amd64/codepatch.c b/sys/arch/amd64/amd64/codepatch.c new file mode 100644 index 000..3f5eba0 --- /dev/null +++ b/sys/arch/amd64/amd64/codepatch.c @@ -0,0 +1,183 @@ +/* + * Copyright (c) 2014 Stefan Fritsch s...@sfritsch.de + * + * Permission

Re: Binary code patching and paravirtualization

2014-12-09 Thread Stefan Fritsch
On Wednesday 10 December 2014 00:52:44, Antoine Jacoutot wrote: I assume we still need this: printf 'change paravirt0\ny\n\n0x8\nq\n' | config -ef /bsd under Illumos? Correct

Re: Binary code patching and paravirtualization

2014-12-11 Thread Stefan Fritsch
On Thursday 11 December 2014 22:20:06, Jonathan Gray wrote: On Wed, Dec 10, 2014 at 12:32:02AM +0100, Stefan Fritsch wrote: For the codepatching part, the most interesting files are codepatch.c and codepatch.h. In copy.S and cpu.c, I convert the code patching already done for SMAP

Re: Binary code patching and paravirtualization

2014-12-15 Thread Stefan Fritsch
On Thu, 11 Dec 2014, Mark Kettenis wrote: From: Alexey Suslikov alexey.susli...@gmail.com Date: Thu, 11 Dec 2014 20:51:14 + (UTC) Stefan Fritsch sf at sfritsch.de writes: --- a/sys/arch/amd64/include/specialreg.h +++ b/sys/arch/amd64/include/specialreg.h at at -158,6

Re: Binary code patching and paravirtualization

2014-12-15 Thread Stefan Fritsch
On Mon, 15 Dec 2014, Ted Unangst wrote: On Wed, Dec 10, 2014 at 00:32, Stefan Fritsch wrote: --- a/sys/arch/amd64/conf/GENERIC +++ b/sys/arch/amd64/conf/GENERIC @@ -39,6 +39,8 @@ isa0 at amdpcib? isa0at tcpcib? pci*at mainbus0 +paravirt0 at mainbus0

Re: Binary code patching and paravirtualization

2014-12-16 Thread Stefan Fritsch
On Mon, 15 Dec 2014, Ted Unangst wrote: On Mon, Dec 15, 2014 at 23:55, Stefan Fritsch wrote: Only in order to get a flags field that can be tweaked with config(8). And to allow disable via config(8), though that could also be achieved with a flag. Tweaking the behavior with a flags

Re: add m_defrag to pcn driver

2015-04-07 Thread Stefan Fritsch
Hi, I have committed the vio diff with some tweaks to remove some more now unused code. But I think this diff is actually incorrect: On Tue, 31 Mar 2015, Kimberley Manning wrote: Index: if_pcn.c === RCS file:

Re: add m_defrag to pcn driver

2015-04-08 Thread Stefan Fritsch
On Wednesday 08 April 2015 09:48:14, David Gwynne wrote: +continue; +} Other drivers don't dequeue mbufs in out of mem situations. I think you should just set IFF_OACTIVE and break out of the for loop (not shown in the diff). The old code just

Re: add m_defrag to pcn driver

2015-04-01 Thread Stefan Fritsch
On Wednesday 01 April 2015 12:46:47, Kimberley Manning wrote: This diff makes the pcn driver use m_defrag for fragmented mbuf chains, I like this kind of cleanups. As for vio(4) could you try the diff or are you looking for testers? Thanks. I've tried both the vio and pcn diffs

Re: Possible fix for i217 problem

2015-08-05 Thread Stefan Fritsch
Thanks to everyone for the testing. The patch is now committed.

Possible fix for i217 problem

2015-08-04 Thread Stefan Fritsch
Hi, someone mentioned to me the i217-LM problems that were reported on misc end of May. It is possible that the patch below helps. For us, it fixed a problem on a laptop with i217-LM (pci id 8086:153a) where the receiving of packets would stop until the battery of the laptop was removed (or

Call for testing for tty diff

2015-07-17 Thread Stefan Fritsch
While writing a virtio-console driver, I have found a bug in ttwrite() that can cause hangs. Below is a fix and after talking to Theo, I would like to know if the patch causes regressions for anyone, for example hangs in pty input/output, serial ports, etc. Thanks in advance. Cheers, Stefan

Re: usb hang related to xhci

2015-07-19 Thread Stefan Fritsch
On Sat, 18 Jul 2015, David Hill wrote: Whenever I plug a device into my USB ports, my machine locks hard. I have the Intel Series 7 / C216 chip, so xhci attempts to route the port from ehci to xhci. The following diff is from FreeBSD and makes my USB devices work again.

Looking for testers for amd64 suspend diff

2015-09-06 Thread Stefan Fritsch
Hi, the diff below is necessary to make suspend/resume work when x2apic is enabled (i.e. on qemu/kvm/...). While I don't expect problems, it would be nice if I could get some reports that this doesn't break suspend/resume on real machines, especially older ones (like core 2 duo and older) and

Re: Looking for testers for amd64 suspend diff

2015-09-07 Thread Stefan Fritsch
On Monday 07 September 2015 13:23:03, Alexander Bluhm wrote: > Suspend OpenBSD in a fully emulated qemu running on OpenBSD works. > After resume, typing in the shell of the virtualized machine works. > But at disk access, all processes hang in biowait. > > It is the same behavior with and without

Re: Looking for testers for amd64 suspend diff

2015-09-11 Thread Stefan Fritsch
On Sunday 06 September 2015 11:44:11, Stefan Fritsch wrote: > the diff below is necessary to make suspend/resume work when x2apic > is enabled (i.e. on qemu/kvm/...). While I don't expect problems, > it would be nice if I could get some reports that this doesn't > break suspend/re

Re: Checking MAC address of incoming unicast packets

2016-01-04 Thread Stefan Fritsch
On Sun, 3 Jan 2016, Theo de Raadt wrote: > >On Friday 01 January 2016 16:25:59, Theo de Raadt wrote: > >> dlg writes: > >> > should we just do it unconditionally? is there a downside to that? > > > >It may decrease performance a tiny bit. Since such bits tend to add > >up, I would be hesitant to

Re: Checking MAC address of incoming unicast packets

2016-01-02 Thread Stefan Fritsch
On Friday 01 January 2016 16:25:59, Theo de Raadt wrote: > dlg writes: > > should we just do it unconditionally? is there a downside to that? It may decrease performance a tiny bit. Since such bits tend to add up, I would be hesitant to enable the check for drivers that don't need it. OTOH,

Checking MAC address of incoming unicast packets

2016-01-01 Thread Stefan Fritsch
Hi, by default, the ether_input() checks the destination MAC address of incoming unicast packets only if the interface is in promiscous mode. If not, it is assumed that the NIC filters unicast packets reliably. Unfortunately, for virtio-net this is not the case. There, unicast filtering is

Re: Xen virtual network (Netfront) driver

2016-01-06 Thread Stefan Fritsch
On Wed, 6 Jan 2016, Mike Belopuhov wrote: > There's still stuff to do, but it receives and transmits reliably > (at least on modern Xen) so I'd like to get it in. Man page will > follow. I only had a quick glance at the code, but I have one comment about your use of memory barriers. The

Re: Checking MAC address of incoming unicast packets

2016-01-04 Thread Stefan Fritsch
On Mon, 4 Jan 2016, Claudio Jeker wrote: > On Sat, Jan 02, 2016 at 04:04:33PM +0100, Mark Kettenis wrote: > > > Date: Sat, 2 Jan 2016 10:57:41 +0100 > > > From: Martin Pieuchot > > > > > > If it's acceptable performance-wise to do the check unconditionally I > > > believe

Re: pppd and ioctl(TIOCSETD) (was: CVS: cvs.openbsd.org: src)

2015-12-22 Thread Stefan Fritsch
On Tue, 22 Dec 2015, David Coppa wrote: > I suspect this broke my 3G connection: Oops. Sorry. Try this diff (already committed): --- sys/kern/tty_conf.c +++ sys/kern/tty_conf.c @@ -42,6 +42,11 @@ #include #include +#include "ppp.h" +#include "nmea.h" +#include "msts.h" +#include "endrun.h"

  1   2   >