Re: [Xen-devel] Mailing List Broken? Unsubscribed?
On 08/29/2017 04:53 PM, Gary R Hook wrote: Hm. For some odd reason I stopped receiving xen-devel mail a while ago. I never unsubscribed, never turned anything off (to the best of my knowledge). Now a co-worker is unable to subscribe. What's up with that? Any ideas? Looks like we may have a problem on our end... ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Mailing List Broken? Unsubscribed?
Hm. For some odd reason I stopped receiving xen-devel mail a while ago. I never unsubscribed, never turned anything off (to the best of my knowledge). Now a co-worker is unable to subscribe. What's up with that? Any ideas? Gary ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/x86: Add Xenoprofile support for AMD Family 17h
On 5/24/2017 1:43 AM, Jan Beulich wrote: On 23.05.17 at 23:51, <gary.h...@amd.com> wrote: On 5/23/2017 4:46 PM, Boris Ostrovsky wrote: On 05/23/2017 05:28 PM, Gary R Hook wrote: Signed-off-by: Gary R Hook <gary.h...@amd.com> --- xen/arch/x86/oprofile/nmi_int.c |4 1 file changed, 4 insertions(+) diff --git a/xen/arch/x86/oprofile/nmi_int.c b/xen/arch/x86/oprofile/nmi_int.c index 13534d491405..5ad48c12e515 100644 --- a/xen/arch/x86/oprofile/nmi_int.c +++ b/xen/arch/x86/oprofile/nmi_int.c @@ -419,6 +419,10 @@ static int __init nmi_init(void) model = _athlon_spec; cpu_type = "x86-64/family16h"; break; + case 0x17: +model = _amd_fam15h_spec; + cpu_type = "x86-64/family17h"; + break; } break; Have you actually tried this? I don't know whether oprofile still works since corresponding kernel patches that I am aware of are at least 5 years old. Yes, I was getting a complaint during boot. That's why I did it. Works a treat on my family 17 system :-) I think Boris meant more than just boot a system, i.e. whether you've actually used oprofile successfully with the change. My interpretation of the state of oprofile is that it's stagnant. Fron what I can tell, the future is 'perf'. I looked around, but could find nothing current for a project. Where does that leave us? Dealing with the "Initialization failed" message would not necessarily require properly installing handlers - we could also declare newer families unsupported and simply suppress the message in such cases. Note how on most Intel family 6 models code behaves in this very way. That would be even better, IMHO. What would we like to do? Btw, please also note the indentation issue your patch has (spaces vs tabs). I copied a line from above, which uses spaces. My bad, but the badly formatted code has been there for a while. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/x86: Add Xenoprofile support for AMD Family 17h
On 5/23/2017 4:46 PM, Boris Ostrovsky wrote: On 05/23/2017 05:28 PM, Gary R Hook wrote: Signed-off-by: Gary R Hook <gary.h...@amd.com> --- xen/arch/x86/oprofile/nmi_int.c |4 1 file changed, 4 insertions(+) diff --git a/xen/arch/x86/oprofile/nmi_int.c b/xen/arch/x86/oprofile/nmi_int.c index 13534d491405..5ad48c12e515 100644 --- a/xen/arch/x86/oprofile/nmi_int.c +++ b/xen/arch/x86/oprofile/nmi_int.c @@ -419,6 +419,10 @@ static int __init nmi_init(void) model = _athlon_spec; cpu_type = "x86-64/family16h"; break; + case 0x17: +model = _amd_fam15h_spec; + cpu_type = "x86-64/family17h"; + break; } break; Have you actually tried this? I don't know whether oprofile still works since corresponding kernel patches that I am aware of are at least 5 years old. Yes, I was getting a complaint during boot. That's why I did it. Works a treat on my family 17 system :-) I don't know whether the code is relevant (and if not, it should be removed, right?) but I don't like complaints, no matter how spurious. Thus, I minor patch. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen/x86: Add Xenoprofile support for AMD Family 17h
Signed-off-by: Gary R Hook <gary.h...@amd.com> --- xen/arch/x86/oprofile/nmi_int.c |4 1 file changed, 4 insertions(+) diff --git a/xen/arch/x86/oprofile/nmi_int.c b/xen/arch/x86/oprofile/nmi_int.c index 13534d491405..5ad48c12e515 100644 --- a/xen/arch/x86/oprofile/nmi_int.c +++ b/xen/arch/x86/oprofile/nmi_int.c @@ -419,6 +419,10 @@ static int __init nmi_init(void) model = _athlon_spec; cpu_type = "x86-64/family16h"; break; + case 0x17: +model = _amd_fam15h_spec; + cpu_type = "x86-64/family17h"; + break; } break; ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Questions about PVHv2/HVMlite
On 05/18/2017 03:16 AM, Roger Pau Monné wrote: So using your example, the config file should look like: extra = "root=/dev/xvda1 console=hvc0" kernel = "/root/64/vmlinuz-4.11.0-pvh+" ramdisk = "/root/64/initrd.img-4.11.0-pvh+" builder="hvm" device_model_version="none" memory = 4096 name = "sospv2" vcpus = 8 vif = [''] disk = ['phy:/dev/vg0/pvclient2,xvda,w'] Well, huzzah! amd@sospvclient2:~$ dmesg | grep -i xen [0.00] Hypervisor detected: Xen [0.00] Xen version 4.9. [0.00] Xen Platform PCI: unrecognised magic value [0.00] ACPI: RSDP 0x000FFFC0 24 (v02 Xen ) [0.00] ACPI: XSDT 0xFC007FA0 34 (v01 XenHVM HVML ) [0.00] ACPI: FACP 0xFC007D70 00010C (v05 XenHVM HVML ) [0.00] ACPI: DSDT 0xFC001050 006C9B (v05 XenHVM INTL 20140214) [0.00] ACPI: APIC 0xFC007E80 6C (v02 XenHVM HVML ) [0.00] Booting paravirtualized kernel on Xen PVH [0.00] xen: PV spinlocks enabled ^^^ This is a temporary interface, and it's not stable. "Stable" as in syntax and keywords are subject to change? Long term PVH guest should be created using "pvh=1", sadly this has not yet been implemented. Do I understand this to mean that using "pvh=1" in the config file hasn't been wired up to do everything needed to create a PVH guest? Is there more to be done besides turning that parameter into "builder='hvm" device_model_version="none"? Or, better yet, are there any design notes on this? Hope this helps, Roger. It seems it did. Thank you very much! ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Questions about PVHv2/HVMlite
On 5/16/2017 12:13 PM, Boris Ostrovsky wrote: On 05/16/2017 11:52 AM, Gary R Hook wrote: A PVH guest's config looks something like kernel="/root/64/vmlinux" May I ask from whence this kernel came? One of 4.11's rcs. Make sure you set CONFIG_XEN_PVH in your .config file. Please excuse my lack of clarity. I meant, on what filesystem does this kernel reside? dom0. Got it. So here's where I stand: I have pulled the torvalds repo, found the "Linux 4.11" commit to create a branch, verified that the config parameters suggested in a different post are all enabled (CONFIG_XEN, CONFIG_XEN_PVH, etc): they're all turned on. Built a kernel. Boot dom0 with it, and I have it in my guest, too (by booting the xvda in a PV guest and building it there... I'm hoping that's not a problem?). And the kernel and initrd are in /root/64 on dom0, per the above. I have this configuration (using a logical volume for my raw disk): extra = "root=/dev/xvda1 console=hvc0" kernel = "/root/64/vmlinuz-4.11.0-pvh+" ramdisk = "/root/64/initrd.img-4.11.0-pvh+" pvh = 1 device_model_version="none" memory = 4096 name = "sospv2" vcpus = 8 vif = [''] disk = ['phy:/dev/vg0/pvclient2,xvda,w'] It boots, but I get: $ dmesg | egrep -i 'xen|front' [0.00] Linux version 4.11.0-pvh+ (a...@sosxen.amd.com) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #10 SMP Tue May 16 16:36:14 CDT 2017 [0.00] Xen: [mem 0x-0x0009] usable [0.00] Xen: [mem 0x000a-0x000f] reserved [0.00] Xen: [mem 0x0010-0x] usable [0.00] Hypervisor detected: Xen [0.00] Booting paravirtualized kernel on Xen [0.00] Xen version: 4.9-rc (preserve-AD) [0.00] xen: PV spinlocks enabled No PVH indication. :-( And /var/log/xen/xl-sospv2.log has only a "waiting for domain to die" message in it. Please forgive my ignorance. What magic am I missing, or what have I not observed in this exchange? Guidance and expertise are greatly appreciated. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Questions about PVHv2/HVMlite
On 05/16/2017 04:36 AM, Andrew Cooper wrote: On 16/05/17 03:54, Boris Ostrovsky wrote: 2) Or, perhaps more importantly, what distinguishes said guest? Simplifying things a bit, it's an HVM guest that doesn't have device model (i.e. qemu) and which is booted directly (i.e. without hvmloader) The "booted directly" isn't relevant here. While being able to boot a PVH kernel directly is useful for development purposes, it is problematic for production purposes. For production systems, mounting of the guest filesystem and parsing of the guest kernel should happen in guest context, rather than dom0 context, to remove the security attack surfaces present in the PV guest model. Okay, stupid question time (again). I interpret the above to mean that the (referenced) disk image would be used to find a boot loader and run it (e.g. grub2). No pygrub, no special boot kernel such as appears to be needed by a PV guest. So if I install an OS (e.g. Ubuntu 14 or 16) onto a raw device (e.g. an LV on a VG on dom0), then build a 4.11 kernel and install it (on that xvda), that device would be bootable in a PVH guest. Yes/no? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Questions about PVHv2/HVMlite
On 05/15/2017 09:54 PM, Boris Ostrovsky wrote: Possibly stupid question time... On 05/15/2017 03:51 PM, Gary R Hook wrote: 2) Or, perhaps more importantly, what distinguishes said guest? Simplifying things a bit, it's an HVM guest that doesn't have device model (i.e. qemu) and which is booted directly (i.e. without hvmloader) So, an unmodified/stock kernel which would rely upon a typical (i.e. its own grub) bootloader. The magic comes from the PVH drivers? domU PVH support has been added in 4.11 kernel so you don't have it. You refer to the drivers? An PVH guest's config looks something like kernel="/root/64/vmlinux" May I ask from whence this kernel came? builder="hvm" device_model_version="none" extra="root=/dev/xvda1 console=hvc0" memory=8192 vcpus=2 name = "pvh" disk=['/root/virt/f22.img,raw,xvda,rw'] (note device_model_version) I saw the comment from I Roger. The overt statement of pvh intention would be a good thing. I am, at the moment, building a 4.11 kernel in a guest, hoping to boot it in PVH mode. Thanks, Gary ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Questions about PVHv2/HVMlite
So I've been slogging through online docs and the code, trying to understand where things stand with PVH. I think my primary questions are: 1) How do I identify a PVHv2/HVMlite guest? 2) Or, perhaps more importantly, what distinguishes said guest? I've got Xen 4.9 unstable built/installed/booted, and am running 4.10 kernels on my dom0 and guests. I've gotten a guest booted, and a basic Ubuntu 14.04 installed from a distro ISO onto a raw disk (a logical volume). All good. If I use the example file /etc/xen/example.hvm to define a simple guest (but no VGA: nographic=1), I see that I have a qemu instance running, which I expect, along with some threads: root 8523 1 0 14:31 ?00:00:03 /usr/local/lib/xen/bin/qemu-system-i386 -xen-domid 17 -chardev socket root 8779 2 0 14:31 ?00:00:00 [17.xvda-0] root 8780 2 0 14:31 ?00:00:00 [vif17.0-q0-gues] root 8781 2 0 14:31 ?00:00:00 [vif17.0-q0-deal] root 8782 2 0 14:31 ?00:00:00 [vif17.0-q1-gues] root 8783 2 0 14:31 ?00:00:00 [vif17.0-q1-deal] All seems good. Now, I've read through the doc at https://wiki.xen.org/wiki/Xen_Linux_PV_on_HVM_drivers and when I log into the above guest, and run dmesg | egrep -i 'xen|front' I get this output: [0.00] DMI: Xen HVM domU, BIOS 4.9-rc 04/25/2017 [0.00] Hypervisor detected: Xen [0.00] Xen version 4.9. [0.00] Xen Platform PCI: I/O protocol version 1 [0.00] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs. [0.00] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks. [0.00] ACPI: RSDP 0x000F6800 24 (v02 Xen ) [0.00] ACPI: XSDT 0xFC00A5B0 54 (v01 XenHVM HVML ) [0.00] ACPI: FACP 0xFC00A2D0 F4 (v04 XenHVM HVML ) [0.00] ACPI: DSDT 0xFC0012A0 008FAC (v02 XenHVM INTL 20140214) [0.00] ACPI: APIC 0xFC00A3D0 70 (v02 XenHVM HVML ) [0.00] ACPI: HPET 0xFC00A4C0 38 (v01 XenHVM HVML ) [0.00] ACPI: WAET 0xFC00A500 28 (v01 XenHVM HVML ) [0.00] ACPI: SSDT 0xFC00A530 31 (v02 XenHVM INTL 20140214) [0.00] ACPI: SSDT 0xFC00A570 31 (v02 XenHVM INTL 20140214) [0.00] Booting paravirtualized kernel on Xen HVM [0.00] xen: PV spinlocks enabled [0.00] xen:events: Using FIFO-based ABI [0.00] xen:events: Xen HVM callback vector for event delivery is enabled [0.156221] clocksource: xen: mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [0.156244] Xen: using vcpuop timer interface [0.156253] installing Xen timer for CPU 0 [0.157188] installing Xen timer for CPU 1 [0.248050] xenbus: xs_reset_watches failed: -38 [0.292506] xen: --> pirq=16 -> irq=9 (gsi=9) [0.464822] xen:balloon: Initialising balloon driver [0.468089] xen_balloon: Initialising balloon driver [0.476131] clocksource: Switched to clocksource xen [0.491289] xen: --> pirq=17 -> irq=8 (gsi=8) [0.491405] xen: --> pirq=18 -> irq=12 (gsi=12) [0.491511] xen: --> pirq=19 -> irq=1 (gsi=1) [0.491622] xen: --> pirq=20 -> irq=6 (gsi=6) [1.058087] xen: --> pirq=21 -> irq=24 (gsi=24) [1.058369] xen:grant_table: Grant tables using version 1 layout [1.091277] blkfront: xvda: flush diskcache: enabled; persistent grants: enabled; indirect descriptors: enabled; [1.100218] xen_netfront: Initialising Xen virtual ethernet driver [1.173298] xenbus_probe_frontend: Device with no driver: device/vkbd/0 [2.692397] systemd[1]: Detected virtualization xen. [3.453534] input: Xen Virtual Keyboard as /devices/virtual/input/input5 [3.454923] input: Xen Virtual Pointer as /devices/virtual/input/input6 Current linux kernels contains PV drivers, as I understand it. And based on the referenced document, the above messages would seem to imply that this is a PVHv2 guest here. At least according to what the referenced document explains as how to identify a PVH guest. But shouldn't this be an HVM guest, per the example config file? I get that the wiki is stale, so I gotta ask questions: How do I identify/characterize a a PVHv2/HVMlite guest on Xen 4.9? What, precisely, -defines- one of these (PVHv2) guests? Re: my prior question on documentation, how does the current tech preview define one of these hybrid guests? what are the salient aspects of said guests, and what is that we want to do to create one? My apologies if this is a simplistic question, but some clarification would be greatly appreciated. Gary ___ Xen-devel mailing
[Xen-devel] Stale Documentation
I'm reading through the page at https://wiki.xen.org/wiki/Linux_PVH, because, well, it claims that AMD hardware isn't supported. That bothers me. The date on the page is December 2014. Is there nothing more current to be found? The roadmap page is also stale. Is there an updated roadmap somewhere? Should I be looking at something besides the wiki? Primarily, my concerns are: 1) Has any information in that document (Linux_PVH) changed with respect to Xen 4.9-unstable? 2) PVH guests have been listed as "Preview" for over 2 years. IS there any updated documentation on PVH guests that I'm missing? I appreciate any insights/information anyone cares to offer. -- This is my day job. Follow me at: IG/Twitter/Facebook: @grhookphoto IG/Twitter/Facebook: @grhphotographer ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
