Re: [Xen-devel] [PATCH v2 1/2] x86/acpi: add retrieval function for rsdp address

[Rafael J. Wysocki]

On Wed, Jan 31, 2018 at 4:43 PM, Andy Shevchenko
 wrote:
> On Mon, Jan 29, 2018 at 5:02 AM, Rafael J. Wysocki  wrote:
>> On Sun, Jan 28, 2018 at 4:04 PM, Andy Shevchenko
>>  wrote:
>>> On Fri, Jan 26, 2018 at 8:21 PM, Juergen Gross  wrote:
 On 26/01/18 19:08, Andy Shevchenko wrote:
> On Thu, Jan 25, 2018 at 4:36 PM, Juergen Gross  wrote:
>
> The problem with weak functions that we can't have more than one
> implementation per kernel while we would like to built several code
> paths.
>
> I have stumbled on the similar stuff and realize that.
>
> Perhaps, one of the solution is to have an additional struct under
> x86_init to alternate ACPI related stuff.

 I think we can go that route when another user of that interface is
 appearing.
>>>
>>> Why not to establish the struct? At least this route I would like to
>>> go with [1].
>>>
>>> [1]: https://lkml.org/lkml/2018/1/17/834
>>
>> Maybe I'm a bit slow today, but care to explain what exactly you mean?
>
> Instead of declaring function as __weak, establish a new struct for
> ACPI related stubs and incorporate it into x86_init.
>
> That is my proposal. I think I would go this way in my case where I
> need to treat differently ACPI HW reduced initialization of legacy
> devices.

IOW you'd like to have a set of ACPI init callbacks that could be
defined by an arch, right?

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [bug]xen 4.10 + dom0 4.15 couldn't boot up

[Juergen Gross]

On 01/02/18 07:20, Zhang, Xiong Y wrote:
> This is the message with debug=y
> Xen 4.11-unstable
> (XEN) Xen version 4.11-unstable (test@) (gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 
> 5.4.0 20160609) debug=y  Tue Jan 30 02:38:14 CST 2018
> (XEN) Latest ChangeSet: Wed Jan 24 12:01:55 2018 + git:1252e28
> (XEN) Bootloader: GRUB 2.02~beta2-36ubuntu3.8
> (XEN) Command line: placeholder loglvl=all guest_loglvl=all com1=115200,8n1 
> console=com1,vga
> (XEN) Xen image load base address: 0
> (XEN) Video information:
> (XEN)  VGA is text mode 80x25, font 8x16
> (XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
> (XEN) Disc information:
> (XEN)  Found 1 MBR signatures
> (XEN)  Found 1 EDD information structures
> (XEN) Xen-e820 RAM map:
> (XEN)   - 0009c800 (usable)
> (XEN)  0009c800 - 000a (reserved)
> (XEN)  000e - 0010 (reserved)
> (XEN)  0010 - c9802000 (usable)
> (XEN)  c9802000 - c9803000 (ACPI NVS)
> (XEN)  c9803000 - c982d000 (reserved)
> (XEN)  c982d000 - c9881000 (usable)
> (XEN)  c9881000 - ca082000 (reserved)
> (XEN)  ca082000 - d71d6000 (usable)
> (XEN)  d71d6000 - d73fc000 (reserved)
> (XEN)  d73fc000 - d744a000 (ACPI data)
> (XEN)  d744a000 - d7abf000 (ACPI NVS)
> (XEN)  d7abf000 - d7fff000 (reserved)
> (XEN)  d7fff000 - d800 (usable)
> (XEN)  d800 - d810 (reserved)
> (XEN)  f800 - fc00 (reserved)
> (XEN)  fe00 - fe011000 (reserved)
> (XEN)  fec0 - fec01000 (reserved)
> (XEN)  fee0 - fee01000 (reserved)
> (XEN)  ff00 - 0001 (reserved)
> (XEN)  0001 - 00042200 (usable)
> (XEN) New Xen image base address: 0xd6a0
> (XEN) ACPI: RSDP 000F05B0, 0024 (r2 DELL  )
> (XEN) ACPI: XSDT D741C0A0, 00C4 (r1 DELLCBX3 1072009 AMI 10013)
> (XEN) ACPI: FACP D743E770, 010C (r5 DELLCBX3 1072009 AMI 10013)
> (XEN) ACPI: DSDT D741C1F8, 22574 (r2 DELLCBX3 1072009 INTL 20120913)
> (XEN) ACPI: FACS D7ABEF80, 0040
> (XEN) ACPI: APIC D743E880, 0084 (r3 DELLCBX3 1072009 AMI 10013)
> (XEN) ACPI: FPDT D743E908, 0044 (r1 DELLCBX3 1072009 AMI 10013)
> (XEN) ACPI: FIDT D743E950, 009C (r1 DELLCBX3 1072009 AMI 10013)
> (XEN) ACPI: MCFG D743E9F0, 003C (r1 DELLCBX3 1072009 MSFT   97)
> (XEN) ACPI: HPET D743EA30, 0038 (r1 DELLCBX3 1072009 AMI.5000B)
> (XEN) ACPI: SSDT D743EA68, 036D (r1 SataRe SataTabl 1000 INTL 20120913)
> (XEN) ACPI: SSDT D743EDD8, 53B2 (r2 SaSsdt  SaSsdt  3000 INTL 20120913)
> (XEN) ACPI: UEFI D7444190, 0042 (r10 0)
> (XEN) ACPI: LPIT D74441D8, 0094 (r1 INTEL   SKL0 MSFT   5F)
> (XEN) ACPI: SSDT D7444270, 0248 (r2 INTEL  sensrhub0 INTL 20120913)
> (XEN) ACPI: SSDT D7B8, 2BAE (r2 INTEL  PtidDevc 1000 INTL 20120913)
> (XEN) ACPI: SSDT D7447068, 0BE3 (r2 INTEL  Ther_Rvp 1000 INTL 20120913)
> (XEN) ACPI: DBGP D7447C50, 0034 (r1 INTEL  0 MSFT   5F)
> (XEN) ACPI: DBG2 D7447C88, 0054 (r0 INTEL  0 MSFT   5F)
> (XEN) ACPI: SSDT D7447CE0, 0613 (r2  INTEL DELL__MT0 INTL 20120913)
> (XEN) ACPI: SSDT D74482F8, 0E73 (r2 CpuRef  CpuSsdt 3000 INTL 20120913)
> (XEN) ACPI: SLIC D7449170, 0176 (r3 DELLCBX3 1072009 MSFT10013)
> (XEN) ACPI: DMAR D74492E8, 00A8 (r1 INTEL  SKL 1 INTL1)
> (XEN) ACPI: ASF! D7449390, 00A5 (r32 INTEL   HCG1 TFSMF4240)
> (XEN) System RAM: 16265MB (16655644kB)
> (XEN) No NUMA configuration found
> (XEN) Faking a node at -00042200
> (XEN) Domain heap initialised
> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 94 (0x5e), Stepping 3 (raw 
> 000506e3)
> (XEN) found SMP MP-table at 000fcdd0
> (XEN) DMI 2.8 present.
> (XEN) Using APIC driver default
> (XEN) ACPI: PM-Timer IO Port: 0x1808 (32 bits)
> (XEN) ACPI: v5 SLEEP INFO: control[1:1804], status[1:1800]
> (XEN) ACPI: Invalid sleep control/status register data: 0:0x8:0x3 0:0x8:0x3
> (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:1804,1:0], pm1x_evt[1:1800,1:0]
> (XEN) ACPI: 32/64X FACS address mismatch in FADT - d7abef80/, 
> using 32
> (XEN) ACPI: wakeup_vec[d7abef8c], vec_size[20]
> (XEN) ACPI: Local APIC address 0xfee0
> (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
> (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
> (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
> (XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
> (XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
> (XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
> (XEN) ACPI: 

Re: [Xen-devel] [PATCH V2] tests/xen-access: disable CR4 write events on application exit

[Razvan Cojocaru]

On 01/29/2018 11:48 PM, Razvan Cojocaru wrote:
> On exit, xen-access did not unsubscribe from CR4 write vm_events,
> potentially leaving the guest stuck.
> 
> Signed-off-by: Razvan Cojocaru 
> 
> ---
> Changes since V1:
>  - Made all the ignored parameters of xc_monitor_write_ctrlreg() zeroes.
> ---
>  tools/tests/xen-access/xen-access.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/tools/tests/xen-access/xen-access.c 
> b/tools/tests/xen-access/xen-access.c
> index 9d960e2109..a081168dea 100644
> --- a/tools/tests/xen-access/xen-access.c
> +++ b/tools/tests/xen-access/xen-access.c
> @@ -654,6 +654,8 @@ int main(int argc, char *argv[])
>  rc = xc_monitor_cpuid(xch, domain_id, 0);
>  if ( desc_access )
>  rc = xc_monitor_descriptor_access(xch, domain_id, 0);
> +if ( write_ctrlreg_cr4 )
> +rc = xc_monitor_write_ctrlreg(xch, domain_id, 
> VM_EVENT_X86_CR4, 0, 0, 0, 0);
>  
>  if ( privcall )
>  rc = xc_monitor_privileged_call(xch, domain_id, 0);
> 

Tamas, could we get an ack (or otherwise) on this? This is probably
small and out-of-the-way enough to make it in with the proper acks even
with all the Spectre / Meltdown activity.


Thanks,
Razvan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] kernel-ml-4.15.0-1.el7.elrepo.x86_64 doesn't boot as Xen PV domU

[Juergen Gross]

On 01/02/18 01:17, Michael Young wrote:
> On Wed, 31 Jan 2018, Michael Young wrote:
> 
>> (XEN) Guest stack trace from rsp=82203e20:
>> (XEN)      
>> 81036a89
>> (XEN)    0001e030 00010092 82203e68
>> e02b
>> (XEN)      
>> 
> 
> I have just spotted this is truncated. The full Guest stack trace is
> 
> (XEN) Guest stack trace from rsp=82203e20:
> (XEN)      
> 81036a89
> (XEN)    0001e030 00010092 82203e68
> e02b
> (XEN)      
> 
> (XEN)    823777e0  
> 
> (XEN)      823777e0
> 82203f08
> (XEN)    82203f0c 82203f04 82203f00
> 82203f1c
> (XEN)    81037673 82203f10 82203f14
> 82203f18
> (XEN)    3024  8008
> 
> (XEN)    81029d10  
> 
> (XEN)      82727b49
> 
> (XEN)      
> 
> (XEN)      
> 
> (XEN)      
> 
> (XEN)      
> 
> (XEN)      
> 
> (XEN)    0f0060c0c748 c305 
> 
> (XEN)      
> 
> (XEN)      
> 
> (XEN)      
> 
> (XEN)      
> 
> 
> Some addresses from this that look like they might be relevant are
> 0x82203e20 :    add    %al,(%rax)
> 0x81036a89 :
>     mov    %gs:0x28,%rax

Hmm, my compiler doesn't generate this instruction here. OTOH it does so
in many other functions, but those seem to be called only later.

Seems as if it would be a good idea to setup the GDT and %gs segment as
early as possible.

I'll have a try how far we can move the call of xen_setup_gdt() up in
the boot process.


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3] libxc: don't fail domain creation when unpacking initrd fails

[Jan Beulich]

At least Linux kernels have been able to work with gzip-ed initrd for
quite some time; initrd compressed with other methods aren't even being
attempted to unpack. Furthermore the unzip-ing routine used here isn't
capable of dealing with various forms of concatenated files, each of
which was gzip-ed separately (it is this particular case which has been
the source of observed VM creation failures).

Hence, if unpacking fails, simply hand the compressed blob to the guest
as is.

Signed-off-by: Jan Beulich 
---
v3: Re-base. Add missing blank.
v2: Almost full re-work, hopefully better meeting Ian's taste.

--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -298,7 +298,6 @@ int xc_dom_mem_init(struct xc_dom_image
 int xc_dom_kernel_check_size(struct xc_dom_image *dom, size_t sz);
 int xc_dom_kernel_max_size(struct xc_dom_image *dom, size_t sz);
 
-int xc_dom_module_check_size(struct xc_dom_image *dom, size_t sz);
 int xc_dom_module_max_size(struct xc_dom_image *dom, size_t sz);
 
 int xc_dom_devicetree_max_size(struct xc_dom_image *dom, size_t sz);
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -314,22 +314,6 @@ int xc_dom_kernel_check_size(struct xc_d
 return 0;
 }
 
-int xc_dom_module_check_size(struct xc_dom_image *dom, size_t sz)
-{
-/* No limit */
-if ( !dom->max_module_size )
-return 0;
-
-if ( sz > dom->max_module_size )
-{
-xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
- "module image too large");
-return 1;
-}
-
-return 0;
-}
-
 /*  */
 /* read files, copy memory blocks, with transparent gunzip  */
 
@@ -1026,16 +1010,28 @@ static int xc_dom_build_module(struct xc
 char name[10];
 
 if ( !dom->modules[mod].seg.vstart )
-{
 unziplen = xc_dom_check_gzip(dom->xch,
  dom->modules[mod].blob, 
dom->modules[mod].size);
-if ( xc_dom_module_check_size(dom, unziplen) != 0 )
-unziplen = 0;
-}
 else
 unziplen = 0;
 
-modulelen = unziplen ? unziplen : dom->modules[mod].size;
+modulelen = max(unziplen, dom->modules[mod].size);
+if ( dom->max_module_size )
+{
+if ( unziplen && modulelen > dom->max_module_size )
+{
+modulelen = min(unziplen, dom->modules[mod].size);
+if ( unziplen > modulelen )
+unziplen = 0;
+}
+if ( modulelen > dom->max_module_size )
+{
+xc_dom_panic(dom->xch, XC_INVALID_KERNEL,
+ "module %u image too large", mod);
+goto err;
+}
+}
+
 snprintf(name, sizeof(name), "module%u", mod);
 if ( xc_dom_alloc_segment(dom, >modules[mod].seg, name,
   dom->modules[mod].seg.vstart, modulelen) != 0 )
@@ -1050,11 +1046,18 @@ static int xc_dom_build_module(struct xc
 if ( unziplen )
 {
 if ( xc_dom_do_gunzip(dom->xch, dom->modules[mod].blob, 
dom->modules[mod].size,
-  modulemap, modulelen) == -1 )
+  modulemap, unziplen) != -1 )
+return 0;
+if ( dom->modules[mod].size > modulelen )
 goto err;
 }
-else
-memcpy(modulemap, dom->modules[mod].blob, dom->modules[mod].size);
+
+/* Fall back to handing over the raw blob. */
+memcpy(modulemap, dom->modules[mod].blob, dom->modules[mod].size);
+/* If an unzip attempt was made, the buffer may no longer be all zero. */
+if ( unziplen > dom->modules[mod].size )
+memset(modulemap + dom->modules[mod].size, 0,
+   unziplen - dom->modules[mod].size);
 
 return 0;
 




___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Problem with IOMEM and domain reboot

[Oleksandr Andrushchenko]

Ian, Wei,

could you please take a look at the below?

Thank you,

Oleksandr


On 12/20/2017 06:27 PM, Oleksandr Andrushchenko wrote:

Hi, all!

While trying to reboot a domain which has iomem configured
(we are passing through some devices), I found an issue,
that after domain reboot those iomem's are incorrectly re-mapped,
e.g. for the configuration snippet below fe960 -> 0.

Part of the domain config I use:
iomem=[
    "0xfd010,1@0xfd000",
    "fe960,8",
]

During domain creation:
libxl_create.c:210:libxl__domain_build_info_setdefault: iomem gfn 
fd000 start fd010
libxl_create.c:210:libxl__domain_build_info_setdefault: iomem gfn 
 start fe960


which means that for fe960 initial value was set to LIBXL_INVALID_GFN
and then on domain configuration, 
tools/libxl/libxl_create.c:libxl__domain_build_info_setdefault:


    for (i = 0 ; i < b_info->num_iomem; i++)
    if (b_info->iomem[i].gfn == LIBXL_INVALID_GFN)
    b_info->iomem[i].gfn = b_info->iomem[i].start;

made that GFN for fe960 to be set to the correct value.

But during domain reboot I see that 
tools/xl/xl_vmcontrol.c:reload_domain_config

tries to replicate configuration from the original domain config
being rebooted, but that leads to iomem's GFN to be set to 0 (if 
configured
in form [IOMEM_START,NUM_PAGES], but for [IOMEM_START,NUM_PAGES[@GFN] 
it is ok):


iomem gfn fd000 start fd010
iomem gfn 0 start fe960

Thus, further domain restart procedure leads to invalid mapping, e.g. 
fe960 -> 0.


I created a patch which allowed me to reboot the domain, but I would love
to hear comments on what would be the proper fix.

Thank you,
Oleksandr




___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [bug]xen 4.10 + dom0 4.15 couldn't boot up

[Zhang, Xiong Y]

This is the message with debug=y
Xen 4.11-unstable
(XEN) Xen version 4.11-unstable (test@) (gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 
5.4.0 20160609) debug=y  Tue Jan 30 02:38:14 CST 2018
(XEN) Latest ChangeSet: Wed Jan 24 12:01:55 2018 + git:1252e28
(XEN) Bootloader: GRUB 2.02~beta2-36ubuntu3.8
(XEN) Command line: placeholder loglvl=all guest_loglvl=all com1=115200,8n1 
console=com1,vga
(XEN) Xen image load base address: 0
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)   - 0009c800 (usable)
(XEN)  0009c800 - 000a (reserved)
(XEN)  000e - 0010 (reserved)
(XEN)  0010 - c9802000 (usable)
(XEN)  c9802000 - c9803000 (ACPI NVS)
(XEN)  c9803000 - c982d000 (reserved)
(XEN)  c982d000 - c9881000 (usable)
(XEN)  c9881000 - ca082000 (reserved)
(XEN)  ca082000 - d71d6000 (usable)
(XEN)  d71d6000 - d73fc000 (reserved)
(XEN)  d73fc000 - d744a000 (ACPI data)
(XEN)  d744a000 - d7abf000 (ACPI NVS)
(XEN)  d7abf000 - d7fff000 (reserved)
(XEN)  d7fff000 - d800 (usable)
(XEN)  d800 - d810 (reserved)
(XEN)  f800 - fc00 (reserved)
(XEN)  fe00 - fe011000 (reserved)
(XEN)  fec0 - fec01000 (reserved)
(XEN)  fee0 - fee01000 (reserved)
(XEN)  ff00 - 0001 (reserved)
(XEN)  0001 - 00042200 (usable)
(XEN) New Xen image base address: 0xd6a0
(XEN) ACPI: RSDP 000F05B0, 0024 (r2 DELL  )
(XEN) ACPI: XSDT D741C0A0, 00C4 (r1 DELLCBX3 1072009 AMI 10013)
(XEN) ACPI: FACP D743E770, 010C (r5 DELLCBX3 1072009 AMI 10013)
(XEN) ACPI: DSDT D741C1F8, 22574 (r2 DELLCBX3 1072009 INTL 20120913)
(XEN) ACPI: FACS D7ABEF80, 0040
(XEN) ACPI: APIC D743E880, 0084 (r3 DELLCBX3 1072009 AMI 10013)
(XEN) ACPI: FPDT D743E908, 0044 (r1 DELLCBX3 1072009 AMI 10013)
(XEN) ACPI: FIDT D743E950, 009C (r1 DELLCBX3 1072009 AMI 10013)
(XEN) ACPI: MCFG D743E9F0, 003C (r1 DELLCBX3 1072009 MSFT   97)
(XEN) ACPI: HPET D743EA30, 0038 (r1 DELLCBX3 1072009 AMI.5000B)
(XEN) ACPI: SSDT D743EA68, 036D (r1 SataRe SataTabl 1000 INTL 20120913)
(XEN) ACPI: SSDT D743EDD8, 53B2 (r2 SaSsdt  SaSsdt  3000 INTL 20120913)
(XEN) ACPI: UEFI D7444190, 0042 (r10 0)
(XEN) ACPI: LPIT D74441D8, 0094 (r1 INTEL   SKL0 MSFT   5F)
(XEN) ACPI: SSDT D7444270, 0248 (r2 INTEL  sensrhub0 INTL 20120913)
(XEN) ACPI: SSDT D7B8, 2BAE (r2 INTEL  PtidDevc 1000 INTL 20120913)
(XEN) ACPI: SSDT D7447068, 0BE3 (r2 INTEL  Ther_Rvp 1000 INTL 20120913)
(XEN) ACPI: DBGP D7447C50, 0034 (r1 INTEL  0 MSFT   5F)
(XEN) ACPI: DBG2 D7447C88, 0054 (r0 INTEL  0 MSFT   5F)
(XEN) ACPI: SSDT D7447CE0, 0613 (r2  INTEL DELL__MT0 INTL 20120913)
(XEN) ACPI: SSDT D74482F8, 0E73 (r2 CpuRef  CpuSsdt 3000 INTL 20120913)
(XEN) ACPI: SLIC D7449170, 0176 (r3 DELLCBX3 1072009 MSFT10013)
(XEN) ACPI: DMAR D74492E8, 00A8 (r1 INTEL  SKL 1 INTL1)
(XEN) ACPI: ASF! D7449390, 00A5 (r32 INTEL   HCG1 TFSMF4240)
(XEN) System RAM: 16265MB (16655644kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at -00042200
(XEN) Domain heap initialised
(XEN) CPU Vendor: Intel, Family 6 (0x6), Model 94 (0x5e), Stepping 3 (raw 
000506e3)
(XEN) found SMP MP-table at 000fcdd0
(XEN) DMI 2.8 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x1808 (32 bits)
(XEN) ACPI: v5 SLEEP INFO: control[1:1804], status[1:1800]
(XEN) ACPI: Invalid sleep control/status register data: 0:0x8:0x3 0:0x8:0x3
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:1804,1:0], pm1x_evt[1:1800,1:0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT - d7abef80/, 
using 32
(XEN) ACPI: wakeup_vec[d7abef8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee0
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
(XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-119
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 

[Xen-devel] [libvirt test] 118468: tolerable all pass - PUSHED

[osstest service owner]

flight 118468 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118468/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118447
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118447
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118447
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  c7f6d4d01063a1c445f2b9cf8af11f8e8c36db43
baseline version:
 libvirt  f2e16994f7d660a54daba1059441dc0dcf4d9cbd

Last test of basis   118447  2018-01-30 04:20:27 Z2 days
Testing same since   118468  2018-01-31 06:24:06 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Peter Krempa 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary

[Xen-devel] [xen-4.8-testing test] 118465: tolerable FAIL - PUSHED

[osstest service owner]

flight 118465 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118465/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-xtf-amd64-amd64-5 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 118446 pass 
in 118465
 test-xtf-amd64-amd64-4 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 118446 pass 
in 118465
 test-xtf-amd64-amd64-3   49 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 118446
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
pass in 118446

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-2  49 xtf/test-hvm64-lbr-tsx-vmentry fail like 118170
 test-xtf-amd64-amd64-1  49 xtf/test-hvm64-lbr-tsx-vmentry fail like 118170
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118170
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118170
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 118170
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118170
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118170
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 118170
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118170
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 118170
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118170
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 build-i386-prev   7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install 

Re: [Xen-devel] Xen 4.11 Development Update

[Yi Sun]

On 18-01-31 02:57:32, Jan Beulich wrote:
> >>> On 31.01.18 at 07:57,  wrote:
> > === x86 === 
> > 
> > *  Enable Memory Bandwidth Allocation in Xen (v10)
> >   -  XEN-48
> >   -  Yi Sun
> 
> I think this has all gone in, the tools parts a little less than two weeks
> ago.
> 
Yes, all patches have been merged into master branch.

> Jan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 1/3] xen/arm: io: Distinguish unhandled IO from aborted one

[Stefano Stabellini]

On Wed, 31 Jan 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 30/01/18 19:09, Stefano Stabellini wrote:
> > On Tue, 30 Jan 2018, Julien Grall wrote:
> > > > > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > > > > index c8534d6cff..843adf4959 100644
> > > > > --- a/xen/arch/arm/traps.c
> > > > > +++ b/xen/arch/arm/traps.c
> > > > > @@ -1864,10 +1864,10 @@ static inline bool hpfar_is_valid(bool s1ptw,
> > > > > uint8_t fsc)
> > > > >return s1ptw || (fsc == FSC_FLT_TRANS &&
> > > > > !check_workaround_834220());
> > > > >}
> > > > >-static bool try_handle_mmio(struct cpu_user_regs *regs,
> > > > > -const union hsr hsr,
> > > > > -paddr_t gpa)
> > > > > -{
> > > > > +static enum io_state try_handle_mmio(struct cpu_user_regs *regs,
> > > > > + const union hsr hsr,
> > > > > + paddr_t gpa)
> > > > > + {
> > > > >const struct hsr_dabt dabt = hsr.dabt;
> > > > >mmio_info_t info = {
> > > > >.gpa = gpa,
> > > > > @@ -1879,11 +1879,11 @@ static bool try_handle_mmio(struct
> > > > > cpu_user_regs
> > > > > *regs,
> > > > >  /* stage-1 page table should never live in an emulated MMIO
> > > > > region
> > > > > */
> > > > >if ( dabt.s1ptw )
> > > > > -return false;
> > > > > +return IO_UNHANDLED;
> > > > >  /* All the instructions used on emulated MMIO region should
> > > > > be
> > > > > valid */
> > > > >if ( !dabt.valid )
> > > > > -return false;
> > > > > +return IO_UNHANDLED;
> > > > >  /*
> > > > > * Erratum 766422: Thumb store translation fault to Hypervisor
> > > > > may
> > > > > @@ -1896,11 +1896,11 @@ static bool try_handle_mmio(struct
> > > > > cpu_user_regs
> > > > > *regs,
> > > > >if ( rc )
> > > > >{
> > > > >gprintk(XENLOG_DEBUG, "Unable to decode
> > > > > instruction\n");
> > > > > -return false;
> > > > > +return IO_ABORT;
> > > > >}
> > > > >}
> > > > 
> > > > Why do the first two error checks result in IO_UNHANDLED, while the
> > > > third result in IO_ABORT? Specifically in relation to pagetable walk
> > > > failures due to someone else changing stage-2 entry simultaneously (see
> > > > comment toward the end of do_trap_stage2_abort_guest)?
> > > 
> > > Good question. Somehow I considered the first two as part of looking up
> > > the
> > > proper handler and not the device itself.
> > > 
> > > But I guess that at this stage we know that IO was targeting an emulated
> > > region. So we can return IO_ABORT.
> > 
> > That is what I thought as well
> 
> Actually, I have said something completely wrong yesterday. Must have been too
> tired :/.
> 
> At the time you call try_handle_mmio, you still don't know whether the fault
> was because of accessing an emulated MMIO region. You will only be sure when
> find_mmio_handler() has returned a non-NULL pointer (see handle_mmio()).
> 
> So returning IO_UNHANDLED here is correct as you want to try another method to
> handle the fault.
> 
> However, it also means that even bad access to emulated region will result to
> fallback on another method. While this should not be issue, I don't think this
> is future proof (I am mostly worry on the ACPI case where MMIO are mapped
> on-demand).
> 
> So I will send a patch to fold try_handle_mmio() into handle_mmio().

All right


> > 
> > 
> > > On a side note, it looks like the check dabt.s1ptw is unnecessary because
> > > a
> > > stage 2 abort on stage 1 translation table lookup will not return a valid
> > > instruction syndrome (see B3-1433 in DDI 0406C.c and D10-2460 in DDI
> > > 0487C.a).
> > 
> > in that case, go ahead and remove it as part of this patch, mention it
> > in the commit message
> 
> I will do that in a patch that fold try_handle_mmio() in handle_mmio().
> 
> Cheers,
> 
> -- 
> Julien Grall
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [seabios test] 118475: regressions - trouble: broken/fail/pass

[osstest service owner]

flight 118475 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118475/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-amd broken
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 115539

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-qemuu-nested-amd  4 host-install(4) broken pass in 118462

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail in 118462 
never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 seabios  14d91c353e19b7085fdbb7b2dcc43f3355665670
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z   89 days
Failing since115733  2017-11-10 17:19:59 Z   82 days   99 attempts
Testing same since   118140  2018-01-17 05:09:48 Z   14 days   20 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Marcel Apfelbaum 
  Michael S. Tsirkin 
  Paul Menzel 
  Stefan Berger 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdbroken  
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary

broken-job test-amd64-amd64-qemuu-nested-amd broken
broken-step test-amd64-amd64-qemuu-nested-amd host-install(4)

Not pushing.


commit 14d91c353e19b7085fdbb7b2dcc43f3355665670
Author: Marcel Apfelbaum 
Date:   Thu Jan 11 22:15:12 2018 +0200

pci: fix 'io hints' capability for RedHat PCI bridges

Commit ec6cb17f (pci: enable RedHat PCI bridges to reserve additional
 resources on PCI init)
added a new vendor specific PCI capability for RedHat PCI bridges
allowing them to reserve additional buses and/or IO/MEM space.

When adding the IO hints PCI capability to the pcie-root-port
without specifying a value for bus reservation, the subordinate bus
computation is wrong and the guest 

Re: [Xen-devel] kernel-ml-4.15.0-1.el7.elrepo.x86_64 doesn't boot as Xen PV domU

[Michael Young]

On Wed, 31 Jan 2018, Michael Young wrote:


(XEN) Guest stack trace from rsp=82203e20:
(XEN)   81036a89
(XEN)0001e030 00010092 82203e68 e02b
(XEN)   


I have just spotted this is truncated. The full Guest stack trace is

(XEN) Guest stack trace from rsp=82203e20:
(XEN)   81036a89
(XEN)0001e030 00010092 82203e68 e02b
(XEN)   
(XEN)823777e0   
(XEN)  823777e0 82203f08
(XEN)82203f0c 82203f04 82203f00 82203f1c
(XEN)81037673 82203f10 82203f14 82203f18
(XEN)3024  8008 
(XEN)81029d10   
(XEN)  82727b49 
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)0f0060c0c748 c305  
(XEN)   
(XEN)   
(XEN)   
(XEN)   

Some addresses from this that look like they might be relevant are
0x82203e20 : add%al,(%rax)
0x81036a89 :
mov%gs:0x28,%rax
0x81037673 : xor%edx,%edx
0x81029d10 :   callq  0x81a01f90 <__fentry__>
0x82727b49 :
callq  0x8106d6d0 

Michael Young

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xtf test] 118484: all pass - PUSHED

[osstest service owner]

flight 118484 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118484/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  9eeb26f3faeb25925c0cfde9ec18571fdbfbe4fa
baseline version:
 xtf  bade68b7087acd6b5ca6310a7460faeea48e4b1c

Last test of basis   117575  2018-01-02 19:50:26 Z   29 days
Testing same since   118484  2018-01-31 12:18:50 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xtf.git
   bade68b..9eeb26f  9eeb26f3faeb25925c0cfde9ec18571fdbfbe4fa -> 
xen-tested-master

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [linux-linus test] 118464: regressions - FAIL

[osstest service owner]

flight 118464 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118464/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail REGR. vs. 118324
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start   fail REGR. vs. 118324

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118324
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118324
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118324
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118324
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118324
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118324
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118324
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118324
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 linux13ddd1667e7f01071cdf120132238ffca004a88e
baseline version:
 linux5b7d27967dabfb17c21b0d98b29153b9e3ee71e5

Last test of basis   118324  2018-01-25 07:31:24 Z6 days
Failing since118362  2018-01-26 16:56:17 Z5 days5 attempts
Testing same since   118464  2018-01-31 00:36:35 Z0 days1 attempts


539 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm   

Re: [Xen-devel] kernel-ml-4.15.0-1.el7.elrepo.x86_64 doesn't boot as Xen PV domU

[Michael Young]

On Wed, 31 Jan 2018, Adi Pircalabu wrote:


(XEN) d8v0: unhandled page fault (ec=)
(XEN) Pagetable walk from 0028:
(XEN) L4[0x000] =  
(XEN) domain_crash_sync called from entry.S: fault at 82d08022a472 
create_bounce_frame+0x12b/0x13a

(XEN) Domain 8 (vcpu#0) crashed on cpu#6:
(XEN) [ Xen-4.6.6-9.el7 x86_64 debug=n Not tainted ]
(XEN) CPU: 6
(XEN) RIP: e033:[]
(XEN) RFLAGS: 0292 EM: 1 CONTEXT: pv guest (d8v0)
(XEN) rax:  rbx: 81e05720 rcx: 
(XEN) rdx: 0030 rsi: 82203efc rdi: 8241d460
(XEN) rbp: 82203ec8 rsp: 82203e10 r8: 
(XEN) r9: 82203f00 r10:  r11: 82203f04
(XEN) r12: 82203e78 r13: 82203e7c r14: 82203e80
(XEN) r15: 82203e84 cr0: 8005003b cr4: 003526e0
(XEN) cr3: 000426314000 cr2: 0028
(XEN) ds:  es:  fs:  gs:  ss: e02b cs: e033
(XEN) Guest stack trace from rsp=82203e10:
(XEN)  82203f04  8103f261
(XEN) 0001e030 00010092 82203e58 e02b
(XEN)  8241d460  
(XEN)    
(XEN)   8241d460 82203f04
(XEN) 82203f00 82203efc 82203ef8 82203f40
(XEN) 8103fce6 82203f14 82203f10 82203f0c
(XEN) 82203f08 3027  8008
(XEN)    
(XEN)   82203ff8 8246c490
(XEN)    
(XEN)    
(XEN)    
(XEN)    
(XEN)    
(XEN)   0f0060c0c748 c305
(XEN)    
(XEN)    
(XEN)    
(XEN)    


I an getting a similar crash with a PV guest running Fedora rawhide

(XEN) d26v0 Unhandled page fault fault/trap [#14, ec=]
(XEN) Pagetable walk from 0028:
(XEN)  L4[0x000] =  
(XEN) domain_crash_sync called from entry.S: fault at 82d080348a68 
entry.o#create_bounce_frame+0x135/0x14d
(XEN) Domain 26 (vcpu#0) crashed on cpu#0:
(XEN) [ Xen-4.9.1  x86_64  debug=n   Not tainted ]
(XEN) CPU:0
(XEN) RIP:e033:[]
(XEN) RFLAGS: 0292   EM: 1   CONTEXT: pv guest (d26v0)
(XEN) rax:    rbx: 81e03fa0   rcx: 
(XEN) rdx:    rsi: 82203f04   rdi: 823777e0
(XEN) rbp: 82203f08   rsp: 82203e20   r8:  82203f08
(XEN) r9:     r10: 82203f0c   r11: 
(XEN) r12: 82203f0c   r13: 82203e88   r14: 82203f00
(XEN) r15: 82203e98   cr0: 8005003b   cr4: 001526e0
(XEN) cr3: 00021709a000   cr2: 0028
(XEN) fsb:    gsb:    gss: 
(XEN) ds:    es:    fs:    gs:    ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=82203e20:
(XEN)   81036a89
(XEN)0001e030 00010092 82203e68 e02b
(XEN)   

This example is when booting 4.15.0-1.fc28.x86_64, the last kernel I 
successfully booted on this guest was 4.15.0-0.rc4.git3.1.fc28.x86_64


In this build of xen the code at create_bounce_frame+0x135 (ie. 309) is
   0x82d080348a61 :  mov0x8(%rdx),%rax
   0x82d080348a65 :  test   %rax,%rax
   0x82d080348a68 :
je 0x82d080349e60 
   0x82d080348a6e :  mov%rax,0x88(%rsp)
   0x82d080348a76 :  retq
   0x82d080348a77 :  nopw   0x0(%rax,%rax,1)

ie. at
movq  TRAPBOUNCE_eip(%rdx),%rax
testq %rax,%rax
UNLIKELY_START(z, create_bounce_frame_bad_bounce_ip)
lea   UNLIKELY_DISPATCH_LABEL(create_bounce_frame_bad_bounce_ip)(%rip), 
%rdi
jmp   asm_domain_crash_synchronous  /* Does not return */

[Xen-devel] [linux-linus bisection] complete test-amd64-amd64-xl-pvhv2-amd

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-pvhv2-amd
testid guest-start

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  4a5733771e6f33918eba07b584e564a67ac1
  Bug not present: 1c2e0f9e4f263714db917eb54f8d1c2d1463ed4c
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/118498/


  commit 4a5733771e6f33918eba07b584e564a67ac1
  Author: Juergen Gross 
  Date:   Fri Dec 1 15:14:07 2017 +0100
  
  libxl: put RSDP for PVH guest near 4GB
  
  Instead of locating the RSDP table below 1MB put it just below 4GB
  like the rest of the ACPI tables in case of PVH guests. This will
  avoid punching more holes than necessary into the memory map.
  
  Signed-off-by: Juergen Gross 
  Acked-by: Wei Liu 
  Reviewed-by: Roger Pau Monné 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-amd64-xl-pvhv2-amd.guest-start.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-amd64-xl-pvhv2-amd.guest-start
 --summary-out=tmp/118498.bisection-summary --basis-template=118324 
--blessings=real,real-bisect linux-linus test-amd64-amd64-xl-pvhv2-amd 
guest-start
Searching for failure / basis pass:
 118445 fail [host=pinot1] / 118428 ok.
Failure / basis pass flights: 118445 / 118428
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 0a4b6e2f80aad46fb55a5cf7b1664c0aef030ee0 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
4c7e478d597b0346eef3a256cfd6794ac778b608
Basis pass d8a5b80568a9cb66810e75b182018e9edb68e8ff 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
e871e80c38547d9faefc6604532ba3e985e65873
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#d8a5b80568a9cb66810e75b182018e9edb68e8ff-0a4b6e2f80aad46fb55a5cf7b1664c0aef030ee0
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60
 
git://xenbits.xen.org/qemu-xen.git#2b033e396f4fa0981bae1213cdacd15775655a97-2b033e396f4fa0981bae1213cdacd15775655a97
 
git://xenbits.xen.org/xen.git#e871e80c38547d9faefc6604532ba3e985e65873-4c7e478d597b0346eef3a256cfd6794ac778b608
>From 
>git://cache:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
   0be600a5add7..e1c70f32386c  master -> origin/master
Loaded 178959 nodes in revision graph
Searching for test results:
 118463 pass d8a5b80568a9cb66810e75b182018e9edb68e8ff 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
e871e80c38547d9faefc6604532ba3e985e65873
 118445 fail 0a4b6e2f80aad46fb55a5cf7b1664c0aef030ee0 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
4c7e478d597b0346eef3a256cfd6794ac778b608
 118428 pass d8a5b80568a9cb66810e75b182018e9edb68e8ff 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
e871e80c38547d9faefc6604532ba3e985e65873
 118466 fail 0a4b6e2f80aad46fb55a5cf7b1664c0aef030ee0 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
4c7e478d597b0346eef3a256cfd6794ac778b608
 118498 fail d8a5b80568a9cb66810e75b182018e9edb68e8ff 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
4a5733771e6f33918eba07b584e564a67ac1
 118467 fail d8a5b80568a9cb66810e75b182018e9edb68e8ff 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
35e40550ab7544c88db548d4d34ce670870e0926
 118469 

[Xen-devel] [PATCH 1/3] x86/svm: update VGIF support

[Brian Woods]

There are places where the GIF value is checked.  A guest with VGIF
enabled can change the GIF value without the host being involved,
therefore it needs to check the GIF value in the VMCB rather the one in
the nestedsvm struct.

Signed-off-by: Brian Woods 
---
 xen/arch/x86/hvm/svm/nestedsvm.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index b6f6449d75..1f7b0d3e88 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -800,8 +800,13 @@ nsvm_vcpu_vmexit_inject(struct vcpu *v, struct 
cpu_user_regs *regs,
 struct nestedvcpu *nv = _nestedhvm(v);
 struct nestedsvm *svm = _nestedsvm(v);
 struct vmcb_struct *ns_vmcb;
+struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
+
+if ( vmcb->_vintr.fields.vgif_enable )
+ASSERT(vmcb->_vintr.fields.vgif == 0);
+else
+ASSERT(svm->ns_gif == 0);
 
-ASSERT(svm->ns_gif == 0);
 ns_vmcb = nv->nv_vvmcx;
 
 if (nv->nv_vmexit_pending) {
@@ -1343,8 +1348,13 @@ nestedsvm_vmexit_defer(struct vcpu *v,
 uint64_t exitcode, uint64_t exitinfo1, uint64_t exitinfo2)
 {
 struct nestedsvm *svm = _nestedsvm(v);
+struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
+
+if ( vmcb->_vintr.fields.vgif_enable )
+vmcb->_vintr.fields.vgif = 0;
+else
+nestedsvm_vcpu_clgi(v);
 
-nestedsvm_vcpu_clgi(v);
 svm->ns_vmexit.exitcode = exitcode;
 svm->ns_vmexit.exitinfo1 = exitinfo1;
 svm->ns_vmexit.exitinfo2 = exitinfo2;
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 3/3] x86/svm: correct EFER.SVME intercept checks

[Brian Woods]

Corrects some EFER.SVME checks in intercepts.  See AMD APM vol2 section
15.4 for more details.  VMMCALL isn't checked due to guests needing it
to boot.

Reported-by: Andrew Cooper 
Signed-off-by: Brian Woods 
---
 xen/arch/x86/hvm/svm/nestedsvm.c | 10 --
 xen/arch/x86/hvm/svm/svm.c   |  8 +---
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index 1f7b0d3e88..1f5981fc18 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -1620,7 +1620,12 @@ void svm_vmexit_do_stgi(struct cpu_user_regs *regs, 
struct vcpu *v)
 {
 unsigned int inst_len;
 
-if ( !nestedhvm_enabled(v->domain) ) {
+/*
+ * STGI doesn't require SVME to be set to be used.  See AMD APM vol
+ * 2 section 15.4 for details.
+ */
+if ( !nestedhvm_enabled(v->domain) )
+{
 hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC);
 return;
 }
@@ -1640,7 +1645,8 @@ void svm_vmexit_do_clgi(struct cpu_user_regs *regs, 
struct vcpu *v)
 uint32_t general1_intercepts = vmcb_get_general1_intercepts(vmcb);
 vintr_t intr;
 
-if ( !nestedhvm_enabled(v->domain) ) {
+if ( !nsvm_efer_svm_enabled(v) )
+{
 hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC);
 return;
 }
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 7864ee39ae..2599f02ab6 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2255,7 +2255,6 @@ svm_vmexit_do_vmrun(struct cpu_user_regs *regs,
 {
 if ( !nsvm_efer_svm_enabled(v) )
 {
-gdprintk(XENLOG_ERR, "VMRUN: nestedhvm disabled, injecting #UD\n");
 hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC);
 return;
 }
@@ -2310,7 +2309,6 @@ svm_vmexit_do_vmload(struct vmcb_struct *vmcb,
 
 if ( !nsvm_efer_svm_enabled(v) ) 
 {
-gdprintk(XENLOG_ERR, "VMLOAD: nestedhvm disabled, injecting #UD\n");
 hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC);
 return;
 }
@@ -2346,7 +2344,6 @@ svm_vmexit_do_vmsave(struct vmcb_struct *vmcb,
 
 if ( !nsvm_efer_svm_enabled(v) ) 
 {
-gdprintk(XENLOG_ERR, "VMSAVE: nestedhvm disabled, injecting #UD\n");
 hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC);
 return;
 }
@@ -2820,6 +2817,11 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
 break;
 
 case VMEXIT_INVLPGA:
+if ( !nsvm_efer_svm_enabled(v) )
+{
+hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC);
+break;
+}
 if ( (inst_len = __get_instruction_length(v, INSTR_INVLPGA)) == 0 )
 break;
 svm_invlpga_intercept(v, regs->rax, regs->ecx);
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 2/3] x86/svm: add EFER SVME support for VGIF/VLOAD

[Brian Woods]

Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set.

Reported-by: Andrew Cooper 
Signed-off-by: Brian Woods 
---
 xen/arch/x86/hvm/svm/svm.c  | 69 +
 xen/arch/x86/hvm/svm/vmcb.c | 17 ---
 2 files changed, 69 insertions(+), 17 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index c48fdfaa5d..7864ee39ae 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -601,6 +601,73 @@ void svm_update_guest_cr(struct vcpu *v, unsigned int cr)
 }
 }
 
+/*
+ * This runs on EFER change to see if nested features need to either be
+ * turned off or on.
+ */
+static void svm_nested_features_on_efer_update(struct vcpu *v)
+{
+struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
+struct nestedsvm *svm = _nestedsvm(v);
+u32 general2_intercepts;
+vintr_t vintr;
+
+   /*
+* Need state for transfering the nested gif status so only write on
+* the hvm_vcpu EFER.SVME changing.
+*/
+if ( (v->arch.hvm_vcpu.guest_efer & EFER_SVME) &&
+ nestedhvm_enabled(v->domain))
+{
+if ( (vmcb->virt_ext.fields.vloadsave_enable == 0) &&
+ paging_mode_hap(v->domain) &&
+ cpu_has_svm_vloadsave )
+{
+vmcb->virt_ext.fields.vloadsave_enable = 1;
+general2_intercepts  = vmcb_get_general2_intercepts(vmcb);
+general2_intercepts &= ~(GENERAL2_INTERCEPT_VMLOAD |
+ GENERAL2_INTERCEPT_VMSAVE);
+vmcb_set_general2_intercepts(vmcb, general2_intercepts);
+}
+
+if ( (vmcb->_vintr.fields.vgif_enable == 0) &&
+ cpu_has_svm_vgif )
+{
+vintr = vmcb_get_vintr(vmcb);
+vintr.fields.vgif = svm->ns_gif;
+vintr.fields.vgif_enable = 1;
+vmcb_set_vintr(vmcb, vintr);
+general2_intercepts  = vmcb_get_general2_intercepts(vmcb);
+general2_intercepts &= ~(GENERAL2_INTERCEPT_STGI |
+ GENERAL2_INTERCEPT_CLGI);
+vmcb_set_general2_intercepts(vmcb, general2_intercepts);
+}
+}
+else
+{
+if ( vmcb->virt_ext.fields.vloadsave_enable == 1 )
+{
+vmcb->virt_ext.fields.vloadsave_enable = 0;
+general2_intercepts  = vmcb_get_general2_intercepts(vmcb);
+general2_intercepts |= (GENERAL2_INTERCEPT_VMLOAD |
+GENERAL2_INTERCEPT_VMSAVE);
+vmcb_set_general2_intercepts(vmcb, general2_intercepts);
+}
+
+if ( vmcb->_vintr.fields.vgif_enable == 1 )
+{
+vintr = vmcb_get_vintr(vmcb);
+svm->ns_gif = vintr.fields.vgif;
+vintr.fields.vgif_enable = 0;
+vmcb_set_vintr(vmcb, vintr);
+general2_intercepts  = vmcb_get_general2_intercepts(vmcb);
+general2_intercepts |= (GENERAL2_INTERCEPT_STGI |
+GENERAL2_INTERCEPT_CLGI);
+vmcb_set_general2_intercepts(vmcb, general2_intercepts);
+}
+}
+}
+
 static void svm_update_guest_efer(struct vcpu *v)
 {
 struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
@@ -611,6 +678,8 @@ static void svm_update_guest_efer(struct vcpu *v)
 if ( lma )
 new_efer |= EFER_LME;
 vmcb_set_efer(vmcb, new_efer);
+
+svm_nested_features_on_efer_update(v);
 }
 
 static void svm_cpuid_policy_changed(struct vcpu *v)
diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 0e6cba5b7b..997e7597e0 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -200,29 +200,12 @@ static int construct_vmcb(struct vcpu *v)
 
 /* PAT is under complete control of SVM when using nested paging. */
 svm_disable_intercept_for_msr(v, MSR_IA32_CR_PAT);
-
-/* Use virtual VMLOAD/VMSAVE if available. */
-if ( cpu_has_svm_vloadsave )
-{
-vmcb->virt_ext.fields.vloadsave_enable = 1;
-vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_VMLOAD;
-vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_VMSAVE;
-}
 }
 else
 {
 vmcb->_exception_intercepts |= (1U << TRAP_page_fault);
 }
 
-/* if available, enable and configure virtual gif */
-if ( cpu_has_svm_vgif )
-{
-vmcb->_vintr.fields.vgif = 1;
-vmcb->_vintr.fields.vgif_enable = 1;
-vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_STGI;
-vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_CLGI;
-}
-
 if ( cpu_has_pause_filter )
 {
 vmcb->_pause_filter_count = SVM_PAUSEFILTER_INIT;
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 0/3] Various SVM Cleanups

[Brian Woods]

This is a small series of SVM cleanup patches.  The first patch is
correcting a couple of checks relating to VGIF.  The other two are
ensuring that nested SVM functionality is emulated/setup more
correctly.

Brian Woods (3):
  x86/svm: update VGIF support
  x86/svm: add EFER SVME support for VGIF/VLOAD
  x86/svm: correct EFER.SVME intercept checks

 xen/arch/x86/hvm/svm/nestedsvm.c | 24 ++---
 xen/arch/x86/hvm/svm/svm.c   | 77 ++--
 xen/arch/x86/hvm/svm/vmcb.c  | 17 -
 3 files changed, 94 insertions(+), 24 deletions(-)

-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 04/25] x86emul: support FMA4 insns

[Andrew Cooper]

On 07/12/17 14:01, Jan Beulich wrote:
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable test] 118456: regressions - FAIL

[osstest service owner]

flight 118456 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118456/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail REGR. vs. 
118441

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118423
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118441
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118441
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118441
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118441
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118441
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118441
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 118441
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118441
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118441
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  2b8d75e975d6fbe0140969154a67601698b84738
baseline version:
 xen  4c7e478d597b0346eef3a256cfd6794ac778b608

Last test of basis   118441  2018-01-29 15:47:57 Z2 days
Testing same since   118456  2018-01-30 15:48:17 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Christian 

Re: [Xen-devel] [PATCH v3 03/25] x86emul: support F16C insns

[Andrew Cooper]

On 07/12/17 14:00, Jan Beulich wrote:
> Note that this avoids emulating the behavior of VCVTPS2PH found on at
> least some Intel CPUs, which update MXCSR even when the memory write
> faults.
>
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH V2 2/2] x86/hvm: fix domain crash when CR3 has the noflush bit set

[Tamas K Lengyel]

On Wed, Jan 31, 2018 at 11:44 AM, Tamas K Lengyel  wrote:
> "
>
> On Tue, Jan 30, 2018 at 2:16 AM, Razvan Cojocaru
>  wrote:
>> The emulation layers of Xen lack PCID support, and as we only offer
>> PCID to HAP guests, all writes to CR3 are handled by hardware,
>> except when introspection is involved. Consequently, trying to set
>> CR3 when the noflush bit is set in hvm_set_cr3() leads to domain
>> crashes. The workaround is to clear the noflush bit in
>> hvm_set_cr3(). CR3 values in hvm_monitor_cr() are also sanitized.
>> Additionally, a bool parameter now propagates to
>> {svm,vmx}_update_guest_cr(), so that no flushes occur when
>> the bit was set.
>>
>> Signed-off-by: Razvan Cojocaru 
>> Reported-by: Bitweasil 
>> Suggested-by: Andrew Cooper 
>>
>> ---
>> Changes since V1:
>>  - Added the bool noflush parameter and code to propagate it to
>>{svm,vmx}_update_guest_cr().
>>  - Added X86_CR3_NOFLUSH_DISABLE_MASK and X86_CR3_NOFLUSH_DISABLE.
>>  - No longer sanitizing the old value in hvm_monitor_cr().
>> ---
>>  xen/arch/x86/hvm/domain.c |  6 +++---
>>  xen/arch/x86/hvm/hvm.c| 25 -
>>  xen/arch/x86/hvm/monitor.c|  3 +++
>>  xen/arch/x86/hvm/svm/nestedsvm.c  |  4 ++--
>>  xen/arch/x86/hvm/svm/svm.c| 22 ++
>>  xen/arch/x86/hvm/svm/vmcb.c   |  4 ++--
>>  xen/arch/x86/hvm/vmx/vmcs.c   |  4 ++--
>>  xen/arch/x86/hvm/vmx/vmx.c| 16 +---
>>  xen/arch/x86/mm.c |  2 +-
>>  xen/arch/x86/mm/hap/hap.c |  6 +++---
>>  xen/arch/x86/mm/shadow/common.c   |  2 +-
>>  xen/arch/x86/mm/shadow/multi.c|  6 +++---
>>  xen/arch/x86/mm/shadow/none.c |  2 +-
>>  xen/arch/x86/monitor.c|  2 +-
>>  xen/include/asm-x86/hvm/hvm.h | 10 +++---
>>  xen/include/asm-x86/hvm/svm/svm.h |  2 +-
>>  xen/include/asm-x86/paging.h  |  7 ---
>>  17 files changed, 73 insertions(+), 50 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/domain.c b/xen/arch/x86/hvm/domain.c
>> index 6047464..9be085e 100644
>> --- a/xen/arch/x86/hvm/domain.c
>> +++ b/xen/arch/x86/hvm/domain.c
>> @@ -287,9 +287,9 @@ int arch_set_info_hvm_guest(struct vcpu *v, const 
>> vcpu_hvm_context_t *ctx)
>>  return -EINVAL;
>>  }
>>
>> -hvm_update_guest_cr(v, 0);
>> -hvm_update_guest_cr(v, 3);
>> -hvm_update_guest_cr(v, 4);
>> +hvm_update_guest_cr(v, 0, false);
>> +hvm_update_guest_cr(v, 3, false);
>> +hvm_update_guest_cr(v, 4, false);
>>  hvm_update_guest_efer(v);
>>
>>  if ( hvm_paging_enabled(v) && !paging_mode_hap(v->domain) )
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index c4287a3..b42fbd1 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -2184,7 +2184,7 @@ static void hvm_update_cr(struct vcpu *v, unsigned int 
>> cr, unsigned long value)
>>  {
>>  v->arch.hvm_vcpu.guest_cr[cr] = value;
>>  nestedhvm_set_cr(v, cr, value);
>> -hvm_update_guest_cr(v, cr);
>> +hvm_update_guest_cr(v, cr, false);
>>  }
>>
>>  int hvm_set_cr0(unsigned long value, bool_t may_defer)
>> @@ -2310,6 +2310,7 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
>>  struct vcpu *v = current;
>>  struct page_info *page;
>>  unsigned long old = v->arch.hvm_vcpu.guest_cr[3];
>> +bool noflush = false;
>>
>>  if ( may_defer && 
>> unlikely(v->domain->arch.monitor.write_ctrlreg_enabled &
>> monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3)) )
>
> In this if block shouldn't we save the "noflush" into
> "v->arch.vm_event->write_data" so that it can be used during
> hvm_do_resume as well?
>

Never mind, I see that this only applies on the return path already.

Tamas

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/2] update the minimal ocaml version to 4.02

[Christian Lindig]

> On 30. Jan 2018, at 22:56, Michael Young  wrote:
> 
> The ocaml safe-strings patch uses code introduced in ocaml 4.02
> so update the minimal version.
> Signed-off-by: Michael Young 
> ---
> stubdom/configure| 4 ++--
> stubdom/configure.ac | 2 +-
> tools/configure  | 2 +-
> tools/configure.ac   | 2 +-
> 4 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/stubdom/configure b/stubdom/configure
> index a7a0c09154..abb749faed 100755
> --- a/stubdom/configure
> +++ b/stubdom/configure
> @@ -3528,10 +3528,10 @@ GRUB_VERSION="0.97"
> 
> if test "x$OCAML_URL" = "x"; then :
> 
> - OCAML_URL="http://caml.inria.fr/pub/distrib/ocaml-3.11;
> + OCAML_URL="http://caml.inria.fr/pub/distrib/ocaml-4.02;
> 
> fi
> -OCAML_VERSION="3.11.0"
> +OCAML_VERSION="4.02.0"
> 
> 
> 
> diff --git a/stubdom/configure.ac b/stubdom/configure.ac
> index 9fec8539d2..9066dfaaa7 100644
> --- a/stubdom/configure.ac
> +++ b/stubdom/configure.ac
> @@ -65,7 +65,7 @@ AX_STUBDOM_LIB([LIBPCI], [libpci], [2.2.9], 
> [http://www.kernel.org/pub/software/
> AX_STUBDOM_LIB([NEWLIB], [newlib], [1.16.0], 
> [ftp://sources.redhat.com/pub/newlib])
> AX_STUBDOM_LIB([LWIP], [lwip], [1.3.0], 
> [http://download.savannah.gnu.org/releases/lwip])
> AX_STUBDOM_LIB([GRUB], [grub], [0.97], [http://alpha.gnu.org/gnu/grub])
> -AX_STUBDOM_LIB_NOEXT([OCAML], [ocaml], [3.11.0], 
> [http://caml.inria.fr/pub/distrib/ocaml-3.11])
> +AX_STUBDOM_LIB_NOEXT([OCAML], [ocaml], [4.02.0], 
> [http://caml.inria.fr/pub/distrib/ocaml-4.02])
> AX_STUBDOM_LIB([GMP], [libgmp], [4.3.2], [ftp://ftp.gmplib.org/pub/gmp-4.3.2])
> AX_STUBDOM_LIB([POLARSSL], [polarssl], [1.1.4], 
> [http://polarssl.org/code/releases])
> AX_STUBDOM_LIB([TPMEMU], [berlios tpm emulator], [0.7.4], 
> [http://download.berlios.de/tpm-emulator])
> diff --git a/tools/configure b/tools/configure
> index 05921b4898..feb34fc03d 100755
> --- a/tools/configure
> +++ b/tools/configure
> @@ -6616,7 +6616,7 @@ else
>  -e 's/[^0-9]//g'`
> 
> 
> -  ax_compare_version_B=`echo "3.09.3" | sed -e 's/\([0-9]*\)/Z\1Z/g' \
> +  ax_compare_version_B=`echo "4.02.0" | sed -e 's/\([0-9]*\)/Z\1Z/g' \
>  -e 's/Z\([0-9]\)Z/Z0\1Z/g' \
>  -e 's/Z\([0-9][0-9]\)Z/Z0\1Z/g' \
>  -e 's/Z\([0-9][0-9][0-9]\)Z/Z0\1Z/g' \
> diff --git a/tools/configure.ac b/tools/configure.ac
> index d1a3a78d87..06eb16db4f 100644
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -294,7 +294,7 @@ AS_IF([test "x$ocamltools" = "xy"], [
> AC_MSG_ERROR([Ocaml tools enabled, but missing ocamlopt or 
> ocamlfind])])
> ocamltools="n"
> ], [
> -AX_COMPARE_VERSION([$OCAMLVERSION], [lt], [3.09.3], [
> +AX_COMPARE_VERSION([$OCAMLVERSION], [lt], [4.02.0], [
> AS_IF([test "x$enable_ocamltools" = "xyes"], [
> AC_MSG_ERROR([Your version of OCaml: $OCAMLVERSION is not 
> supported])])
> ocamltools="n"
> -- 
> 2.14.3

Acked-by: Christian Lindig 
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 3/7] xen/arm32: entry: Add missing trap_reset entry

[Stefano Stabellini]

On Wed, 31 Jan 2018, Julien Grall wrote:
> From: Julien Grall 
> 
> At the moment, the reset vector is defined as .word 0 (e.g andeq r0, r0,
> r0).
> 
> This is rather unintuitive and will result to execute the trap
> undefined. Instead introduce trap helpers for reset and will generate an
> error message in the unlikely case that reset will be called.
> 
> This is part of XSA-254.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
> Changes in v2:
> - Replace .word 0 by trap_reset
> ---
>  xen/arch/arm/arm32/entry.S | 3 ++-
>  xen/arch/arm/arm32/traps.c | 5 +
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
> index c6490d2847..64876c1184 100644
> --- a/xen/arch/arm/arm32/entry.S
> +++ b/xen/arch/arm/arm32/entry.S
> @@ -137,7 +137,7 @@ trap_##trap:  
>   \
>  
>  .align 5
>  GLOBAL(hyp_traps_vector)
> -.word 0 /* 0x00 - Reset */
> +b trap_reset/* 0x00 - Reset */
>  b trap_undefined_instruction/* 0x04 - Undefined Instruction */
>  b trap_hypervisor_call  /* 0x08 - Hypervisor Call */
>  b trap_prefetch_abort   /* 0x0c - Prefetch Abort */
> @@ -146,6 +146,7 @@ GLOBAL(hyp_traps_vector)
>  b trap_irq  /* 0x18 - IRQ */
>  b trap_fiq  /* 0x1c - FIQ */
>  
> +DEFINE_TRAP_ENTRY(reset)
>  DEFINE_TRAP_ENTRY(undefined_instruction)
>  DEFINE_TRAP_ENTRY(hypervisor_call)
>  DEFINE_TRAP_ENTRY(prefetch_abort)
> diff --git a/xen/arch/arm/arm32/traps.c b/xen/arch/arm/arm32/traps.c
> index 705255883e..4f27543dec 100644
> --- a/xen/arch/arm/arm32/traps.c
> +++ b/xen/arch/arm/arm32/traps.c
> @@ -23,6 +23,11 @@
>  
>  #include 
>  
> +void do_trap_reset(struct cpu_user_regs *regs)
> +{
> +do_unexpected_trap("Reset", regs);
> +}
> +
>  void do_trap_undefined_instruction(struct cpu_user_regs *regs)
>  {
>  uint32_t pc = regs->pc;
> -- 
> 2.11.0
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 4/7] xen/arm32: Add skeleton to harden branch predictor aliasing attacks

[Stefano Stabellini]

On Wed, 31 Jan 2018, Julien Grall wrote:
> From: Julien Grall 
> 
> Aliasing attacked against CPU branch predictors can allow an attacker to
> redirect speculative control flow on some CPUs and potentially divulge
> information from one context to another.
> 
> This patch adds initiatial skeleton code behind a new Kconfig option
> to enable implementation-specific mitigations against these attacks
> for CPUs that are affected.
> 
> Most of mitigations will have to be applied when entering to the
> hypervisor from the guest context.
> 
> Because the attack is against branch predictor, it is not possible to
> safely use branch instruction before the mitigation is applied.
> Therefore this has to be done in the vector entry before jump to the
> helper handling a given exception.
> 
> However, on arm32, each vector contain a single instruction. This means
> that the hardened vector tables may rely on the state of registers that
> does not hold when in the hypervisor (e.g SP is 8 bytes aligned).
> Therefore hypervisor code running with guest vectors table should be
> minimized and always have IRQs and SErrors masked to reduce the risk to
> use them.
> 
> This patch provides an infrastructure to switch vector tables before
> entering to the guest and when leaving it.
> 
> Note that alternative could have been used, but older Xen (4.8 or
> earlier) doesn't have support. So avoid using alternative to ease
> backporting.
> 
> This is part of XSA-254.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
> Changes in v2:
> - Clarify the commit message
> ---
>  xen/arch/arm/Kconfig   |  3 +++
>  xen/arch/arm/arm32/entry.S | 41 -
>  xen/arch/arm/cpuerrata.c   | 30 ++
>  3 files changed, 73 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 06fd85cc77..2782ee6589 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -191,6 +191,9 @@ config HARDEN_BRANCH_PREDICTOR
>  config ARM64_HARDEN_BRANCH_PREDICTOR
>  def_bool y if ARM_64 && HARDEN_BRANCH_PREDICTOR
>  
> +config ARM32_HARDEN_BRANCH_PREDICTOR
> +def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
> +
>  source "common/Kconfig"
>  
>  source "drivers/Kconfig"
> diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
> index 64876c1184..828e52c25c 100644
> --- a/xen/arch/arm/arm32/entry.S
> +++ b/xen/arch/arm/arm32/entry.S
> @@ -34,6 +34,20 @@
>  blne save_guest_regs
>  
>  save_guest_regs:
> +#ifdef CONFIG_ARM32_HARDEN_BRANCH_PREDICTOR
> +/*
> + * Restore vectors table to the default as it may have been
> + * changed when returning to the guest (see
> + * return_to_hypervisor). We need to do that early (e.g before
> + * any interrupts are unmasked) because hardened vectors requires
> + * SP to be 8 bytes aligned. This does not hold when running in
> + * the hypervisor.
> + */
> +ldr r1, =hyp_traps_vector
> +mcr p15, 4, r1, c12, c0, 0
> +isb
> +#endif
> +
>  ldr r11, =0x  /* Clobber SP which is only valid for 
> hypervisor frames. */
>  str r11, [sp, #UREGS_sp]
>  SAVE_ONE_BANKED(SP_usr)
> @@ -179,12 +193,37 @@ return_to_guest:
>  RESTORE_ONE_BANKED(R11_fiq); RESTORE_ONE_BANKED(R12_fiq);
>  /* Fall thru */
>  return_to_hypervisor:
> -cpsid i
> +cpsid ai
>  ldr lr, [sp, #UREGS_lr]
>  ldr r11, [sp, #UREGS_pc]
>  msr ELR_hyp, r11
>  ldr r11, [sp, #UREGS_cpsr]
>  msr SPSR_hyp, r11
> +#ifdef CONFIG_ARM32_HARDEN_BRANCH_PREDICTOR
> +/*
> + * Hardening branch predictor may require to setup a different
> + * vector tables before returning to the guests. Those vectors
> + * may rely on the state of registers that does not hold when
> + * running in the hypervisor (e.g SP is 8 bytes aligned). So setup
> + * HVBAR very late.
> + *
> + * Default vectors table will be restored on exit (see
> + * save_guest_regs).
> + */
> +mov r9, #0  /* vector tables = NULL */
> +/*
> + * Load vector tables pointer from the per-cpu bp_harden_vecs
> + * when returning to the guest only.
> + */
> +and r11, #PSR_MODE_MASK
> +cmp r11, #PSR_MODE_HYP
> +ldrne r11, =per_cpu__bp_harden_vecs
> +mrcne p15, 4, r10, c13, c0, 2   /* r10 = per-cpu offset (HTPIDR) */
> +addne r11, r11, r10 /* r11 = offset of the vector tables 
> */
> +ldrne r9, [r11] /* r9  = vector tables */
> +cmp r9, #0  /* Only update HVBAR when the vector 
> */
> +mcrne p15, 4, r9, c12, c0, 0/* tables is not NULL. */
> +#endif
> 

[Xen-devel] [PATCH RFC] firmware/shim: fix Xen tree setup

[Jan Beulich]

There are multiple issues here, and I'm happy to split the patch up if
that's what it takes:
- "set -e" on a separate Makefile line is meaningless. Glue together all
  the lines that this is supposed to cover.
- I have no idea what *.d1 is supposed to refer to - we only have .*.d
  and .*.d2 files (not also the leading dot).
- I have also no idea what *.1 is meant to cover. Instead also exclude
  preprocessed and non-source assembly files.
- Excluding symlinks in the source tree is a problem for me: Short of
  out-of-tree builds, in order to easily build test multiple
  configurations, I'm setting up my build trees as trees of symlinks
  into the source tree. Hence the original logic would find only the few
  generated files under config/. I do realize though that find's -xtype
  primary is a non-standard extension (explicitly having "! type -l"
  seems pointless though, at least for standard conforming find, as
  "-type f" is supposed to only find non-symlinked files).

Irrespective of the changes I'm still observing "mkdir -p" to report a
missing operand, as config/ has no subdirs. Oddly enough this doesn't
cause the whole command (and hence the build to fail), despite the
"set -e" now covering the entire set of commands - perhaps a quirk of
the relatively old bash I've seen this with (a few simple experiments
suggest that commands inside () producing a non-success status would
exit the inner shell, but not the outer one).

Signed-off-by: Jan Beulich 

--- a/tools/firmware/xen-dir/Makefile
+++ b/tools/firmware/xen-dir/Makefile
@@ -16,18 +16,18 @@ DEP_FILES=$(foreach i, $(LINK_FILES), $(
 
 linkfarm.stamp: $(DEP_DIRS) $(DEP_FILES) FORCE
mkdir -p $(D)
-   set -e
rm -f linkfarm.stamp.tmp
+   set -e; \
$(foreach d, $(LINK_DIRS), \
 (mkdir -p $(D)/$(d); \
  cd $(D)/$(d); \
  find $(XEN_ROOT)/$(d)/ -type d |\
-   sed 's,^$(XEN_ROOT)/$(d)/,,g' | xargs mkdir -p);)
+   sed 's,^$(XEN_ROOT)/$(d)/,,g' | xargs mkdir -p);) \
$(foreach d, $(LINK_DIRS), \
(cd $(XEN_ROOT); \
-find $(d) ! -type l -type f \
-$(addprefix ! -path , '*.[oda1]' '*.d[12]')) \
->> linkfarm.stamp.tmp ; )
+find $(d) -xtype f \
+$(addprefix ! -path , '*.[isoa]' '.*.d' '.*.d2')) \
+>> linkfarm.stamp.tmp;) \
$(foreach f, $(LINK_FILES), \
echo $(f) >> linkfarm.stamp.tmp ;)
cmp -s linkfarm.stamp.tmp linkfarm.stamp && \




___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 5/7] xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12

[Julien Grall]

From: Julien Grall 

In order to avoid aliasing attackes agains the branch predictor, let's
invalidate the BTB on guest exist. This is made complicated by the fact
that we cannot take a branch invalidating the BTB.

This is based on the first version posrted by Marc Zyngier on Linux-arm
mailing list (see [1]).

This is part of XSA-254.

Signed-off-by: Marc Zyngier 
Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

[1] https://www.spinics.net/lists/arm-kernel/msg627032.html

---
Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/arm32/entry.S | 55 ++
 xen/arch/arm/cpuerrata.c   | 19 
 2 files changed, 74 insertions(+)

diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
index 828e52c25c..a295f3ad67 100644
--- a/xen/arch/arm/arm32/entry.S
+++ b/xen/arch/arm/arm32/entry.S
@@ -160,6 +160,61 @@ GLOBAL(hyp_traps_vector)
 b trap_irq  /* 0x18 - IRQ */
 b trap_fiq  /* 0x1c - FIQ */
 
+.align 5
+GLOBAL(hyp_traps_vector_bp_inv)
+/*
+ * We encode the exception entry in the bottom 3 bits of
+ * SP, and we have to guarantee to be 8 bytes aligned.
+ */
+add sp, sp, #1  /* Reset7 */
+add sp, sp, #1  /* Undef6 */
+add sp, sp, #1  /* Hypervisor Call  5 */
+add sp, sp, #1  /* Prefetch abort   4 */
+add sp, sp, #1  /* Data abort   3 */
+add sp, sp, #1  /* Hypervisor   2 */
+add sp, sp, #1  /* IRQ  1 */
+nop /* FIQ  0 */
+
+mcrp15, 0, r0, c7, c5, 6   /* BPIALL */
+isb
+
+/*
+ * As we cannot use any temporary registers and cannot
+ * clobber SP, we can decode the exception entry using
+ * an unrolled binary search.
+ */
+tst sp, #4
+bne 1f
+
+tst sp, #2
+bne 3f
+
+tst sp, #1
+bic sp, sp, #0x7
+bne trap_irq
+b   trap_fiq
+
+1:
+tst sp, #2
+bne 2f
+
+tst sp, #1
+bic sp, sp, #0x7
+bne trap_hypervisor_call
+b   trap_prefetch_abort
+
+2:
+tst sp, #1
+bic sp, sp, #0x7
+bne trap_reset
+b   trap_undefined_instruction
+
+3:
+tst sp, #1
+bic sp, sp, #0x7
+bne trap_data_abort
+b   trap_guest_sync
+
 DEFINE_TRAP_ENTRY(reset)
 DEFINE_TRAP_ENTRY(undefined_instruction)
 DEFINE_TRAP_ENTRY(hypervisor_call)
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 0a138fa735..c79e6d65d3 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -198,6 +198,13 @@ install_bp_hardening_vecs(const struct 
arm_cpu_capabilities *entry,
 this_cpu(bp_harden_vecs) = hyp_vecs;
 }
 
+static int enable_bp_inv_hardening(void *data)
+{
+install_bp_hardening_vecs(data, hyp_traps_vector_bp_inv,
+  "execute BPIALL");
+return 0;
+}
+
 #endif
 
 #define MIDR_RANGE(model, min, max) \
@@ -284,6 +291,18 @@ static const struct arm_cpu_capabilities arm_errata[] = {
 .enable = enable_psci_bp_hardening,
 },
 #endif
+#ifdef CONFIG_ARM32_HARDEN_BRANCH_PREDICTOR
+{
+.capability = ARM_HARDEN_BRANCH_PREDICTOR,
+MIDR_ALL_VERSIONS(MIDR_CORTEX_A12),
+.enable = enable_bp_inv_hardening,
+},
+{
+.capability = ARM_HARDEN_BRANCH_PREDICTOR,
+MIDR_ALL_VERSIONS(MIDR_CORTEX_A17),
+.enable = enable_bp_inv_hardening,
+},
+#endif
 {},
 };
 
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 4/7] xen/arm32: Add skeleton to harden branch predictor aliasing attacks

[Julien Grall]

From: Julien Grall 

Aliasing attacked against CPU branch predictors can allow an attacker to
redirect speculative control flow on some CPUs and potentially divulge
information from one context to another.

This patch adds initiatial skeleton code behind a new Kconfig option
to enable implementation-specific mitigations against these attacks
for CPUs that are affected.

Most of mitigations will have to be applied when entering to the
hypervisor from the guest context.

Because the attack is against branch predictor, it is not possible to
safely use branch instruction before the mitigation is applied.
Therefore this has to be done in the vector entry before jump to the
helper handling a given exception.

However, on arm32, each vector contain a single instruction. This means
that the hardened vector tables may rely on the state of registers that
does not hold when in the hypervisor (e.g SP is 8 bytes aligned).
Therefore hypervisor code running with guest vectors table should be
minimized and always have IRQs and SErrors masked to reduce the risk to
use them.

This patch provides an infrastructure to switch vector tables before
entering to the guest and when leaving it.

Note that alternative could have been used, but older Xen (4.8 or
earlier) doesn't have support. So avoid using alternative to ease
backporting.

This is part of XSA-254.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Clarify the commit message
---
 xen/arch/arm/Kconfig   |  3 +++
 xen/arch/arm/arm32/entry.S | 41 -
 xen/arch/arm/cpuerrata.c   | 30 ++
 3 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 06fd85cc77..2782ee6589 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -191,6 +191,9 @@ config HARDEN_BRANCH_PREDICTOR
 config ARM64_HARDEN_BRANCH_PREDICTOR
 def_bool y if ARM_64 && HARDEN_BRANCH_PREDICTOR
 
+config ARM32_HARDEN_BRANCH_PREDICTOR
+def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
+
 source "common/Kconfig"
 
 source "drivers/Kconfig"
diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
index 64876c1184..828e52c25c 100644
--- a/xen/arch/arm/arm32/entry.S
+++ b/xen/arch/arm/arm32/entry.S
@@ -34,6 +34,20 @@
 blne save_guest_regs
 
 save_guest_regs:
+#ifdef CONFIG_ARM32_HARDEN_BRANCH_PREDICTOR
+/*
+ * Restore vectors table to the default as it may have been
+ * changed when returning to the guest (see
+ * return_to_hypervisor). We need to do that early (e.g before
+ * any interrupts are unmasked) because hardened vectors requires
+ * SP to be 8 bytes aligned. This does not hold when running in
+ * the hypervisor.
+ */
+ldr r1, =hyp_traps_vector
+mcr p15, 4, r1, c12, c0, 0
+isb
+#endif
+
 ldr r11, =0x  /* Clobber SP which is only valid for hypervisor 
frames. */
 str r11, [sp, #UREGS_sp]
 SAVE_ONE_BANKED(SP_usr)
@@ -179,12 +193,37 @@ return_to_guest:
 RESTORE_ONE_BANKED(R11_fiq); RESTORE_ONE_BANKED(R12_fiq);
 /* Fall thru */
 return_to_hypervisor:
-cpsid i
+cpsid ai
 ldr lr, [sp, #UREGS_lr]
 ldr r11, [sp, #UREGS_pc]
 msr ELR_hyp, r11
 ldr r11, [sp, #UREGS_cpsr]
 msr SPSR_hyp, r11
+#ifdef CONFIG_ARM32_HARDEN_BRANCH_PREDICTOR
+/*
+ * Hardening branch predictor may require to setup a different
+ * vector tables before returning to the guests. Those vectors
+ * may rely on the state of registers that does not hold when
+ * running in the hypervisor (e.g SP is 8 bytes aligned). So setup
+ * HVBAR very late.
+ *
+ * Default vectors table will be restored on exit (see
+ * save_guest_regs).
+ */
+mov r9, #0  /* vector tables = NULL */
+/*
+ * Load vector tables pointer from the per-cpu bp_harden_vecs
+ * when returning to the guest only.
+ */
+and r11, #PSR_MODE_MASK
+cmp r11, #PSR_MODE_HYP
+ldrne r11, =per_cpu__bp_harden_vecs
+mrcne p15, 4, r10, c13, c0, 2   /* r10 = per-cpu offset (HTPIDR) */
+addne r11, r11, r10 /* r11 = offset of the vector tables */
+ldrne r9, [r11] /* r9  = vector tables */
+cmp r9, #0  /* Only update HVBAR when the vector */
+mcrne p15, 4, r9, c12, c0, 0/* tables is not NULL. */
+#endif
 pop {r0-r12}
 add sp, #(UREGS_SP_usr - UREGS_sp); /* SP, LR, SPSR, PC */
 clrex
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index f1ea7f3c5b..0a138fa735 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -170,6 +170,36 @@ static int enable_psci_bp_hardening(void *data)
 
 #endif /* 

[Xen-devel] [PATCH v2 3/7] xen/arm32: entry: Add missing trap_reset entry

[Julien Grall]

From: Julien Grall 

At the moment, the reset vector is defined as .word 0 (e.g andeq r0, r0,
r0).

This is rather unintuitive and will result to execute the trap
undefined. Instead introduce trap helpers for reset and will generate an
error message in the unlikely case that reset will be called.

This is part of XSA-254.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Replace .word 0 by trap_reset
---
 xen/arch/arm/arm32/entry.S | 3 ++-
 xen/arch/arm/arm32/traps.c | 5 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S
index c6490d2847..64876c1184 100644
--- a/xen/arch/arm/arm32/entry.S
+++ b/xen/arch/arm/arm32/entry.S
@@ -137,7 +137,7 @@ trap_##trap:
\
 
 .align 5
 GLOBAL(hyp_traps_vector)
-.word 0 /* 0x00 - Reset */
+b trap_reset/* 0x00 - Reset */
 b trap_undefined_instruction/* 0x04 - Undefined Instruction */
 b trap_hypervisor_call  /* 0x08 - Hypervisor Call */
 b trap_prefetch_abort   /* 0x0c - Prefetch Abort */
@@ -146,6 +146,7 @@ GLOBAL(hyp_traps_vector)
 b trap_irq  /* 0x18 - IRQ */
 b trap_fiq  /* 0x1c - FIQ */
 
+DEFINE_TRAP_ENTRY(reset)
 DEFINE_TRAP_ENTRY(undefined_instruction)
 DEFINE_TRAP_ENTRY(hypervisor_call)
 DEFINE_TRAP_ENTRY(prefetch_abort)
diff --git a/xen/arch/arm/arm32/traps.c b/xen/arch/arm/arm32/traps.c
index 705255883e..4f27543dec 100644
--- a/xen/arch/arm/arm32/traps.c
+++ b/xen/arch/arm/arm32/traps.c
@@ -23,6 +23,11 @@
 
 #include 
 
+void do_trap_reset(struct cpu_user_regs *regs)
+{
+do_unexpected_trap("Reset", regs);
+}
+
 void do_trap_undefined_instruction(struct cpu_user_regs *regs)
 {
 uint32_t pc = regs->pc;
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 0/7] xen/arm32: Branch predictor hardening (XSA-254 variant 2)

[Julien Grall]

Hi all,

This series provides a skeleton for mitigating branch predictor hardening for
arm32 on exception entry.

It also implements mitigation for Cortex-A12, A15 and A17. SoC vendors with
affected CPUs are strongly encouraged to update.

For more information about the impact of this issue and the software mitigations
for Arm processors, please see http://www.arm.com/security-update.

Cheers,

Julien Grall (7):
  xen/arm32: entry: Consolidate DEFINE_TRAP_ENTRY_* macros
  xen/arm32: Add missing MIDR values for Cortex-A17 and A12
  xen/arm32: entry: Add missing trap_reset entry
  xen/arm32: Add skeleton to harden branch predictor aliasing attacks
  xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12
  xen/arm32: Invalidate icache on guest exist for Cortex-A15
  xen/arm32: entry: Document the purpose of r11 in the traps handler

 xen/arch/arm/Kconfig|   3 +
 xen/arch/arm/arm32/entry.S  | 164 ++--
 xen/arch/arm/arm32/traps.c  |   5 ++
 xen/arch/arm/cpuerrata.c|  62 +++
 xen/include/asm-arm/processor.h |   4 +
 5 files changed, 213 insertions(+), 25 deletions(-)

-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 5/7] xen/arm32: Invalidate BTB on guest exit for Cortex A17 and 12

[Stefano Stabellini]

On Wed, 31 Jan 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 25/01/18 19:35, Stefano Stabellini wrote:
> > > This means that bne will branch only when bit 2 is set. So the only way to
> > > end
> > > here is because the first 3-bit are equal to 0x00X. This corresponds to
> > > IRQ/FIQ vector.
> > 
> > I got it the other way around, thanks for the explanation :-)
> > 
> > Signed-off-by: Stefano Stabellini 
> 
> Did you mean Reviewed-by or Acked-by?

LOL!  I meant Reviewed-by.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 4/7] xen/arm32: Add skeleton to harden branch predictor aliasing attacks

[Stefano Stabellini]

On Wed, 31 Jan 2018, Julien Grall wrote:
> On 26/01/18 16:21, Julien Grall wrote:
> > > "Therefore hypervisor code running with guest vectors table should be
> > > minimized and always have interrupts and async aborts masked to reduce
> > > the risk to use them."
> > > 
> > > Do you think that it is clearer?
> > 
> > Well, that was covered by "interrupts". If you look at the Arm Arm, A, I, F
> > are considered all interrupts.
> 
> I reworked the paragraph and it is now:
> 
> "However, on arm32, each vector contain a single instruction. This means that
> the hardened vector tables may rely on the state of registers that does not
> hold when in the hypervisor (e.g SP is 8 bytes aligned). Therefore hypervisor
> code running with guest vectors table should be
> minimized and always have IRQ and SError masked to reduce the risk to use
> them."

I think it's much better, thanks!

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 5/8] ARM: VGIC: factor out vgic_connect_hw_irq()

[Julien Grall]

On 31/01/18 15:54, Andre Przywara wrote:

Hi,

Yeah! Locking discussions! Have fun below ;-)

On 30/01/18 13:19, Julien Grall wrote:

Hi Andre,

On 24/01/18 18:10, Andre Przywara wrote:

At the moment we happily access VGIC internal data structures like
the rank and struct pending_irq in gic.c, which should be VGIC agnostic.

Factor out a new function vgic_connect_hw_irq(), which allows a virtual
IRQ to be connected to a hardware IRQ (using the hw bit in the LR).

This removes said accesses to VGIC data structures and improves
abstraction.


You are modifying the locking of the 2 functions. But I don't see how
this is safe. Can you explain it?


Are you worried about anything particular? I will explain my reasoning
below, but feel free to point me to the cause of your gripes.


In general, it is quite nice to explain roughly in the commit message 
why the new locking order is ok. It would avoid reviewers to spend time 
guessing why it is fine.


In that particular case I am concerned about any potential concurrent 
access on anything related to a vIRQ.


[...]


   set_bit(_IRQ_GUEST, >status);


This looks wrong to me. You don't want to execute any of the code below
if you are not able to route the pIRQ. For instance because the vIRQ has
already a desc assigned.


Ah, good point. Indeed I didn't consider the failure path. Should be
easily fixed, though. Thanks for catching this.


   @@ -156,31 +141,19 @@ int gic_route_irq_to_guest(struct domain *d,
unsigned int virq,
   gic_set_irq_type(desc, desc->arch.type);
   gic_set_irq_priority(desc, priority);
   -    p->desc = desc;
-    res = 0;
-
-out:
-    vgic_unlock_rank(v_target, rank, flags);
-
-    return res;
+    return vgic_connect_hw_irq(d, NULL, virq, desc);
   }
     /* This function only works with SPIs for now */
   int gic_remove_irq_from_guest(struct domain *d, unsigned int virq,
     struct irq_desc *desc)
   {
-    struct vcpu *v_target = vgic_get_target_vcpu(d->vcpu[0], virq);
-    struct vgic_irq_rank *rank = vgic_rank_irq(v_target, virq);
-    struct pending_irq *p = irq_to_pending(v_target, virq);
-    unsigned long flags;
+    int ret;
     ASSERT(spin_is_locked(>lock));
   ASSERT(test_bit(_IRQ_GUEST, >status));
-    ASSERT(p->desc == desc);


You dropped this assert but I don't see any replacement in the new code?
We really want to make sure the caller will not do something dumb here
(like passing a different desc).


So the first thing here is that I can't have anything dereferencing
struct pending_irq here. Secondly the rank lock (protecting the p->
structure) is only taken below, so nothing prevents this from changing
between the ASSERT and the lock, AFAICS.


You could move the ASSERT within the lock, right?


And to be honest, I don't really get the purpose of this ASSERT: the
desc pointer is taken from the pending_irq in the caller, but without
any locks. So if I am not mistaken, it could race with a
gic_route_irq_to_xen(), and that would lead to the ASSERT triggering,
just because of this race and not because of the code being broken
ultimately.
I *could* get the irq_desc by calling the new vgic_get_hw_irq_desc() -
again. Not sure if that is useful, though.
Another possibility would be to rethink this whole functionality:
The only caller (release_guest_irq() in irq.c) gets a virtual IRQ
number, then finds the associated irq_desc, only to lock it. Then it
passes both the virtual IRQ number and the irq_desc to this function,
where both are rechecked. The reason for this redundancy seems to be
some locking order (irq_desc first?), however I can't find any
documentation about this.
So I wonder if we could just pass on only the virtual IRQ number, and
let it up to this function here to safely retrieve the right irq_desc.


While I agree that the ASSERT without any lock is dangerous, it could at 
least catch someone passing the wrong irq_desc. Something will really go 
wrong if you disable pIRQ A but the irq_desc was belonging to pIRQ B.


And I agree that the code does not prevent that today. But it at least 
limit the scope of the problem.


So I think the code should be:

gic_remove_irq_from_guest(.)
{

   vgic_lock_rank(...)
   if ( p->desc != desc )
   {
vgic_unlock_rank(...)
return -1;
   }

   do the vGIC removal

   vgic_unlock_rank(...)

   return 0;
}




   ASSERT(!is_lpi(virq));
   -    vgic_lock_rank(v_target, rank, flags);


I couldn't find what this lock protects here, so early at least. Until
the actual "p->desc = NULL;" line below nothing needs to be protected by
this lock, it's all already covered by the desc lock.
We only need the lock to eventually atomically remove the connection
between the h/w and the virtual IRQ, which is done in
vgic_connect_hw_irq() now.


See above.

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org

Re: [Xen-devel] [PATCH v3 6/8] ARM: VGIC: factor out vgic_get_hw_irq_desc()

[Andre Przywara]

Hi,

On 31/01/18 16:16, Julien Grall wrote:
> Hi,
> 
> On 24/01/18 18:10, Andre Przywara wrote:
>> At the moment we happily access the VGIC internal struct pending_irq
>> (which describes a virtual IRQ) in irq.c.
>> Factor out the actually needed functionality to learn the associated
>> hardware IRQ and move that into gic-vgic.c to improve abstraction.
>>
>> Signed-off-by: Andre Przywara 
>> Acked-by: Stefano Stabellini 
>> ---
>>   xen/arch/arm/gic-vgic.c    | 15 +++
>>   xen/arch/arm/irq.c |  7 ++-
>>   xen/include/asm-arm/vgic.h |  2 ++
>>   3 files changed, 19 insertions(+), 5 deletions(-)
>>
>> diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
>> index d44e4dacd3..3ad98dcd3a 100644
>> --- a/xen/arch/arm/gic-vgic.c
>> +++ b/xen/arch/arm/gic-vgic.c
>> @@ -411,6 +411,21 @@ void gic_dump_vgic_info(struct vcpu *v)
>>   printk("Pending irq=%d\n", p->irq);
>>   }
>>   +struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu
>> *v,
>> +  unsigned int virq)
>> +{
>> +    struct pending_irq *p;
>> +
>> +    if ( !v )
>> +    v = d->vcpu[0];
> 
> I dislike this new function in the current state. Let's imagine someone
> decide to pass a PPI but no vCPU. The vCPU would now be default to vCPU0
> and potentially returning the wrong irq_desc (imagine PPI passthrough
> such as for the vtimer).
> 
> So the code needs at least checking the vCPU is passed in the case of a
> PPI. I would be happy with an ASSERT().

Yeah, good point. Something like ASSERT(!v && virq >= 32), I guess?

Cheers,
Andre.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 6/8] ARM: VGIC: factor out vgic_get_hw_irq_desc()

[Julien Grall]

Hi,

On 24/01/18 18:10, Andre Przywara wrote:

At the moment we happily access the VGIC internal struct pending_irq
(which describes a virtual IRQ) in irq.c.
Factor out the actually needed functionality to learn the associated
hardware IRQ and move that into gic-vgic.c to improve abstraction.

Signed-off-by: Andre Przywara 
Acked-by: Stefano Stabellini 
---
  xen/arch/arm/gic-vgic.c| 15 +++
  xen/arch/arm/irq.c |  7 ++-
  xen/include/asm-arm/vgic.h |  2 ++
  3 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index d44e4dacd3..3ad98dcd3a 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -411,6 +411,21 @@ void gic_dump_vgic_info(struct vcpu *v)
  printk("Pending irq=%d\n", p->irq);
  }
  
+struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,

+  unsigned int virq)
+{
+struct pending_irq *p;
+
+if ( !v )
+v = d->vcpu[0];


I dislike this new function in the current state. Let's imagine someone 
decide to pass a PPI but no vCPU. The vCPU would now be default to vCPU0 
and potentially returning the wrong irq_desc (imagine PPI passthrough 
such as for the vtimer).


So the code needs at least checking the vCPU is passed in the case of a 
PPI. I would be happy with an ASSERT().


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 1/2] x86/acpi: add retrieval function for rsdp address

[Andy Shevchenko]

On Mon, Jan 29, 2018 at 5:02 AM, Rafael J. Wysocki  wrote:
> On Sun, Jan 28, 2018 at 4:04 PM, Andy Shevchenko
>  wrote:
>> On Fri, Jan 26, 2018 at 8:21 PM, Juergen Gross  wrote:
>>> On 26/01/18 19:08, Andy Shevchenko wrote:
 On Thu, Jan 25, 2018 at 4:36 PM, Juergen Gross  wrote:

 The problem with weak functions that we can't have more than one
 implementation per kernel while we would like to built several code
 paths.

 I have stumbled on the similar stuff and realize that.

 Perhaps, one of the solution is to have an additional struct under
 x86_init to alternate ACPI related stuff.
>>>
>>> I think we can go that route when another user of that interface is
>>> appearing.
>>
>> Why not to establish the struct? At least this route I would like to
>> go with [1].
>>
>> [1]: https://lkml.org/lkml/2018/1/17/834
>
> Maybe I'm a bit slow today, but care to explain what exactly you mean?

Instead of declaring function as __weak, establish a new struct for
ACPI related stubs and incorporate it into x86_init.

That is my proposal. I think I would go this way in my case where I
need to treat differently ACPI HW reduced initialization of legacy
devices.

-- 
With Best Regards,
Andy Shevchenko

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 1/2] x86/acpi: add retrieval function for rsdp address

[Andy Shevchenko]

On Mon, Jan 29, 2018 at 5:01 AM, Rafael J. Wysocki  wrote:
> On Fri, Jan 26, 2018 at 7:08 PM, Andy Shevchenko
>  wrote:

>> I have stumbled on the similar stuff and realize that.
>>
>> Perhaps, one of the solution is to have an additional struct under
>> x86_init to alternate ACPI related stuff.
>
> I'm not sure if that really is a problem in this particular case.
>
> Why would you want to use different RSDP retrieval functions for one arch?

I was not clear. I'm talking about approach struct x86_init vs. __weak function.
In my case it has nothing to do with RDSP, but with ACPI stubs.

-- 
With Best Regards,
Andy Shevchenko

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] x86/shim: don't use 32-bit compare on boolean variable

[Jan Beulich]

Current upstream gas silently assumes 32-bit operand size for most
operations where the size can't be inferred from an involved register
(my own one doesn't anymore, which is how I've noticed this). It is pure
luck that the 3 bytes following pvh_boot are currently padding ones.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -586,7 +586,7 @@ trampoline_setup:
 push%eax/* Magic number. */
 callreloc
 #ifdef CONFIG_PVH_GUEST
-cmp $0, sym_fs(pvh_boot)
+cmpb$0, sym_fs(pvh_boot)
 je  1f
 mov %eax, sym_fs(pvh_start_info_pa)
 jmp 2f




___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 0.5/5] arm/alternatives: Drop the !HAS_ALTERNATIVE infrastructure

[Julien Grall]

Hi,

On 30/01/18 11:31, Andrew Cooper wrote:

On 30/01/18 11:29, Julien Grall wrote:

Hi Andrew,

Thank you for doing the clean-up.

On 30/01/18 11:16, Andrew Cooper wrote:

ARM now unconditionally selects HAS_ALTERNATIVE, which has caused the
!HAS_ALTERNATIVE code in include/asm-arm/alternative.h to bitrot to
the point
of failing to compile.

Expand all the CONFIG_HAS_ALTERNATIVE references in ARM code.

Signed-off-by: Andrew Cooper 
---
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Konrad Rzeszutek Wilk 

N.B. Only compile tested
---
   xen/arch/arm/xen.lds.S    |  2 --
   xen/include/asm-arm/alternative.h | 15 ---
   xen/test/livepatch/xen_hello_world_func.c |  2 +-


You forgot on in include/asm-arm/cpuerrata.h :).


Oops - so I did.  Folded this incremental diff.


With that folded:

Acked-by: Julien Grall 

Cheers,



~Andrew

diff --git a/xen/include/asm-arm/cpuerrata.h
b/xen/include/asm-arm/cpuerrata.h
index 7de6836..4e45b23 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -7,8 +7,6 @@
  void check_local_cpu_errata(void);
  void enable_errata_workarounds(void);
  
-#ifdef CONFIG_HAS_ALTERNATIVE

-
  #define CHECK_WORKAROUND_HELPER(erratum, feature, arch) \
  static inline bool check_workaround_##erratum(void) \
  {   \
@@ -27,19 +25,6 @@ static inline bool
check_workaround_##erratum(void) \
  }   \
  }
  
-#else /* CONFIG_HAS_ALTERNATIVE */

-
-#define CHECK_WORKAROUND_HELPER(erratum, feature, arch) \
-static inline bool check_workaround_##erratum(void) \
-{   \
-    if ( !IS_ENABLED(arch) )    \
-    return false;   \
-    else    \
-    return unlikely(cpus_have_cap(feature));    \
-}
-
-#endif
-
  CHECK_WORKAROUND_HELPER(766422, ARM32_WORKAROUND_766422, CONFIG_ARM_32)
  CHECK_WORKAROUND_HELPER(834220, ARM64_WORKAROUND_834220, CONFIG_ARM_64)
  



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel



--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Access I2C bus from guest/DomU on ARM board

[Andrii Anisov]

Hello Saumya,


On 18.01.18 09:50, Saumya Rajesh wrote:

Actually I am planning to set up Android as guest in Xen.

I see.

In order to enable sound in the Android guest, I need to passthrough 
the audio codec device which communicates through the I2C bus. For 
BE/FE scheme, I think sharing the internal DMA and clock would pose 
problems. So I'm going to go ahead with the device passthrough way.
Passing through I2C bus to guest domain would not be enough to get sound 
in Android. You would face more dependencies, and they may appear not 
solvable.


Any thoughts or inputs you can possibly give regarding this use case 
will be very helpful and valuable.

We are using PV Audio solution for such a task:

https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg02428.html
https://lkml.org/lkml/2017/8/7/115

--

*Andrii Anisov*



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCHv2] xen-netfront: remove warning when unloading module

[Oleksandr Andrushchenko]

Hi, Eduardo!

I am working on a frontend driver (PV DRM) and also seeing some strange

things on driver unloading:

xt# rmmod -f drm_xen_front.ko
[ 3236.462497] [drm] Unregistering XEN PV vdispl
[ 3236.485745] [drm:xen_drv_remove [drm_xen_front]] *ERROR* Backend 
state is InitWait while removing driver

[ 3236.486950] vdispl vdispl-0: 22 freeing event channel 11
[ 3236.496123] vdispl vdispl-0: failed to write error node for 
device/vdispl/0 (22 freeing event channel 11)

[ 3236.496271] vdispl vdispl-0: 22 freeing event channel 12
[ 3236.501633] vdispl vdispl-0: failed to write error node for 
device/vdispl/0 (22 freeing event channel 12)


These are somewhat different from your use-case with grant references, 
but I have a question:


do you really see that XenbusStateClosed and XenbusStateClosing are

called? In my driver I can't see those and once I tried to dig deeper 
into the problem


I saw that on driver removal it is disconnected from XenBus, so no 
backend state


change events come in via .otherend_changed callback.

The only difference I see here is that the backend is a user-space 
application


Thank you,
Oleksandr

On 11/23/2017 04:18 PM, Eduardo Otubo wrote:

v2:
  * Replace busy wait with wait_event()/wake_up_all()
  * Cannot garantee that at the time xennet_remove is called, the
xen_netback state will not be XenbusStateClosed, so added a
condition for that
  * There's a small chance for the xen_netback state is
XenbusStateUnknown by the time the xen_netfront switches to Closed,
so added a condition for that.

When unloading module xen_netfront from guest, dmesg would output
warning messages like below:

   [  105.236836] xen:grant_table: WARNING: g.e. 0x903 still in use!
   [  105.236839] deferring g.e. 0x903 (pfn 0x35805)

This problem relies on netfront and netback being out of sync. By the time
netfront revokes the g.e.'s netback didn't have enough time to free all of
them, hence displaying the warnings on dmesg.

The trick here is to make netfront to wait until netback frees all the g.e.'s
and only then continue to cleanup for the module removal, and this is done by
manipulating both device states.

Signed-off-by: Eduardo Otubo 
---
  drivers/net/xen-netfront.c | 18 ++
  1 file changed, 18 insertions(+)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 8b8689c6d887..391432e2725d 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -87,6 +87,8 @@ struct netfront_cb {
  /* IRQ name is queue name with "-tx" or "-rx" appended */
  #define IRQ_NAME_SIZE (QUEUE_NAME_SIZE + 3)
  
+static DECLARE_WAIT_QUEUE_HEAD(module_unload_q);

+
  struct netfront_stats {
u64 packets;
u64 bytes;
@@ -2021,10 +2023,12 @@ static void netback_changed(struct xenbus_device *dev,
break;
  
  	case XenbusStateClosed:

+   wake_up_all(_unload_q);
if (dev->state == XenbusStateClosed)
break;
/* Missed the backend's CLOSING state -- fallthrough */
case XenbusStateClosing:
+   wake_up_all(_unload_q);
xenbus_frontend_closed(dev);
break;
}
@@ -2130,6 +2134,20 @@ static int xennet_remove(struct xenbus_device *dev)
  
  	dev_dbg(>dev, "%s\n", dev->nodename);
  
+	if (xenbus_read_driver_state(dev->otherend) != XenbusStateClosed) {

+   xenbus_switch_state(dev, XenbusStateClosing);
+   wait_event(module_unload_q,
+  xenbus_read_driver_state(dev->otherend) ==
+  XenbusStateClosing);
+
+   xenbus_switch_state(dev, XenbusStateClosed);
+   wait_event(module_unload_q,
+  xenbus_read_driver_state(dev->otherend) ==
+  XenbusStateClosed ||
+  xenbus_read_driver_state(dev->otherend) ==
+  XenbusStateUnknown);
+   }
+
xennet_disconnect_backend(info);
  
  	unregister_netdev(info->netdev);



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

[Volodymyr Babchuk]

On 31.01.18 16:54, Julien Grall wrote:


On 31/01/18 11:32, Volodymyr Babchuk wrote:
I thought about vpsci.h, but basically you will have only 2 
functions in it and

the number of PSCI calls. That's it.


Is  this really a problem? It is quite natural to find declarations 
for something.c in something.h. By moving declaration into different 
file, you are hiding it from anyone who does not carry sacred 
knowledge (or use grep/cscope, yes).
And then, when people decide to extend something.c they continue to 
put declarations into inappropriate.h. Just look at processor.h as a 
good example. All functions it define are implemented either in 
traps.c or domain.c. But functions from processor.c are defined in 
procinfo.h.

I can tell for sure, that this confuses newbies.


So it is not going to help to update because the header will 
unlikely need to

change when adding new PSCI call.


Yes. But at least we can put comment above switch(fid):

/* Please don't forget to update call count in (v)psci.h */


See my answer on my own e-mail I sent few minutes ago. I said I will 
create a the vpsci.h.




I can't find it anywhere. I even tried Markmail. Would you please 
point it to me?


I wrote it somewhere and thought I sent but I can't find it :/. Sorry 
for that.



Ah, I see. It is okay.

I was saying after some thought, I will create a header vpsic.h with 
number in it.


I will also add a comment as you suggested.


Thanks. I'm fine with this.



--
Volodymyr Babchuk

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

[Julien Grall]

On 31/01/18 14:29, Volodymyr Babchuk wrote:

Hi,


Hi Volodymyr,


On 31.01.18 13:36, Julien Grall wrote:

Hi,

On 31/01/18 11:32, Volodymyr Babchuk wrote:
I thought about vpsci.h, but basically you will have only 2 
functions in it and

the number of PSCI calls. That's it.


Is  this really a problem? It is quite natural to find declarations 
for something.c in something.h. By moving declaration into different 
file, you are hiding it from anyone who does not carry sacred 
knowledge (or use grep/cscope, yes).
And then, when people decide to extend something.c they continue to 
put declarations into inappropriate.h. Just look at processor.h as a 
good example. All functions it define are implemented either in 
traps.c or domain.c. But functions from processor.c are defined in 
procinfo.h.

I can tell for sure, that this confuses newbies.


So it is not going to help to update because the header will 
unlikely need to

change when adding new PSCI call.


Yes. But at least we can put comment above switch(fid):

/* Please don't forget to update call count in (v)psci.h */


See my answer on my own e-mail I sent few minutes ago. I said I will 
create a the vpsci.h.




I can't find it anywhere. I even tried Markmail. Would you please point 
it to me?


I wrote it somewhere and thought I sent but I can't find it :/. Sorry 
for that.


I was saying after some thought, I will create a header vpsic.h with 
number in it.


I will also add a comment as you suggested.

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 4.10] SUPPORT.md: Fix version and Initial-Release

[Jan Beulich]

>>> On 31.01.18 at 14:10,  wrote:
> On 31/01/18 13:06, Ian Jackson wrote:
>> Security-Support-Until should be `TBD'.  We need to answer these
>> questions properly, but let's not block fixing the obvious bugs here
>> for that policy discussion.
>>
>> CC: Andrew Cooper 
>> CC: Lars Kurth 
>> Reported-by: Andrew Cooper 
>> Signed-off-by: Ian Jackson 
>> ---
>>  SUPPORT.md | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/SUPPORT.md b/SUPPORT.md
>> index 42ffa9f..55170d9 100644
>> --- a/SUPPORT.md
>> +++ b/SUPPORT.md
>> @@ -9,10 +9,10 @@ for the definitions of the support status levels etc.
>>  
>>  # Release Support
>>  
>> -Xen-Version: 4.10-unstable
>> -Initial-Release: n/a
>> +Xen-Version: 4.10
> 
> Is it worth making this 4.10.0 ?  We are liable to make changes to the
> document over the course of the point releases.
> 
> Either way, Acked-by: Andrew Cooper 

For the purpose of the document I think leaving out the stable
release number is fine.

Acked-by: Jan Beulich 

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable-smoke test] 118485: tolerable all pass - PUSHED

[osstest service owner]

flight 118485 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118485/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  9885e4d81ff27e51a221c7987cbc36c520cb0b21
baseline version:
 xen  ac37ec1ddef234eeba6f438c29ff687c64962ebd

Last test of basis   118479  2018-01-31 11:01:09 Z0 days
Testing same since   118485  2018-01-31 13:01:08 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Roger Pau Monné 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   ac37ec1dde..9885e4d81f  9885e4d81ff27e51a221c7987cbc36c520cb0b21 -> smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

[Volodymyr Babchuk]

Hi,

On 31.01.18 13:36, Julien Grall wrote:

Hi,

On 31/01/18 11:32, Volodymyr Babchuk wrote:
I thought about vpsci.h, but basically you will have only 2 functions 
in it and

the number of PSCI calls. That's it.


Is  this really a problem? It is quite natural to find declarations 
for something.c in something.h. By moving declaration into different 
file, you are hiding it from anyone who does not carry sacred 
knowledge (or use grep/cscope, yes).
And then, when people decide to extend something.c they continue to 
put declarations into inappropriate.h. Just look at processor.h as a 
good example. All functions it define are implemented either in 
traps.c or domain.c. But functions from processor.c are defined in 
procinfo.h.

I can tell for sure, that this confuses newbies.


So it is not going to help to update because the header will unlikely 
need to

change when adding new PSCI call.


Yes. But at least we can put comment above switch(fid):

/* Please don't forget to update call count in (v)psci.h */


See my answer on my own e-mail I sent few minutes ago. I said I will 
create a the vpsci.h.




I can't find it anywhere. I even tried Markmail. Would you please point 
it to me?


[...]

--
Volodymyr Babchuk

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.9-testing test] 118452: regressions - FAIL

[osstest service owner]

flight 118452 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118452/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2  broken  in 118314
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail in 118438 REGR. vs. 
118167

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2  4 host-install(4) broken in 118314 pass in 118452
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 118438 
pass in 118452
 test-amd64-i386-xl-qemut-ws16-amd64 18 guest-start/win.repeat fail pass in 
118314
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail pass in 
118438

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 118438 
blocked in 118222
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 118438 like 
118167
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail in 118438 like 118167
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop   fail in 118438 like 118167
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail in 118438 like 118222
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118222
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118222
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118222
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118222
 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 118222
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install

Re: [Xen-devel] [PATCH 4.10] SUPPORT.md: Fix version and Initial-Release

[Andrew Cooper]

On 31/01/18 13:06, Ian Jackson wrote:
> Security-Support-Until should be `TBD'.  We need to answer these
> questions properly, but let's not block fixing the obvious bugs here
> for that policy discussion.
>
> CC: Andrew Cooper 
> CC: Lars Kurth 
> Reported-by: Andrew Cooper 
> Signed-off-by: Ian Jackson 
> ---
>  SUPPORT.md | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 42ffa9f..55170d9 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -9,10 +9,10 @@ for the definitions of the support status levels etc.
>  
>  # Release Support
>  
> -Xen-Version: 4.10-unstable
> -Initial-Release: n/a
> +Xen-Version: 4.10

Is it worth making this 4.10.0 ?  We are liable to make changes to the
document over the course of the point releases.

Either way, Acked-by: Andrew Cooper 

> +Initial-Release: 2017-12-13
>  Supported-Until: TBD
> -Security-Support-Until: Unreleased - not yet security-supported
> +Security-Support-Until: TBD
>  
>  # Feature Support
>  


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/2] release-checklist.txt: Say to increment SUPPORT.md version number

[Andrew Cooper]

On 31/01/18 13:03, Ian Jackson wrote:
> CC: Andrew Cooper 
> Reported-by: Andrew Cooper 
> Signed-off-by: Ian Jackson 
> ---
>  docs/process/release-checklist.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/docs/process/release-checklist.txt 
> b/docs/process/release-checklist.txt
> index b96964e..c791ad2 100644
> --- a/docs/process/release-checklist.txt
> +++ b/docs/process/release-checklist.txt
> @@ -50,6 +50,7 @@ t=RELEASE-$r
>  
>  * change xen-unstable README (should say "Xen 4.5" in releases and on stable 
> branches, "Xen 4.5-unstable" on unstable)
>  * change xen-unstable Config.mk (QEMU_UPSTREAM_REVISION, 
> QEMU_TRADITIONAL_REVISION, MINIOS_UPSTREAM_REVISION)
> +* change SUPPORT.md heading
>  * change xen-unstable xen/Makefile XEN_EXTRAVERSION
>  # if main version number has changed (eg 4.7 -> 4.8) rerun ./autogen.sh
>  * rerun ./autogen.sh to update version number in configure

This also (somewhere) needs an "edit staging-$X.$Y's SUPPORT.md" to fill
in the heading.

On that note, 4.10's block currently says:

# Release Support

    Xen-Version: 4.10-unstable
    Initial-Release: n/a
    Supported-Until: TBD
    Security-Support-Until: Unreleased - not yet security-supported

which is stale.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 4.10] SUPPORT.md: Fix version and Initial-Release

[Ian Jackson]

Security-Support-Until should be `TBD'.  We need to answer these
questions properly, but let's not block fixing the obvious bugs here
for that policy discussion.

CC: Andrew Cooper 
CC: Lars Kurth 
Reported-by: Andrew Cooper 
Signed-off-by: Ian Jackson 
---
 SUPPORT.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index 42ffa9f..55170d9 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -9,10 +9,10 @@ for the definitions of the support status levels etc.
 
 # Release Support
 
-Xen-Version: 4.10-unstable
-Initial-Release: n/a
+Xen-Version: 4.10
+Initial-Release: 2017-12-13
 Supported-Until: TBD
-Security-Support-Until: Unreleased - not yet security-supported
+Security-Support-Until: TBD
 
 # Feature Support
 
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 2/2] release-checklist.txt: Say to increment SUPPORT.md version number

[Ian Jackson]

CC: Andrew Cooper 
Reported-by: Andrew Cooper 
Signed-off-by: Ian Jackson 
---
 docs/process/release-checklist.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/docs/process/release-checklist.txt 
b/docs/process/release-checklist.txt
index b96964e..c791ad2 100644
--- a/docs/process/release-checklist.txt
+++ b/docs/process/release-checklist.txt
@@ -50,6 +50,7 @@ t=RELEASE-$r
 
 * change xen-unstable README (should say "Xen 4.5" in releases and on stable 
branches, "Xen 4.5-unstable" on unstable)
 * change xen-unstable Config.mk (QEMU_UPSTREAM_REVISION, 
QEMU_TRADITIONAL_REVISION, MINIOS_UPSTREAM_REVISION)
+* change SUPPORT.md heading
 * change xen-unstable xen/Makefile XEN_EXTRAVERSION
 # if main version number has changed (eg 4.7 -> 4.8) rerun ./autogen.sh
 * rerun ./autogen.sh to update version number in configure
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 1/2] SUPPORT.md: increment version number

[Ian Jackson]

CC: Andrew Cooper 
Reported-by: Andrew Cooper 
Signed-off-by: Ian Jackson 
---
 SUPPORT.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index 42ffa9f..a1810b8 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -9,7 +9,7 @@ for the definitions of the support status levels etc.
 
 # Release Support
 
-Xen-Version: 4.10-unstable
+Xen-Version: 4.11-unstable
 Initial-Release: n/a
 Supported-Until: TBD
 Security-Support-Until: Unreleased - not yet security-supported
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2] x86/emul: Split exception handling out of invoke_stub()

[Andrew Cooper]

For a release build, bloat-o-meter reports:

  add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-5111 (-5111)
  function old new   delta
  x86_emulate   126458  121347   -5111

or in other words, a 4% redunction in code size from this change alone.

The use of __LINE__ is a concern with livepatching, but any livepatch touching
this file is overwhemlingly likely to alter x86_emulate() anyway.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 

v2:
 * Retain __LINE__.  It can't be embedded in union stub_exception_token as the
   full token gets written by the exception hanlder.
---
 xen/arch/x86/x86_emulate/x86_emulate.c | 37 +-
 1 file changed, 23 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index 4cc51ea..c9221c8 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -866,7 +866,8 @@ static inline int mkec(uint8_t e, int32_t ec, ...)
 
 #ifdef __XEN__
 # define invoke_stub(pre, post, constraints...) do {\
-union stub_exception_token res_ = { .raw = ~0 };\
+stub_exn_info = (union stub_exception_token) { .raw = ~0 }; \
+stub_exn_line = __LINE__; /* Utility outweighs livepatching cost */ \
 asm volatile ( pre "\n\tINDIRECT_CALL %[stub]\n\t" post "\n"\
".Lret%=:\n\t"   \
".pushsection .fixup,\"ax\"\n"   \
@@ -875,21 +876,11 @@ static inline int mkec(uint8_t e, int32_t ec, ...)
"jmp .Lret%=\n\t"\
".popsection\n\t"\
_ASM_EXTABLE(.Lret%=, .Lfix%=)   \
-   : [exn] "+g" (res_), constraints,\
+   : [exn] "+g" (stub_exn_info), constraints,   \
  [stub] "r" (stub.func),\
  "m" (*(uint8_t(*)[MAX_INST_LEN + 1])stub.ptr) );   \
-if ( unlikely(~res_.raw) )  \
-{   \
-gprintk(XENLOG_WARNING, \
-"exception %u (ec=%04x) in emulation stub (line %u)\n", \
-res_.fields.trapnr, res_.fields.ec, __LINE__);  \
-gprintk(XENLOG_INFO, "stub: %"__stringify(MAX_INST_LEN)"ph\n",  \
-stub.func); \
-generate_exception_if(res_.fields.trapnr == EXC_UD, EXC_UD);\
-domain_crash(current->domain);  \
-rc = X86EMUL_UNHANDLEABLE;  \
-goto done;  \
-}   \
+if ( unlikely(~stub_exn_info.raw) ) \
+goto emulation_stub_failure;\
 } while (0)
 #else
 # define invoke_stub(pre, post, constraints...) \
@@ -3017,6 +3008,10 @@ x86_emulate(
 struct fpu_insn_ctxt fic = { .type = X86EMUL_FPU_none, .exn_raised = -1 };
 struct x86_emulate_stub stub = {};
 DECLARE_ALIGNED(mmval_t, mmval);
+#ifdef __XEN__
+union stub_exception_token stub_exn_info;
+unsigned int stub_exn_line;
+#endif
 
 ASSERT(ops->read);
 
@@ -8023,6 +8018,20 @@ x86_emulate(
 put_stub(stub);
 return rc;
 #undef state
+
+#ifdef __XEN__
+ emulation_stub_failure:
+gprintk(XENLOG_WARNING,
+"exception %u (ec=%04x) in emulation stub (line %u)\n",
+stub_exn_info.fields.trapnr, stub_exn_info.fields.ec,
+stub_exn_line);
+gprintk(XENLOG_INFO, "  stub: %"__stringify(MAX_INST_LEN)"ph\n",
+stub.func);
+generate_exception_if(stub_exn_info.fields.trapnr == EXC_UD, EXC_UD);
+domain_crash(current->domain);
+rc = X86EMUL_UNHANDLEABLE;
+goto done;
+#endif
 }
 
 #undef op_bytes
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable-smoke test] 118479: tolerable all pass - PUSHED

[osstest service owner]

flight 118479 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118479/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  ac37ec1ddef234eeba6f438c29ff687c64962ebd
baseline version:
 xen  16a31ca735165e63d67e86f60996f2b6a31cc0ee

Last test of basis   118460  2018-01-30 20:01:40 Z0 days
Testing same since   118479  2018-01-31 11:01:09 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   16a31ca735..ac37ec1dde  ac37ec1ddef234eeba6f438c29ff687c64962ebd -> smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 1/3] xen/arm: io: Distinguish unhandled IO from aborted one

[Julien Grall]

Hi Stefano,

On 30/01/18 19:09, Stefano Stabellini wrote:

On Tue, 30 Jan 2018, Julien Grall wrote:

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index c8534d6cff..843adf4959 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1864,10 +1864,10 @@ static inline bool hpfar_is_valid(bool s1ptw,
uint8_t fsc)
   return s1ptw || (fsc == FSC_FLT_TRANS &&
!check_workaround_834220());
   }
   -static bool try_handle_mmio(struct cpu_user_regs *regs,
-const union hsr hsr,
-paddr_t gpa)
-{
+static enum io_state try_handle_mmio(struct cpu_user_regs *regs,
+ const union hsr hsr,
+ paddr_t gpa)
+ {
   const struct hsr_dabt dabt = hsr.dabt;
   mmio_info_t info = {
   .gpa = gpa,
@@ -1879,11 +1879,11 @@ static bool try_handle_mmio(struct cpu_user_regs
*regs,
 /* stage-1 page table should never live in an emulated MMIO region
*/
   if ( dabt.s1ptw )
-return false;
+return IO_UNHANDLED;
 /* All the instructions used on emulated MMIO region should be
valid */
   if ( !dabt.valid )
-return false;
+return IO_UNHANDLED;
 /*
* Erratum 766422: Thumb store translation fault to Hypervisor may
@@ -1896,11 +1896,11 @@ static bool try_handle_mmio(struct cpu_user_regs
*regs,
   if ( rc )
   {
   gprintk(XENLOG_DEBUG, "Unable to decode instruction\n");
-return false;
+return IO_ABORT;
   }
   }


Why do the first two error checks result in IO_UNHANDLED, while the
third result in IO_ABORT? Specifically in relation to pagetable walk
failures due to someone else changing stage-2 entry simultaneously (see
comment toward the end of do_trap_stage2_abort_guest)?


Good question. Somehow I considered the first two as part of looking up the
proper handler and not the device itself.

But I guess that at this stage we know that IO was targeting an emulated
region. So we can return IO_ABORT.


That is what I thought as well


Actually, I have said something completely wrong yesterday. Must have 
been too tired :/.


At the time you call try_handle_mmio, you still don't know whether the 
fault was because of accessing an emulated MMIO region. You will only be 
sure when find_mmio_handler() has returned a non-NULL pointer (see 
handle_mmio()).


So returning IO_UNHANDLED here is correct as you want to try another 
method to handle the fault.


However, it also means that even bad access to emulated region will 
result to fallback on another method. While this should not be issue, I 
don't think this is future proof (I am mostly worry on the ACPI case 
where MMIO are mapped on-demand).


So I will send a patch to fold try_handle_mmio() into handle_mmio().





On a side note, it looks like the check dabt.s1ptw is unnecessary because a
stage 2 abort on stage 1 translation table lookup will not return a valid
instruction syndrome (see B3-1433 in DDI 0406C.c and D10-2460 in DDI 0487C.a).


in that case, go ahead and remove it as part of this patch, mention it
in the commit message


I will do that in a patch that fold try_handle_mmio() in handle_mmio().

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 0/3] xen/arm: Inject an exception to the guest rather than crashing it

[Julien Grall]

Hi Stefano,

On 30/01/18 19:21, Stefano Stabellini wrote:

On Tue, 30 Jan 2018, Julien Grall wrote:

Hi,

On 30/01/18 18:29, Andrew Cooper wrote:

On 30/01/18 17:00, Julien Grall wrote:



On 30/01/18 16:38, Andrew Cooper wrote:

On 30/01/18 16:14, Julien Grall wrote:

Hi all,

This small series replaces all call to domain_crash_synchronous by
injecting
an exception to the guest.

This will result to a nicer trace from the guest (no need to
manually walk
the stack) and give a chance to the guest to give a bit more
information on
what it was doing.

Cheers,

Julien Grall (3):
     xen/arm: io: Distinguish unhandled IO from aborted one
     xen/arm: Don't crash domain on bad MMIO emulation
     xen/arm: Don't crash the domain on invalid HVC immediate


Thanks.

I don't feel qualified to review these, but some notes.

Patch 1.  s/avodi/avoid/ in the commit message

Patches 2 and 3.  You probably want to convert the printks to
gdprintk()s, otherwise guests can choke up the ratelimited log.  Doing
so will also mean that the vcpu will be identified consistently, which
it isn't currently.

We didn't use g*printk because it would be more confusing to print the
current vCPU in some cases (e.g when accessing the re-distributor of
another vCPU) or does not matter (e.g for ITS).


In the former case, you'd want to print both current, and the target
vcpu.  The latter still matters what current is if something goes wrong.

We have plenty of similar cases in x86, but at the point you are
printing an diagnostic message, ignoring current is almost always the
wrong think to do.


I will look at it on another series.





The problem with the debug version is those information are actually
quite useful in non-debug build. We found quite a few issues thanks to
them.

I think it would make more sense for Xen to provide per-guest
ratelimited than hiding those messages in non-debug build.


Per guest is quite a lot more complicated than global, and would still
require a global limit to prevent a concerted attack from multiple
guests to avoid DoSing the system.

Debug vs unilateral is your prerogative as a maintainer, but as you've
said yourself, the are used for debugging purposes, which proves my point.


So on x86, you always request the user to reproduce it with debug build
enable?

Stefano, what's your opinion here?


I think it would be great to have per-guest rate limiting.

On ARM, it would be impossible to ask users to repro with debug enabled,
given that many deployments are embedded (set-top boxes, etc).

I think it is OK to keep the XENLOG_DEBUG, they should be filtered out
by loglvl. But we need to be careful about the others. We might want to
convert the XENLOG_WARNING in traps.c to XENLOG_DEBUG: they are warning
about guests misbehaving, but from the hypervisor point of view, it's not
a problem, guests can shoot themselves if they want to; it's OK.


Not really. Some of the XENLOG_WARNING may happen because Xen does not 
handle a trap (see the one on do_trap_guest_sync). That has nothing to 
do with a guest misbehaving and could happen if Xen boots on newer hardware.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] ThunderX support in Xen

[Julien Grall]

Hi Stefano,

On 31/01/18 00:01, Stefano Stabellini wrote:
> I am testing Xen support in ThunderX, but I am having some issues
> booting Dom0 using Xen staging and the Ubuntu Xenial kernel (it has
> CONFIG_XEN enabled). The trace is appened to this email. I am using the
> device tree converted from /proc/device-tree on the running system
> without Xen.

Why do you need to convert the DT from /proc/device-tree? You should just
rely on the one provided by the firmware directly.

> [3.273098] Unable to handle kernel NULL pointer dereference at virtual 
> address 0080
> [3.281254] pgd = 0946d000
> [3.284721] [0080] *pgd=bfffe003, *pud=bfffd003, 
> *pmd=
> [3.293059] Internal error: Oops: 9604 [#1] SMP
> [3.298001] Modules linked in:
> [3.301127] CPU: 81 PID: 1 Comm: swapper/0 Not tainted 4.10.0-38-generic 
> #42~16.04.1-Ubuntu
> [3.309564] Hardware name: cavium,thunder-88xx (DT)
> [3.314492] task: 80007c573a00 task.stack: 80007c578000
> [3.320485] PC is at arm_smmu_device_cfg_probe+0x300/0x770
> [3.326039] LR is at arm_smmu_device_cfg_probe+0x25c/0x770

SMMU should not be assigned to the hardware domain. Cavium has a specific
compatible for their SMMUs which is not in Xen yet.

There was an attempt to add the compatible in Xen (see [1] which I didn't
ack because the SMMU changes for Cavium were not added.

Until the SMMU driver properly support Cavium's SMMU, we should blacklist
them.

When working on getting Xen booting on rochester{0,1} (Thunder-X in Osstest),
I blacklist them with this small patch. I will clean-up it and send it on the 
ML:

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 155c952349..8b7fb0e12a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1182,6 +1182,7 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 DT_MATCH_TYPE("memory"),
 /* The memory mapped timer is not supported by Xen. */
 DT_MATCH_COMPATIBLE("arm,armv7-timer-mem"),
+DT_MATCH_COMPATIBLE("cavium,smmu-v2"),
 { /* sentinel */ },
 };
 static const struct dt_device_match timer_matches[] __initconst =

The only other issues I found was when booting using Grub. I needed to bump the
number of banks.

By the way, if you haven't done it. I would highly recommend to upgrade to the 
latest
firmware.

Cheers,

[1] https://lists.xen.org/archives/html/xen-devel/2017-06/msg02293.html

-- 
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

[Julien Grall]

Hi,

On 31/01/18 11:32, Volodymyr Babchuk wrote:
I thought about vpsci.h, but basically you will have only 2 functions 
in it and

the number of PSCI calls. That's it.


Is  this really a problem? It is quite natural to find declarations for 
something.c in something.h. By moving declaration into different file, 
you are hiding it from anyone who does not carry sacred knowledge (or 
use grep/cscope, yes).
And then, when people decide to extend something.c they continue to put 
declarations into inappropriate.h. Just look at processor.h as a good 
example. All functions it define are implemented either in traps.c or 
domain.c. But functions from processor.c are defined in procinfo.h.

I can tell for sure, that this confuses newbies.


So it is not going to help to update because the header will unlikely 
need to

change when adding new PSCI call.


Yes. But at least we can put comment above switch(fid):

/* Please don't forget to update call count in (v)psci.h */


See my answer on my own e-mail I sent few minutes ago. I said I will 
create a the vpsci.h.






[...]



I looked at some implementation of SMCCC and those calls are either not
handled or the number are not correct.


I agree that *some* implementations can not conform to SMCCC.But, I 
thought

you want Xen to follow standards as close as possible...


It is not about cannot conform but only implements partially SMCCC. I 
could name

ATF for that (yes).

So it makes me more confident the call count is not something people 
seem to

care.


So, you propose to fix this only when something will trip over this?


No, I am just saying that it is not that important if we get it wrong. 
That number does not tell you anything. You can have 2 functions and 
still does not know where they are (it is not always possible to just 
probe a function ID because they may have side-effect).


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

[Volodymyr Babchuk]

Hi Julien,

On 31.01.18 00:06, Julien Grall wrote:

On 30 January 2018 at 19:35, Volodymyr Babchuk
 wrote:



On 30.01.18 20:44, Julien Grall wrote:




On 30/01/18 18:28, Volodymyr Babchuk wrote:


Hi Julien,

On 30.01.18 20:01, Julien Grall wrote:




On 26/01/18 18:27, Volodymyr Babchuk wrote:


Hi,



Hi Volodymyr,


On 26.01.18 20:15, Julien Grall wrote:


Hi,

On 26/01/18 18:09, Volodymyr Babchuk wrote:


On 24.01.18 20:34, Julien Grall wrote:


-case PSCI_0_2_FN32(AFFINITY_INFO):
-case PSCI_0_2_FN64(AFFINITY_INFO):
+switch ( fid )
   {
-register_t taff = PSCI_ARG(regs, 1);
-uint32_t laff = PSCI_ARG32(regs, 2);
-
-perfc_incr(vpsci_cpu_affinity_info);
-PSCI_SET_RESULT(regs, do_psci_0_2_affinity_info(taff,
laff));
-return true;
-}
-
   case ARM_SMCCC_FUNC_CALL_COUNT(STANDARD):
   return fill_function_call_count(regs,
SSSC_SMCCC_FUNCTION_COUNT);


Now definition SSSC_SMCCC_FUNCTION_COUNT depends on code in vscpi.c.
Maybe it is time to introduce function get_psci_0_2_fn_count() and
use it there, what do you think?



Definitely not a function. It is a static number. But I can think of
separate the call count.


Yep, separate call count for vPSCI and for SSSC itself would be a good
thing.



Looking a bit more into it, this will not make a real improvement. This
will be equally difficult to remember to update the call count.


Nevertheless, I think that it is right thing to hold call count in the
same file, where calls are implemented. This increases chances that call
count will be held in sync.



So you are suggesting to implement a function? If so, that's a no-go from
my side.


I'm not insist on function if you can propose alternative.
But why you are against getter function in the first place?


Because a function returning a const value is pretty dumb.


I can't agree with you there. In my opinion - if it is needed for 
clarity - then it is fine.


Nevertheless, you have my opinion. It is up to you what to do with it.



I wanted to propose another approach: define this call count in
vpsci.h, but there is no vpsci.h, instead you use psci.h, which is confusing
in itself.


I thought about vpsci.h, but basically you will have only 2 functions in it and
the number of PSCI calls. That's it.


Is  this really a problem? It is quite natural to find declarations for 
something.c in something.h. By moving declaration into different file, 
you are hiding it from anyone who does not carry sacred knowledge (or 
use grep/cscope, yes).
And then, when people decide to extend something.c they continue to put 
declarations into inappropriate.h. Just look at processor.h as a good 
example. All functions it define are implemented either in traps.c or 
domain.c. But functions from processor.c are defined in procinfo.h.

I can tell for sure, that this confuses newbies.



So it is not going to help to update because the header will unlikely need to
change when adding new PSCI call.


Yes. But at least we can put comment above switch(fid):

/* Please don't forget to update call count in (v)psci.h */



[...]



I looked at some implementation of SMCCC and those calls are either not
handled or the number are not correct.


I agree that *some* implementations can not conform to SMCCC.But, I thought
you want Xen to follow standards as close as possible...


It is not about cannot conform but only implements partially SMCCC. I could name
ATF for that (yes).

So it makes me more confident the call count is not something people seem to
care.


So, you propose to fix this only when something will trip over this?

--
Volodymyr Babchuk

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 1/4] x86/emul: Introduce a test covering legacy byte ops

[Andrew Cooper]

On 31/01/18 11:06, Jan Beulich wrote:
 On 30.01.18 at 16:56,  wrote:
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 
> with one cosmetic remark:
>
>> --- a/tools/tests/x86_emulator/test_x86_emulator.c
>> +++ b/tools/tests/x86_emulator/test_x86_emulator.c
>> @@ -442,6 +442,21 @@ int main(int argc, char **argv)
>>  goto fail;
>>  printf("okay\n");
>>  
>> +printf("%-40s", "Testing xchgl %bl,%ah...");
>> +instr[0] = 0x86; instr[1] = 0xdc;
>> +regs.eflags = 0x200;
> Please can we stop the bad habit of using hex numbers here (and
> in the check below)? We have X86_EFLAGS_IF available after all.

Ok.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen 4.11 Development Update

[Wei Liu]

On Wed, Jan 31, 2018 at 07:57:51AM +0100, Juergen Gross wrote:
> *  Comet: Run PV in PVH container (v2)
>   -  Wei Liu
> 

This is committed some time ago.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [OSSTEST PATCH] sg-report-host-history: Multiply size of reported history by 10

[Ian Jackson]

Right now,
  http://logs.test-lab.xenproject.org/osstest/results/host/laxton1.html
contains ~200 jobs as expected, but that covers only 4 days.  We
obviously would like more like a month.

The effect ought to be some more db work, but not worse concurrency.

CC: Julien Grall 
Signed-off-by: Ian Jackson 
---
 sg-report-host-history | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sg-report-host-history b/sg-report-host-history
index 19a86ab..871ad5f 100755
--- a/sg-report-host-history
+++ b/sg-report-host-history
@@ -28,7 +28,7 @@ use POSIX;
 
 use Osstest::Executive qw(:DEFAULT :colours);
 
-our $limit= 200;
+our $limit= 2000;
 our $flightlimit;
 our $htmlout = ".";
 our @blessings;
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 4/4] x86/emul: Improvements to internal users of decode_register()

[Jan Beulich]

>>> On 30.01.18 at 16:56,  wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -1957,9 +1957,8 @@ const uint8_t cpu_user_regs_gpr_offsets[] = {
>  #endif
>  };
>  
> -void *
> -decode_register(
> -uint8_t modrm_reg, struct cpu_user_regs *regs, int highbyte_regs)
> +static void *decode_gpr_byteop(
> +struct cpu_user_regs *regs, unsigned int modrm_reg, bool legacy_byteop)

Again I'm not really happy about "op" here. Why not follow the
model of my original patch and make this

static void *_decode_gpr(
struct cpu_user_regs *regs, unsigned int modrm_reg, bool legacy)

? With that or a substantially similar adjustment
Reviewed-by: Jan Beulich 

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 2/4] x86/emul: Optimise decode_register() somewhat

[Jan Beulich]

>>> On 30.01.18 at 16:56,  wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -1935,36 +1935,67 @@ load_seg(
>  return rc;
>  }
>  
> +/* Map GPRs by ModRM encoding to their offset within struct cpu_user_regs. */
> +static const uint8_t cpu_user_regs_gpr_offsets[] = {
> +offsetof(struct cpu_user_regs, r(ax)),
> +offsetof(struct cpu_user_regs, r(cx)),
> +offsetof(struct cpu_user_regs, r(dx)),
> +offsetof(struct cpu_user_regs, r(bx)),
> +offsetof(struct cpu_user_regs, r(sp)),
> +offsetof(struct cpu_user_regs, r(bp)),
> +offsetof(struct cpu_user_regs, r(si)),
> +offsetof(struct cpu_user_regs, r(di)),
> +#ifdef __x86_64__
> +offsetof(struct cpu_user_regs, r8),
> +offsetof(struct cpu_user_regs, r9),
> +offsetof(struct cpu_user_regs, r10),
> +offsetof(struct cpu_user_regs, r11),
> +offsetof(struct cpu_user_regs, r12),
> +offsetof(struct cpu_user_regs, r13),
> +offsetof(struct cpu_user_regs, r14),
> +offsetof(struct cpu_user_regs, r15),
> +#endif
> +};
> +
>  void *
>  decode_register(
>  uint8_t modrm_reg, struct cpu_user_regs *regs, int highbyte_regs)
>  {
> -void *p;
> +static const uint8_t byteop_offsets[] = {

byte_reg_offsets[] ?

With that (or a suitable other name not using "op" when registers
are meant)
Reviewed-by: Jan Beulich 

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 1/4] x86/emul: Introduce a test covering legacy byte ops

[Jan Beulich]

>>> On 30.01.18 at 16:56,  wrote:
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 
with one cosmetic remark:

> --- a/tools/tests/x86_emulator/test_x86_emulator.c
> +++ b/tools/tests/x86_emulator/test_x86_emulator.c
> @@ -442,6 +442,21 @@ int main(int argc, char **argv)
>  goto fail;
>  printf("okay\n");
>  
> +printf("%-40s", "Testing xchgl %bl,%ah...");
> +instr[0] = 0x86; instr[1] = 0xdc;
> +regs.eflags = 0x200;

Please can we stop the bad habit of using hex numbers here (and
in the check below)? We have X86_EFLAGS_IF available after all.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 4/5] x86/alternative: Implement NMI/#MC-safe patching

[Jan Beulich]

>>> On 30.01.18 at 20:26,  wrote:
> On 30/01/18 08:39, Jan Beulich wrote:
> On 29.01.18 at 16:38,  wrote:
>>> +/*
>>> + * We are the CPU performing the patching, and might have ended up 
>>> here by
>>> + * hitting a breakpoint.
>>> + *
>>> + * Either way, we need to complete particular patch to make forwards
>>> + * progress.  This logic is safe even if executed recursively in the
>>> + * breakpoint handler; the worst that will happen when normal execution
>>> + * resumes is that we will rewrite the same bytes a second time.
>>> + */
>>> +
>>> +/* First, insert a breakpoint to prevent execution of the patch site. 
>>> */
>>> +i->addr[0] = 0xcc;
>>> +smp_wmb();
>> This is necessary, but not sufficient when replacing more than a
>> single insn: The other CPU may be executing instructions _after_
>> the initial one that is being replaced, and ...
>>
>>> +/* Second, copy the remaining instructions into place. */
>>> +memcpy(i->addr + 1, i->opcode + 1, i->len - 1);
>> ... this may be altering things underneath its feet.
> 
> Hmm.
> 
> It is completely impossible to recover if another CPU hits the middle of
> this memcpy().  It is impossible to synchronise a specific write against
> the remote CPU pipelines.

It is not completely impossible, but the solution would be awkward
to use: If the code doing the patching knew instruction boundaries,
it could put breakpoints onto all of them. Or maybe it isn't all that
bad to use - we have an insn decoder after all.

> The only way to be safe is to guarantee that CPUs can't hit the code to
> begin with.
> 
> On AMD, we can use STGI/CLGI to do this sensibly, and really really
> inhibit all interrupts.

Not really for #MC - clear GIF may also result in shutdown when
one would need delivering.

>  For Intel, we can fix the NMI problem by
> rendezvousing and running the patching loop in NMI context, at which
> point the hardware latch will prevent further NMIs.
> 
> However, there is literally nothing we can do to prevent #MC from
> arriving.  We can stop servicing #MC by disabling CR4.MCE, but then the
> processor will shut down.

Not a good idea indeed.

> We can't put a big barrier at the head of #MC handler which delays
> processing, because we have no way to ensure that processors aren't
> already later in the #MC handler.  Furthermore, attempting to do so
> heightens the risk of hitting a shutdown condition from a second queued #MC.
> 
> 
> The chance of hitting an NMI/#MC collide with patching is already
> minuscule.  Alternatives and livepatching have been used (by XenServer
> alone) in this form for nearly 3 years, across millions of servers,
> without a single report of such a collision.  The chance of an #MC
> collision is far less likely than an NMI collision, and in the best case.
> 
> While we can arrange and test full NMI safety, we cannot test #MC safety
> at all.  Any code to try and implement #MC safety is going to be
> complicated, and make things worse if an #MC does hit.
> 
> Therefore, I agree with the Linux view that trying to do anything for
> #MC safety is going to be worse than doing nothing at all.

I agree. But as said before - the immediate goal ought to be to
make alternatives patching safe, and that doesn't require any
of these considerations.

>>> @@ -153,7 +231,31 @@ void init_or_livepatch add_nops(void *insns, unsigned 
>>> int len)
>>>  void init_or_livepatch noinline
>>>  text_poke(void *addr, const void *opcode, size_t len, bool live)
>>>  {
>>> -memcpy(addr, opcode, len);
>>> +if ( !live || len == 1 )
>>> +{
>>> +/*
>>> + * If we know *addr can't be executed, or we are patching a single
>>> + * byte, it is safe to use a straight memcpy().
>>> + */
>>> +memcpy(addr, opcode, len);
>> Is it really worth special casing this? Whether to actually ack
>> patches 2 and 3 depends on that.
> 
> Yes, and even more so if we are going to use an NMI rendezvous.  We
> definitely don't want to have an NMI rendezvous while applying
> alternatives as part of livepatch preparation.

Well, again - live patching should be the second step here.

>>> +};
>>> +smp_wmb();
>>> +active_text_patching = true;
>>> +smp_wmb();
>>> +text_poke_live(NULL);
>>> +smp_wmb();
>>> +active_text_patching = false;
>> Perhaps better to zap live_poke_info.cpu again here? That could
>> in fact replace the separate active_text_patching flag.
> 
> No - it cant because...
> 
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -119,6 +119,8 @@ boolean_param("ler", opt_ler);
>>>  #define stack_words_per_line 4
>>>  #define ESP_BEFORE_EXCEPTION(regs) ((unsigned long *)regs->rsp)
>>>  
>>> +bool active_text_patching;
>> Why here rather than in alternative.c?
> 
> ... in the !LIVEPATCH case, alternative.c is an .init.o and the build
> fails because of a 

Re: [Xen-devel] [PATCH] xen/cmdline: Fix parse_boolean() for unadorned values

[Jan Beulich]

>>> On 31.01.18 at 11:36,  wrote:
> A command line such as "cpuid=no-ibrsb,no-stibp" tickles a bug in
> parse_boolean() because the separating comma fails the NUL case.
> 
> Instead, check for slen == nlen which accounts for the boundary (if any)
> passed via the 'e' parameter.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH RFC v2 12/12] x86: activate per-vcpu stacks in case of xpti

[Jan Beulich]

>>> On 30.01.18 at 18:33,  wrote:
> On 30/01/18 17:33, Jan Beulich wrote:
> On 22.01.18 at 13:32,  wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -1585,9 +1585,28 @@ static inline bool need_full_gdt(const struct domain 
>>> *d)
>>>  return is_pv_domain(d) && !is_idle_domain(d);
>>>  }
>>>  
>>> +static void copy_user_regs_from_stack(struct vcpu *v)
>>> +{
>>> +struct cpu_user_regs *stack_regs;
>> 
>> const
> 
> Okay.
> 
>> 
>>> +stack_regs = (is_pv_vcpu(v) && v->domain->arch.pv_domain.xpti)
>>> + ? v->arch.pv_vcpu.stack_regs
>>> + : _cpu_info()->guest_cpu_user_regs;
>> 
>> Ugly open coding of what previously was guest_cpu_user_regs().
> 
> I have to make sure to address the per physical cpu stack.

I would have guessed that's the reason, but especially when
uses are inconsistent (see e.g. the two MSR_IA32_SYSENTER_ESP
writes) a brief comment should be attached to clarify why the
other variant is unsuitable in the specific case.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] xen/cmdline: Fix parse_boolean() for unadorned values

[Andrew Cooper]

A command line such as "cpuid=no-ibrsb,no-stibp" tickles a bug in
parse_boolean() because the separating comma fails the NUL case.

Instead, check for slen == nlen which accounts for the boundary (if any)
passed via the 'e' parameter.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 

This wants backporting everywhere the spectre series has gone.
---
 xen/common/kernel.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 19f9bad..5766a0f 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -259,12 +259,16 @@ int parse_boolean(const char *name, const char *s, const 
char *e)
 if ( slen < nlen || strncmp(s, name, nlen) )
 return -1;
 
-switch ( s[nlen] )
-{
-case '\0': return val;
-case '=':  return parse_bool([nlen + 1], e);
-default:   return -1;
-}
+/* Exact, unadorned name?  Result depends on the 'no-' prefix. */
+if ( slen == nlen )
+return val;
+
+/* =$SOMETHING?  Defer to the regular boolean parsing. */
+if ( s[nlen] == '=' )
+return parse_bool([nlen + 1], e);
+
+/* Unrecognised.  Give up. */
+return -1;
 }
 
 unsigned int tainted;
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH RFC v2 11/12] x86: modify interrupt handlers to support stack switching

[Jan Beulich]

>>> On 30.01.18 at 18:19,  wrote:
> On 30/01/18 17:07, Jan Beulich wrote:
> On 22.01.18 at 13:32,  wrote:
>>> --- a/xen/arch/x86/x86_64/asm-offsets.c
>>> +++ b/xen/arch/x86/x86_64/asm-offsets.c
>>> @@ -137,6 +137,10 @@ void __dummy__(void)
>>>  OFFSET(CPUINFO_processor_id, struct cpu_info, processor_id);
>>>  OFFSET(CPUINFO_current_vcpu, struct cpu_info, current_vcpu);
>>>  OFFSET(CPUINFO_cr4, struct cpu_info, cr4);
>>> +OFFSET(CPUINFO_stack_bottom_cpu, struct cpu_info, stack_bottom_cpu);
>>> +OFFSET(CPUINFO_flags, struct cpu_info, flags);
>>> +DEFINE(ASM_ON_VCPUSTACK, ON_VCPUSTACK);
>>> +DEFINE(ASM_VCPUSTACK_ACTIVE, VCPUSTACK_ACTIVE);
>> 
>> Seeing their uses in asm_defns.h it's not really clear to me why
>> you can't use the C constants there, the more that those uses
>> are inside C macros (which perhaps would better be assembler
>> ones). The latter doesn't even appear to be used in assembly
>> code.
> 
> I tried using the C constants but this led to rather nasty include
> dependencies.

Hmm, I can imagine this to be the case, but I'd like to have more
detail for justification. current.h itself doesn't have that many
dependencies, and if half-way reasonable disentangling our
headers may be the better choice.

> ASM_VCPUSTACK_ACTIVE will be used when %cr3 switching is being added.

Please introduce it when needed.

>>> --- a/xen/common/wait.c
>>> +++ b/xen/common/wait.c
>>> @@ -122,10 +122,10 @@ void wake_up_all(struct waitqueue_head *wq)
>>>  
>>>  static void __prepare_to_wait(struct waitqueue_vcpu *wqv)
>>>  {
>>> -struct cpu_info *cpu_info = get_cpu_info();
>>> +struct cpu_user_regs *user_regs = guest_cpu_user_regs();
>>>  struct vcpu *curr = current;
>>>  unsigned long dummy;
>>> -u32 entry_vector = cpu_info->guest_cpu_user_regs.entry_vector;
>>> +u32 entry_vector = user_regs->entry_vector;
>>>  
>>>  ASSERT(wqv->esp == 0);
>>>  
>>> @@ -160,7 +160,7 @@ static void __prepare_to_wait(struct waitqueue_vcpu 
>>> *wqv)
>>>  "pop %%r11; pop %%r10; pop %%r9;  pop %%r8;"
>>>  "pop %%rbp; pop %%rdx; pop %%rbx; pop %%rax"
>>>  : "=" (wqv->esp), "=" (dummy), "=" (dummy)
>>> -: "i" (PAGE_SIZE), "0" (0), "1" (cpu_info), "2" (wqv->stack)
>>> +: "i" (PAGE_SIZE), "0" (0), "1" (user_regs), "2" (wqv->stack)
>>>  : "memory" );
>>>  
>>>  if ( unlikely(wqv->esp == 0) )
>>> @@ -169,7 +169,7 @@ static void __prepare_to_wait(struct waitqueue_vcpu 
>>> *wqv)
>>>  domain_crash_synchronous();
>>>  }
>>>  
>>> -cpu_info->guest_cpu_user_regs.entry_vector = entry_vector;
>>> +user_regs->entry_vector = entry_vector;
>>>  }
>> 
>> I don't see how this change is related to the purpose of this patch,
>> or why the change is needed. All you do is utilize that
>> guest_cpu_user_regs is the first field of struct cpu_info afaics.
> 
> guest_cpu_user_regs() might point to either stack, while get_cpu_info()
> will always reference the Xen stack and never the per-vcpu one.

Then the description should say so for justification.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 4/5] x86/alternative: Implement NMI/#MC-safe patching

[Andrew Cooper]

On 31/01/18 06:07, Juergen Gross wrote:
> On 30/01/18 20:26, Andrew Cooper wrote:
>> However, there is literally nothing we can do to prevent #MC from
>> arriving.  We can stop servicing #MC by disabling CR4.MCE, but then the
>> processor will shut down.
> Hmm, there is a way to avoid #MC on other processors, but this
> requires the really big hammer: stop all other cpus and restart
> them after patching.

I think that firmly goes on the pile of "worse than doing nothing" :)

Also, it doesn't solve the problem of #MC arriving on the current processor.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH RFC v2 07/12] x86: allow per-domain mappings without NX bit or with specific mfn

[Jan Beulich]

>>> On 22.01.18 at 13:32,  wrote:
> For support of per-vcpu stacks we need per-vcpu trampolines. To be
> able to put those into the per-domain mappings the upper levels
> page tables must not have NX set for per-domain mappings.
> 
> In order to be able to reset the NX bit for a per-domain mapping add
> a helper flipflags_perdomain_mapping() for flipping page table flags
> of a specific mapped page.
> 
> To be able to use a page from xen heap for the last per-vcpu stack
> page add a helper to map an arbitrary mfn in the perdomain area.

One further remark on this patch as a whole:
create_perdomain_mapping() allows the L1 tables to be returned,
and I think making this fit your needs (if it doesn't in its current
shape) might be better than introducing new functions which in
the end only want to fiddle with the L1 entries of previously
established mappings. This might also help mapping the pCPU's
GDT into the vCPU's per-domain mappings during context switch,
as suggested elsewhere.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-unstable-coverity test] 118472: all pass - PUSHED

[osstest service owner]

flight 118472 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118472/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  16a31ca735165e63d67e86f60996f2b6a31cc0ee
baseline version:
 xen  4c7e478d597b0346eef3a256cfd6794ac778b608

Last test of basis   118414  2018-01-28 09:18:47 Z3 days
Testing same since   118472  2018-01-31 09:19:44 Z0 days1 attempts


People who touched revisions under test:
  Andre Przywara 
  Andrew Cooper 
  Christian Lindig 
  Daniel De Graaf 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monne 
  Roger Pau Monné 
  Stefano Stabellini 
  Wei Liu 

jobs:
 coverity-amd64   pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   4c7e478d59..16a31ca735  16a31ca735165e63d67e86f60996f2b6a31cc0ee -> 
coverity-tested/smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen 4.11 Development Update

[Jan Beulich]

>>> On 31.01.18 at 07:57,  wrote:
> === x86 === 
> 
> *  Enable Memory Bandwidth Allocation in Xen (v10)
>   -  XEN-48
>   -  Yi Sun

I think this has all gone in, the tools parts a little less than two weeks
ago.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [seabios test] 118462: regressions - FAIL

[osstest service owner]

flight 118462 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118462/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 115539

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 seabios  14d91c353e19b7085fdbb7b2dcc43f3355665670
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z   88 days
Failing since115733  2017-11-10 17:19:59 Z   81 days   98 attempts
Testing same since   118140  2018-01-17 05:09:48 Z   14 days   19 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Marcel Apfelbaum 
  Michael S. Tsirkin 
  Paul Menzel 
  Stefan Berger 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Not pushing.


commit 14d91c353e19b7085fdbb7b2dcc43f3355665670
Author: Marcel Apfelbaum 
Date:   Thu Jan 11 22:15:12 2018 +0200

pci: fix 'io hints' capability for RedHat PCI bridges

Commit ec6cb17f (pci: enable RedHat PCI bridges to reserve additional
 resources on PCI init)
added a new vendor specific PCI capability for RedHat PCI bridges
allowing them to reserve additional buses and/or IO/MEM space.

When adding the IO hints PCI capability to the pcie-root-port
without specifying a value for bus reservation, the subordinate bus
computation is wrong and the guest kernel gets messed up.

Fix it by returning to prev code if the value for bus
reservation is not set.

Removed also a wrong debug print "PCI: invalid QEMU resource reserve
cap offset" which appears if the 'IO hints' capability is not present.

Acked-by: Michael S. Tsirkin 

[Xen-devel] [qemu-mainline test] 118449: tolerable FAIL - PUSHED

[osstest service owner]

flight 118449 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118449/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118411
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118411
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118411
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118411
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118411
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118411
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 qemuu30d9fefe1aca1e92c785214aa9201fd7c2287d56
baseline version:
 qemuue607bbee553cfe73072870cef458cfa4e78133e2

Last test of basis   118411  2018-01-28 07:17:23 Z3 days
Failing since118436  2018-01-29 10:11:34 Z1 days2 attempts
Testing same since   118449  2018-01-30 06:22:08 Z1 days1 attempts


People who touched revisions under test:
  Cédric Le Goater 
  Daniel P. Berrange 
  David Gibson 
  Edgar Kaziakhmedov 
  Eric Blake 
  Gerd Hoffmann 
  Greg Kurz 
  Jason Wang 
  Li Zhijian 
  Mao Zhongyi 
  Mark Cave-Ayland 
  Miika S 
  Peter Maydell 
  Philippe Mathieu-Daudé 
  Prasad J Pandit 
  Suraj 

Re: [Xen-devel] Xen 4.11 Development Update

[Ross Lagerwall]

On 01/31/2018 06:57 AM, Juergen Gross wrote:

This email only tracks big items for xen.git tree. Please reply for items you
would like to see in 4.11 so that people have an idea what is going on and
prioritise accordingly.


snip>

*  Mitigations for SP2/CVE-2017-5715/Branch Target Injection (v7)
   -  Andrew Cooper

*  Vixen: A PV-in-HVM shim (v3)
   -  Anthony Liguori

*  Add dmops to allow use of VGA with restricted QEMU (v3)
   -  Ross Lagerwall


v4 has been sent and committed.

Thanks,
--
Ross Lagerwall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel