OK, here’s an updated diff. Sorry for the delay, I’ve been having network
problems. Boots up and gets detected immediately by OpenBSD, no delays.
diff --git a/sys/arch/amd64/amd64/vmm.c b/sys/arch/amd64/amd64/vmm.c
index 4ffb2ff899f..7de38facc78 100644
--- a/sys/arch/amd64/amd64/vmm.c
+++ b/sys/a
On Sat, Jun 01, 2019 at 06:12:16PM -0500, Katherine Rohl wrote:
> Couple questions:
>
> > This means no interrupt will be injected. I'm not sure if that's what you
> > want.
> > See vm.c: vcpu_exit_inout(..). It looks like you may have manually asserted
> > the
> > IRQ in this file, which is a b
On Sun, Jun 02, 2019 at 03:21:34PM +0200, Jasper Lievisse Adriaanse wrote:
> On Sat, Jun 01, 2019 at 06:12:16PM -0500, Katherine Rohl wrote:
> > Couple questions:
> >
> > > This means no interrupt will be injected. I'm not sure if that's what you
> > > want.
> > > See vm.c: vcpu_exit_inout(..). I
On Sat, Jun 01, 2019 at 06:12:16PM -0500, Katherine Rohl wrote:
> Couple questions:
>
> > This means no interrupt will be injected. I'm not sure if that's what you
> > want.
> > See vm.c: vcpu_exit_inout(..). It looks like you may have manually asserted
> > the
> > IRQ in this file, which is a b
Couple questions:
> This means no interrupt will be injected. I'm not sure if that's what you
> want.
> See vm.c: vcpu_exit_inout(..). It looks like you may have manually asserted
> the
> IRQ in this file, which is a bit different than what we do in other devices.
> That
> may be okay, though.
On Thu, May 30, 2019 at 11:06:57PM -0500, Katherine Rohl wrote:
> Apologies.
>
> ---
>
Hi Katherine,
Thanks for the diff. I think we are getting close! A few comments below.
-ml
> diff --git a/sys/arch/amd64/amd64/vmm.c b/sys/arch/amd64/amd64/vmm.c
> index 4ffb2ff899f..7de38facc78 100644
>
Apologies.
---
diff --git a/sys/arch/amd64/amd64/vmm.c b/sys/arch/amd64/amd64/vmm.c
index 4ffb2ff899f..7de38facc78 100644
--- a/sys/arch/amd64/amd64/vmm.c
+++ b/sys/arch/amd64/amd64/vmm.c
@@ -5359,6 +5359,8 @@ svm_handle_inout(struct vcpu *vcpu)
case IO_ICU1 ... IO_ICU1 + 1:
case
Ah, OK. This should follow style(9):
—
Ah, OK. This should follow style(9):
---
diff --git a/sys/arch/amd64/amd64/vmm.c b/sys/arch/amd64/amd64/vmm.c
index 4ffb2ff899f..7de38facc78 100644
--- a/sys/arch/amd64/amd64/vmm.c
+++ b/sys/arch/amd64/amd64/vmm.c
@@ -5359,6 +5359,8 @@ svm_handle_inout(str
On Thu, May 30, 2019 at 12:09:01AM -0500, Katherine Rohl wrote:
> Okay, here's the first pass of my 8042 device - I wasn't able to figure out
> how to tie the reset line to the guest VM reset, so I was hoping someone
> could give me a hand with that. Other than that, it attaches to i386 and
> am
Okay, here’s the first pass of my 8042 device - I wasn’t able to figure out how
to tie the reset line to the guest VM reset, so I was hoping someone could give
me a hand with that. Other than that, it attaches to i386 and amd64 OpenBSD
guests. There’s no input yet as I mentioned, but the 8042 co
I did a little more looking and the only practical use is $F0 to pulse the
reset line rather than setting it directly (and thus locking up the system
forever). I’ll treat it as a reset. $F1 would pulse Gate A20 (which is a
useless operation in a PC) and $F2 and $F3 pulse reserved bits.
> On Ma
On Tue, May 28, 2019 at 09:57:02PM -0500, Katherine Rohl wrote:
> I have my i8042 device for vmd(8) mostly implemented. It’s only missing a few
> commands, but since there are no PS/2 input devices yet, there isn’t very
> much in the way of testing I can do beyond ensuring that commands act as th
I have my i8042 device for vmd(8) mostly implemented. It’s only missing a few
commands, but since there are no PS/2 input devices yet, there isn’t very much
in the way of testing I can do beyond ensuring that commands act as they
should.
I have a couple questions about expected behavior, mostl
13 matches
Mail list logo
