Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?

[Tinker]

On March 30, 2018 12:39 AM, Mike Larkin  wrote:
> On Thu, Mar 29, 2018 at 11:59:21AM -0400, Tinker wrote:
> > On March 29, 2018 11:36 PM, Mike Larkin mlar...@azathoth.net wrote:
> > ..
> > > > (Thread crossreferenced with
> > > > https://marc.info/?t=15223071333=1=2 .)
> > > > Thanks for reporting that you got X dummy working, though only on
> > > > baremetal but not in a VMM, the latter crashing at X start with
> > > > message "(EE) xf86OpenConsole: No console driver found".
> > > > ..
> > > > 
> > > > what do you hope to achieve here?
> > 
> > Xvfb + X11vnc gives you a fixed-resolution graphical remote terminal.
> > My hope is that dummy X + X11vnc will give the same but allow dynamic
> > resizing of the X framebuffer upon request to do so via Xrandr from a
> > VNC resize command.
> > 
> > This protocol interaction is what happens when you resize a VNC client
> > window.
> > 
> > This will be practical when you have one X/VNC server that you will
> > access from different computers with different screens and screen
> > resolutions, or you just benefit of dynamically resizing the X
> > framebuffer without needing to restart all your running X programs.
> > With Xvfb you'd be inclined to have some different launch scripts for
> > your different monitors and usecases, e.g. 1400x1000px, 2500x1500px and
> > 800x600px variants for surfing web, checking top, checking network
> > stats etc. . With dummy X you can just resize the same framebuffer as
> > you go along depending on needs from time to time.
> 
> I see. good luck.

So, I did get dummy X going.

Start command "Xorg +extension GLX +extension RANDR +extension RENDER
-config custom-xorg.conf", draft /etc/X11/custom-xorg.conf copied below.


VNC seems to not support dynamic resizing according to the definition i
suggested above.

"resizing" may mean that the xrandr CLI tool lets you choose between a
selection of 16:9 resolutions, and that the VNC client would resize its
framebuffer, instead of disconnecting.

I tried with two of the most popular VNC clients and they did *not*
handle the resize but instead disconnected. Not sure why.


On March 30, 2018 1:09 AM, Karel Gardas  wrote:
> On Thu, 29 Mar 2018 11:59:21 -0400
> Tinker t1...@protonmail.ch wrote:
> > On March 29, 2018 11:36 PM, Mike Larkin mlar...@azathoth.net wrote:
> > > what do you hope to achieve here?
> > 
> > Xvfb + X11vnc gives you a fixed-resolution graphical remote terminal.
> > 
> > My hope is that dummy X + X11vnc will give the same but allow dynamic
> > 
> > resizing of the X framebuffer upon request to do so via Xrandr from a
> > 
> > VNC resize command.
> 
> Have you tried Xvnc as a X server?

Not recently. What about it?


Are you aware of any tool that gives a "persistent" X environment that
also allows very convenient live resizing of the framebuffer?

Best regards,
Tinker

/etc/X11/custom-xorg.conf:

Section "ServerLayout"
  Identifier  "Layout0"
  Screen  0 "Screen0"
  InputDevice "Keyboard0" "CoreKeyboard"
  InputDevice "Mouse0""CorePointer"
EndSection

Section "ServerFlags"
  Option "DontVTSwitch"   "true"
  Option "AllowMouseOpenFail" "true"
  Option "PciForceNone"   "true"
  Option "AutoEnableDevices"  "false"
  Option "AutoAddDevices" "false"
EndSection

Section "Module"
  Load "dbe"
  Load "extmod"
  Load "freetype"
  Load "glx"
EndSection

Section "InputDevice"
  Identifier "Mouse0"
  Option "CorePointer" "true"
  Driver "void"
EndSection

Section "InputDevice"
  Identifier "Keyboard0"
  Option "CoreKeyboard" "true"
  Driver "void"
EndSection

Section "Device"
  Identifier "Device0"
  Driver "dummy"
  # Option "ConstantDPI" "true"
  # VideoRam 4096000
  # VideoRam 256000
  VideoRam 192000
EndSection

Section "Monitor"
  Identifier "Monitor0"
  HorizSync   5.0 - 1000.0
  VertRefresh 5.0 - 200.0
  # Modeline "1440x900"
  Option  "DPMS"
EndSection

Section "Screen"
  Identifier   "Screen0"
  Device   "Device0"
  Monitor  "Monitor0"
  DefaultDepth 24
  SubSection "Display"
# Viewport 0 0
Depth 24
# Modes "1440x900"
# Virtual 8192 4096
  EndSubSection
EndSection

Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?

[Karel Gardas]

On Thu, 29 Mar 2018 11:59:21 -0400
Tinker  wrote:

> On March 29, 2018 11:36 PM, Mike Larkin  wrote:
> > what do you hope to achieve here?
> 
> Xvfb + X11vnc gives you a fixed-resolution graphical remote terminal.
> 
> My hope is that dummy X + X11vnc will give the same but allow dynamic
> resizing of the X framebuffer upon request to do so via Xrandr from a
> VNC resize command.

Have you tried Xvnc as a X server?

Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?

[Mike Larkin]

On Thu, Mar 29, 2018 at 11:59:21AM -0400, Tinker wrote:
> On March 29, 2018 11:36 PM, Mike Larkin  wrote:
> ..
> > > (Thread crossreferenced with
> > > https://marc.info/?t=15223071333=1=2 .)
> > > 
> > > Thanks for reporting that you got X dummy working, though only on
> > > baremetal but not in a VMM, the latter crashing at X start with
> > > message "(EE) xf86OpenConsole: No console driver found".
> ..
> > what do you hope to achieve here?
> 
> Xvfb + X11vnc gives you a fixed-resolution graphical remote terminal.
> 
> My hope is that dummy X + X11vnc will give the same but allow dynamic
> resizing of the X framebuffer upon request to do so via Xrandr from a
> VNC resize command.
> 
> This protocol interaction is what happens when you resize a VNC client
> window.
> 
> This will be practical when you have one X/VNC server that you will
> access from different computers with different screens and screen
> resolutions, or you just benefit of dynamically resizing the X
> framebuffer without needing to restart all your running X programs.
> 
> With Xvfb you'd be inclined to have some different launch scripts for
> your different monitors and usecases, e.g. 1400x1000px, 2500x1500px and
> 800x600px variants for surfing web, checking top, checking network
> stats etc. . With dummy X you can just resize the same framebuffer as
> you go along depending on needs from time to time.
> 

I see. good luck.

Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?

[Tinker]

On March 29, 2018 11:36 PM, Mike Larkin  wrote:
..
> > (Thread crossreferenced with
> > https://marc.info/?t=15223071333=1=2 .)
> > 
> > Thanks for reporting that you got X dummy working, though only on
> > baremetal but not in a VMM, the latter crashing at X start with
> > message "(EE) xf86OpenConsole: No console driver found".
..
> what do you hope to achieve here?

Xvfb + X11vnc gives you a fixed-resolution graphical remote terminal.

My hope is that dummy X + X11vnc will give the same but allow dynamic
resizing of the X framebuffer upon request to do so via Xrandr from a
VNC resize command.

This protocol interaction is what happens when you resize a VNC client
window.

This will be practical when you have one X/VNC server that you will
access from different computers with different screens and screen
resolutions, or you just benefit of dynamically resizing the X
framebuffer without needing to restart all your running X programs.

With Xvfb you'd be inclined to have some different launch scripts for
your different monitors and usecases, e.g. 1400x1000px, 2500x1500px and
800x600px variants for surfing web, checking top, checking network
stats etc. . With dummy X you can just resize the same framebuffer as
you go along depending on needs from time to time.

Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?

[Mike Larkin]

On Thu, Mar 29, 2018 at 11:03:21AM -0400, Tinker wrote:
> On February 16, 2018 4:35 PM, Jiri B  wrote:
> > On Fri, Feb 16, 2018 at 12:19:44AM -0800, Mike Larkin wrote:
> > 
> > > Xvfb + x11vnc worked fine in the test I just did.
> > 
> > Yes, it does, thanks for confirmation.
> > 
> > I was curious why X11 'dummy' mode does not if it should be
> > used in environments without graphical card for headless X11
> > server.
> > 
> > Maybe it does not work as our xf86-video-dummy is old,
> > 
> > https://github.com/freedesktop/xorg-xf86-video-dummy/commit/87249af5faf85c8d093e910c069faa4db0aee843#diff-67e997bcfdac55191033d57a16d1408a
> > 
> > I'll stick to Xvfb for now and I'll give a try to build
> > newer xf86-video-dummy.
> > 
> > Jiri
> 
> (Thread crossreferenced with
> https://marc.info/?t=15223071333=1=2 .)
> 
> Thanks for reporting that you got X dummy working, though only on
> baremetal but not in a VMM, the latter crashing at X start  with
> message "(EE) xf86OpenConsole: No console driver found".
> 
> Do you have any idea what "No console driver found" here means, like,
> is it trying to open some hardware descriptor and it can't find it in
> VMM because VMM won't produce it while some PCI device on your
> baremetal would? Anyhow weird considering the X is supposed to not
> touch any hardware ("dummy" = graphics driver and "void" = mouse and
> keyboard drivers.)
> 
> Did you get any idea about the detail cause?
> 
> If any patch needs testing e.g. upgrade to latest
> https://github.com/freedesktop/xorg-xf86-video-dummy/ feel free to let
> me know.
> 
> Thanks,
> Tinker

what do you hope to achieve here?

Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?

[Tinker]

On February 16, 2018 4:35 PM, Jiri B  wrote:
> On Fri, Feb 16, 2018 at 12:19:44AM -0800, Mike Larkin wrote:
> 
> > Xvfb + x11vnc worked fine in the test I just did.
> 
> Yes, it does, thanks for confirmation.
> 
> I was curious why X11 'dummy' mode does not if it should be
> used in environments without graphical card for headless X11
> server.
> 
> Maybe it does not work as our xf86-video-dummy is old,
> 
> https://github.com/freedesktop/xorg-xf86-video-dummy/commit/87249af5faf85c8d093e910c069faa4db0aee843#diff-67e997bcfdac55191033d57a16d1408a
> 
> I'll stick to Xvfb for now and I'll give a try to build
> newer xf86-video-dummy.
> 
> Jiri

(Thread crossreferenced with
https://marc.info/?t=15223071333=1=2 .)

Thanks for reporting that you got X dummy working, though only on
baremetal but not in a VMM, the latter crashing at X start  with
message "(EE) xf86OpenConsole: No console driver found".

Do you have any idea what "No console driver found" here means, like,
is it trying to open some hardware descriptor and it can't find it in
VMM because VMM won't produce it while some PCI device on your
baremetal would? Anyhow weird considering the X is supposed to not
touch any hardware ("dummy" = graphics driver and "void" = mouse and
keyboard drivers.)

Did you get any idea about the detail cause?

If any patch needs testing e.g. upgrade to latest
https://github.com/freedesktop/xorg-xf86-video-dummy/ feel free to let
me know.

Thanks,
Tinker

Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?

[Jiri B]

On Fri, Feb 16, 2018 at 09:42:25PM +0200, Dumitru Mi?u Moldovan wrote:
> On 02/16/18 10:14, Jiri B wrote:
> 
> […]
> 
> > I'll try to clarify my use case further. I'd like to attach of a persistent
> > remote display session in screen/tmux-like manner.
> > 
> > IIUC a 'persistent' disqualifies X11 forwarding over SSH, and it
> > disqualifies usage of "remote" DISPLAY=$ip:$display too.
> > 
> > Thus, IIUC, X11 server needs to run on remote OS as well, and because the VM
> > does not have real graphical card, it does need a kind of fake X11 server.
> > 
> > Xvfb or X11 native 'dummy'-driver based solution should work, the graphics
> > itself can be later attached in screen/tmux-like manner via VNC for example.
> > 
> > Solutions I'm aware:
> > 
> > - X11 forwarding (not persistent)
> > - X11 with remote DISPLAY (not persistent)
> > - X11 'dummy' driver (not working in VMM VM)
> > - Xvfb (works but seems slower/obsoleted by X11 native 'dummy' driver)
> > 
> 
> Might want to add this to your list: https://www.xpra.org/ (have never
> tried it, but advertises itself as "screen for X11").

IIUC xpra uses 'dummy' X11 driver but I haven't checked too deeply
as there's no port for it right now.

Jiri

Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?

[Dumitru Mișu Moldovan]

On 02/16/18 10:14, Jiri B wrote:

[…]

> I'll try to clarify my use case further. I'd like to attach of a persistent
> remote display session in screen/tmux-like manner.
> 
> IIUC a 'persistent' disqualifies X11 forwarding over SSH, and it
> disqualifies usage of "remote" DISPLAY=$ip:$display too.
> 
> Thus, IIUC, X11 server needs to run on remote OS as well, and because the VM
> does not have real graphical card, it does need a kind of fake X11 server.
> 
> Xvfb or X11 native 'dummy'-driver based solution should work, the graphics
> itself can be later attached in screen/tmux-like manner via VNC for example.
> 
> Solutions I'm aware:
> 
> - X11 forwarding (not persistent)
> - X11 with remote DISPLAY (not persistent)
> - X11 'dummy' driver (not working in VMM VM)
> - Xvfb (works but seems slower/obsoleted by X11 native 'dummy' driver)
> 

Might want to add this to your list: https://www.xpra.org/ (have never
tried it, but advertises itself as "screen for X11").



signature.asc
Description: OpenPGP digital signature

Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?

[Jiri B]

On Fri, Feb 16, 2018 at 12:19:44AM -0800, Mike Larkin wrote:
> Xvfb + x11vnc worked fine in the test I just did.

Yes, it does, thanks for confirmation.

I was curious why X11 'dummy' mode does not if it should be
used in environments without graphical card for headless X11
server.

Maybe it does not work as our xf86-video-dummy is old,
https://github.com/freedesktop/xorg-xf86-video-dummy/commit/87249af5faf85c8d093e910c069faa4db0aee843#diff-67e997bcfdac55191033d57a16d1408a

I'll stick to Xvfb for now and I'll give a try to build
newer xf86-video-dummy.

Jiri

Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?

[Mike Larkin]

On Fri, Feb 16, 2018 at 03:14:49AM -0500, Jiri B wrote:
> On Thu, Feb 15, 2018 at 06:48:53PM -0800, Mike Larkin wrote:
> > > > what are you trying to accomplish?
> > > 
> > > A persistent remote display session, ie. xenodm->wm or users one 
> > > accessible
> > > via VNC with x11vnc.
> > > 
> > I found a solution to do this with about 1 minute of google searching. What
> > are you finding difficult?
> 
> I'm not sure I can follow.
> 
> I would be happy to listen for your proposal for my use case.
> 
> I'll try to clarify my use case further. I'd like to attach of a persistent
> remote display session in screen/tmux-like manner.
> 
> IIUC a 'persistent' disqualifies X11 forwarding over SSH, and it
> disqualifies usage of "remote" DISPLAY=$ip:$display too.
> 
> Thus, IIUC, X11 server needs to run on remote OS as well, and because the VM
> does not have real graphical card, it does need a kind of fake X11 server.
> 
> Xvfb or X11 native 'dummy'-driver based solution should work, the graphics
> itself can be later attached in screen/tmux-like manner via VNC for example.
> 
> Solutions I'm aware:
> 
> - X11 forwarding (not persistent)
> - X11 with remote DISPLAY (not persistent)
> - X11 'dummy' driver (not working in VMM VM)
> - Xvfb (works but seems slower/obsoleted by X11 native 'dummy' driver)
> 
> Thank you for help.
> 
> Jiri
> 
> 

Xvfb + x11vnc worked fine in the test I just did.

Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?

[Jiri B]

On Thu, Feb 15, 2018 at 06:48:53PM -0800, Mike Larkin wrote:
> > > what are you trying to accomplish?
> > 
> > A persistent remote display session, ie. xenodm->wm or users one accessible
> > via VNC with x11vnc.
> > 
> I found a solution to do this with about 1 minute of google searching. What
> are you finding difficult?

I'm not sure I can follow.

I would be happy to listen for your proposal for my use case.

I'll try to clarify my use case further. I'd like to attach of a persistent
remote display session in screen/tmux-like manner.

IIUC a 'persistent' disqualifies X11 forwarding over SSH, and it
disqualifies usage of "remote" DISPLAY=$ip:$display too.

Thus, IIUC, X11 server needs to run on remote OS as well, and because the VM
does not have real graphical card, it does need a kind of fake X11 server.

Xvfb or X11 native 'dummy'-driver based solution should work, the graphics
itself can be later attached in screen/tmux-like manner via VNC for example.

Solutions I'm aware:

- X11 forwarding (not persistent)
- X11 with remote DISPLAY (not persistent)
- X11 'dummy' driver (not working in VMM VM)
- Xvfb (works but seems slower/obsoleted by X11 native 'dummy' driver)

Thank you for help.

Jiri

Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?

[Mike Larkin]

On Thu, Feb 15, 2018 at 07:31:07PM -0500, Jiri B wrote:
> On Thu, Feb 15, 2018 at 04:18:33PM -0800, Mike Larkin wrote:
> > On Thu, Feb 15, 2018 at 07:10:26PM -0500, Jiri B wrote:
> > > Is it possible to run 'dummy' based X11 (should be better that Xvfb)[1] 
> > > inside
> > > VMM VM?
> > > 
> > 
> > what are you trying to accomplish?
> 
> A persistent remote display session, ie. xenodm->wm or users one accessible
> via VNC with x11vnc.
> 
> Jiri

I found a solution to do this with about 1 minute of google searching. What
are you finding difficult?

Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?

[Jiri B]

On Thu, Feb 15, 2018 at 04:18:33PM -0800, Mike Larkin wrote:
> On Thu, Feb 15, 2018 at 07:10:26PM -0500, Jiri B wrote:
> > Is it possible to run 'dummy' based X11 (should be better that Xvfb)[1] 
> > inside
> > VMM VM?
> > 
> 
> what are you trying to accomplish?

A persistent remote display session, ie. xenodm->wm or users one accessible
via VNC with x11vnc.

Jiri

Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?

[Mike Larkin]

On Thu, Feb 15, 2018 at 07:10:26PM -0500, Jiri B wrote:
> Is it possible to run 'dummy' based X11 (should be better that Xvfb)[1] inside
> VMM VM?
> 

what are you trying to accomplish?

> $ Xorg -noreset +extension GLX +extension RANDR +extension RENDER -logfile 
> ./10.log -config ./xorg.conf :10
> (EE)
> Fatal server error:
> (EE) xf86OpenConsole: No console driver found
> Supported drivers: wscons
> Check your kernel's console driver configuration and /dev entries(EE)
> (EE)
> Please consult the The X.Org Foundation support
>  at http://wiki.x.org
>  for help.
> (EE) Please also check the log file at "./10.log" for additional information.
> (EE)
> (EE) Server terminated with error (1). Closing log file.
> 
> $ cat 10.log
> [62.900] (--) checkDevMem: using aperture driver /dev/xf86
> [62.969] (EE) 
> Fatal server error:
> [62.970] (EE) xf86OpenConsole: No console driver found
> Supported drivers: wscons
> Check your kernel's console driver configuration and /dev entries(EE) 
> [62.973] (EE) 
> Please consult the The X.Org Foundation support 
>  at http://wiki.x.org
>  for help. 
> [62.974] (EE) Please also check the log file at "./10.log" for additional 
> information.
> [62.976] (EE) 
> [62.992] (EE) Server terminated with error (1). Closing log file.
> 
> xorg.conf is from https://xpra.org/xorg.conf (attached in the end of the 
> mail).
> 
> But same xorg.conf and same command work OK on headless baremetal.
> 
> [1] http://xpra.org/trac/wiki/Xdummy
> [2] https://xpra.org/xorg.conf
> 
> Jiri
> 
> - from host
> 
> OpenBSD 6.2-current (GENERIC.MP) #6: Tue Feb 13 20:16:11 MST 2018
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8564375552 (8167MB)
> avail mem = 8297807872 (7913MB)
> enter_shared_special_pages: entered idt page va 0x8001 pa 
> 0x1d5a000
> enter_shared_special_pages: entered kutext page va 0x81831000 pa 
> 0x1831000
> enter_shared_special_pages: entered kutext page va 0x81832000 pa 
> 0x1832000
> enter_shared_special_pages: entered kutext page va 0x81833000 pa 
> 0x1833000
> enter_shared_special_pages: entered kudata page va 0x81ac9000 pa 
> 0x1ac9000
> cpu_enter_pages: entered tss+gdt page at va 0x81abd000 pa 0x1abd000
> cpu_enter_pages: entered t.stack page at va 0x81abe000 pa 0x1abe000
> cpu_enter_pages: cif_tss.tss_rsp0 = 0x81abe3e0
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9f000 (68 entries)
> bios0: vendor American Megatrends Inc. version "1.1" date 05/27/2010
> bios0: Supermicro X8SIL
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S1 S4 S5
> acpi0: tables DSDT FACP APIC MCFG OEMB HPET GSCI DMAR SSDT
> acpi0: wakeup devices P0P1(S4) P0P3(S4) P0P4(S4) P0P5(S4) P0P6(S4) BR1E(S4) 
> USB0(S4) USB1(S4) USB2(S4) USB3(S4) USB4(S4) USB5(S4) USB6(S4) GBE_(S4) 
> BR20(S4) BR21(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> lapic_map: entered lapic page va 0x81ab2000 pa 0xfee0
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Xeon(R) CPU L3426 @ 1.87GHz, 1866.93 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> acpitimer0: recalibrated TSC frequency 189986 Hz
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 133MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> cpu1 at mainbus0cpu_enter_pages: entered tss+gdt page at va 
> 0x800021fff000 pa 0x10f7ab000
> cpu_enter_pages: entered t.stack page at va 0x80002200 pa 0x10f7ac000
> cpu_enter_pages: cif_tss.tss_rsp0 = 0x8000220003e0
> : apid 2 (application processor)
> cpu1: Intel(R) Xeon(R) CPU L3426 @ 1.87GHz, 1866.67 MHz
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0cpu_enter_pages: entered tss+gdt page at va 
> 0x80002201 pa 0x10f7b6000
> cpu_enter_pages: entered t.stack page at va 0x800022011000 pa 0x10f7b7000
> cpu_enter_pages: cif_tss.tss_rsp0 = 0x8000220113e0
> : apid 4 (application processor)
> cpu2: Intel(R) Xeon(R) CPU L3426 @ 1.87GHz, 1866.67 MHz
> cpu2: 
>