Hi
I believe the change [1] vmm(4): wire faulted in pages, might have been
a bit heavy handed a broken the use of VMM_IOC_MPROTECT_EPT ioctl.
[1] https://marc.info/?l=openbsd-cvs&m=161144130825752
please see the patch below which restores this functionality
Cheers
Adam
diff 917cc7a95e2615798f
Thanks Dave,
I like the description and listing the ioctl, and referencing vmmvar.h is a
good idea
Cheers
Adam
On Thu, Apr 1, 2021 at 18:49, Dave Voutila wrote:
> This diff documents the ioctl(2) values supported by vmm(4). Besides
> vmd(8) there's at least one application I've seen (Solo5) d
Hi
IA32_EPT_VPID_CAP_XO_TRANSLATIONS is specified incorrectly, see the
patch below.
Cheers
Adam
On Fri, Feb 26, 2021 at 01:08:17PM +0800, Adam Steen wrote:
> Hi
>
> IA32_EPT_VPID_CAP_XO_TRANSLATIONS is specified as 0x0 and not (1ULL << 0)
> ie 0 and not bit 0 as on.
>
&g
Hi
IA32_EPT_VPID_CAP_XO_TRANSLATIONS is specified as 0x0 and not (1ULL << 0)
ie 0 and not bit 0 as on.
Please see the attach diff to correct this and rename
IA32_EPT_VPID_CAP_XO_TRANSLATIONS to IA32_EPT_VPID_CAP_XO to reduce
wordyness.
Cheers
Adam
diff 0e7183d43c8ed36e5d169be05df61472565710eb /
> On Fri, Feb 07, 2020 at 01:25:38PM -0800, Mike Larkin wrote:
> > On Fri, Feb 07, 2020 at 04:20:16AM +0000, Adam Steen wrote:
> > > Hi
> > >
> > > Please see the attached patch to add an 'IOCTL handler to sets the access
> > > protections of the
Hi
Please see the patch below to handle invalid writes to cr0 as per the
Intel SDM Volume 3.
The 3 cases i am handling with this change are
1. CR0.PG: Setting the PG flag when the PE flag is clear causes a
general-protection exception (#GP). (Intel SDM Volume 3abcd page 76, Section
2.5 Cont
On Fri, Feb 07, 2020 at 04:38:16PM -0800, Mike Larkin wrote:
>
> On Fri, Feb 07, 2020 at 01:25:38PM -0800, Mike Larkin wrote:
> > On Fri, Feb 07, 2020 at 04:20:16AM +, Adam Steen wrote:
> > > Hi
> > >
> > > Please see the attached patch to a
Hi
Please see the attached patch to add an 'IOCTL handler to sets the access
protections of the ept'
vmd(8) does not make use of this change, but solo5, which uses vmm(4) as
a backend hypervisor. The code calling 'VMM_IOC_MPROTECT_EPT' is
available here https://github.com/Solo5/solo5/compare/mast
Hi
Again while working on a larger patch i noticed that the eptp for vmx
was not getting initialised to zero like the svm code path, as part of
a VMM_IOC_RESETCPU ioctl call.
please see the attach patch to initialise eptp to zero
cheers
Adam
? div
Index: sys/arch/amd64/amd64/vmm.c
=
Hi
While working on a patch, i noticed that vmm_get_guest_faulttype was
incorrect for amd (VMM_MODE_RVI) cpus, apon further inspection realised
it was unused. Please see the patch below to remove it.
cheers
Adam
? div
Index: sys/arch/amd64/amd64/vmm.c
Hi
I have been working on this diff on and off for a while now, mlarkin was
able to give me lots of tips, but now i am stuck, so i thought i would
ask for nits, tips or even your doing it wrong.
The code below causes the vm to triple fault without the
((*pte & EPT_WB) == EPT_WB) check in vmx_mpro
Hi
I am experiencing packet loss and ENOBUFs, I have a program with
with two tap(4) interfaces and i am using kqueue(2) to determine
when and which tap interface to process the packet. I
email bugs@ over a month ago with no reply
https://marc.info/?l=openbsd-bugs&m=156229879107900&w=2
so i thought
Hi tech
The following diff allows vmd to specify which ports it can handle
or fix "XXX something better than a hardcoded list here, maybe configure via
vmd via the device list in vm create params?"
There are currently two implementation of bsearch in the kernel and this patch
would add a third, I
On Sun, Oct 8, 2017 at 6:03 AM, Theo de Raadt wrote:
> > Adam will correct me if I'm wrong, but his idea was to provide clock
> > emulation to the operating system running in userland (solo5/unikernel).
> > Perhaps vmd can make use of this interface too.
>
> But why does it matter if it knows the
On Sat, Oct 07, 2017 at 06:27:53PM +0800, Adam Steen wrote:
> On Sat, Oct 7, 2017 at 5:52 PM, Adam Steen wrote:
>
> > On Fri, Oct 06, 2017 at 03:58:18PM +0200, Mike Belopuhov wrote:
> > > Hi,
> > >
> > > An experimental change to use TSC as a timecounter so
On Sat, Oct 7, 2017 at 5:52 PM, Adam Steen wrote:
> On Fri, Oct 06, 2017 at 03:58:18PM +0200, Mike Belopuhov wrote:
> > Hi,
> >
> > An experimental change to use TSC as a timecounter source on a variety
> > of modern Intel and AMD CPUs has been just committed and e
On Fri, Oct 06, 2017 at 03:58:18PM +0200, Mike Belopuhov wrote:
> Hi,
>
> An experimental change to use TSC as a timecounter source on a variety
> of modern Intel and AMD CPUs has been just committed and enabled on
> OpenBSD/amd64 thanks to the work done by Adam Steen.
>
On Fri, Aug 25, 2017 at 12:43:44PM +0200, Mike Belopuhov wrote:
> On Fri, Aug 25, 2017 at 00:40 -0700, Mike Larkin wrote:
> > On Thu, Aug 24, 2017 at 12:39:33PM +0800, Adam Steen wrote:
> > > On Thu, Aug 24, 2017 at 2:35 AM, Mike Larkin wrote:
> > > > On Wed, Au
On Thu, Aug 24, 2017 at 2:35 AM, Mike Larkin wrote:
> On Wed, Aug 23, 2017 at 09:29:15PM +0800, Adam Steen wrote:
>> On Thu, Aug 17, 2017 at 12:19:28PM +0800, Adam Steen wrote:
>> > On Tue, Aug 8, 2017 at 10:12 PM, Mike Belopuhov wrote:
>> > > On Tue, Aug 08, 2
On Thu, Aug 17, 2017 at 12:19:28PM +0800, Adam Steen wrote:
> On Tue, Aug 8, 2017 at 10:12 PM, Mike Belopuhov wrote:
> > On Tue, Aug 08, 2017 at 08:18 +0800, Adam Steen wrote:
> >> On Mon, Jul 31, 2017 at 3:58 PM, Mike Belopuhov wrote:
> >> > On Mon, Jul 31, 2017 at
On Tue, Aug 8, 2017 at 10:12 PM, Mike Belopuhov wrote:
> On Tue, Aug 08, 2017 at 08:18 +0800, Adam Steen wrote:
>> On Mon, Jul 31, 2017 at 3:58 PM, Mike Belopuhov wrote:
>> > On Mon, Jul 31, 2017 at 09:48 +0800, Adam Steen wrote:
>> >> Ted Unangst wrote:
>>
On Mon, Jul 31, 2017 at 3:58 PM, Mike Belopuhov wrote:
> On Mon, Jul 31, 2017 at 09:48 +0800, Adam Steen wrote:
>> Ted Unangst wrote:
>> > we don't currently export this info, but we could add some sysctls. there's
>> > some cpufeatures stuff there, but
22 matches
Mail list logo
