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.
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
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
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:
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
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
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
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
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
(-)
===
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
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
This is now in -current. If anyone notices problems, give noise.
Cheers,
Stefan
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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 |
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
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,
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 @@
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
+++
%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 +-
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
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
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
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
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
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
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 },
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
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
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
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
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
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
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
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
: $
+.\
+.\ 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
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
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
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
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
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
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
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
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
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
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 */
/*
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
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
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
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.
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
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
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
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
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
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
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
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
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)
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
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
101 - 187 of 187 matches
Mail list logo
