[Xen-devel] [xen-unstable bisection] complete test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install

Tree: linux git://xenbits.xen.org/linux-pvops.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:  ad011ad08843f60f9ae17b9ae4aa5907674d72af
  Bug not present: 95596f6ab18feb825006ef8f272041f1d94e6bd1
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/143389/


  commit ad011ad08843f60f9ae17b9ae4aa5907674d72af
  Author: Ian Jackson 
  Date:   Mon Oct 7 17:59:15 2019 +0100
  
  libxl/xl: Overhaul passthrough setting logic
  
  LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
  version of this code) is doing double duty.  We actually need all of
  the following to be specifiable:
* "default": enable PT iff we have devices to
  pass through specified in the initial config file.
* "enabled" (and fail if the platform doesn't support it).
* "disabled" (and reject future PT hotplug).
* "share_pt"/"sync_pt": enable PT and set a specific PT mode.
  
  Defaulting and error checking should be done in libxl.  So, we make
  several changes here.
  
  We introduce "enabled", and rename "unknown" to "default".
  
  We move all of the error checking and defaulting code from xl into
  libxl.  Now, libxl__domain_config_setdefault has all of the necessary
  information to get this right.  So we can do it all there.  Choosing
  the specific mode is arch-specific.
  
  We can also arrange to have only one place each which calculates
  (i) whether passthrough needs to be enabled because pt devices were
  specified (ii) whether pt_share can be used (for each arch).
  
  xl now only has to parse the enum in the same way as it parses all
  other enums.
  
  This change fixes a regression from earlier 4.13-pre: until recent
  changes, passthrough was only enabled by default if passthrough
  devices were specified.  We restore this behaviour.
  
  Signed-off-by: Ian Jackson 
  CC: Stefano Stabellini 
  CC: Julien Grall 
  CC: Volodymyr Babchuk 
  CC: Andrew Cooper 
  CC: Paul Durrant 
  CC: Jan Beulich 
  Release-acked-by: Juergen Gross 
  Acked-by: Anthony PERARD 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-unstable/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install
 --summary-out=tmp/143389.bisection-summary --basis-template=142750 
--blessings=real,real-bisect xen-unstable 
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm debian-hvm-install
Searching for failure / basis pass:
 143288 fail [host=debina0] / 143133 [host=chardonnay0] 143036 [host=pinot1] 
143018 [host=fiano1] 142973 [host=italia1] 142907 [host=baroque0] 142865 
[host=pinot0] 142777 [host=albana0] 142750 [host=rimava1] 142722 
[host=chardonnay1] 142683 [host=debina1] 142642 [host=huxelrebe1] 142598 
[host=chardonnay0] 142563 ok.
Failure / basis pass flights: 143288 / 142563
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.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 b98aebd298246df37b472c52a2ee1023256d02e3 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
933ebad2470a169504799a1d95b8e410bd9847ef 
df663157c638d9778fa3ada9859f968fb240
Basis pass 42327896f194f256e5a361e0069985bc8d209b42 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
933ebad2470a169504799a1d95b8e410bd9847ef 
4ca8eab5ce1893b3048b06921f12157d33ab60f7
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#42327896f194f256e5a361e0069985bc8d209b42-b98aebd298246df37b472c52a2ee1023256d02e3
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798
 git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e41\
 0bd9847ef-933ebad2470a169504799a1d95b8e410bd9847ef 
git://

Re: [Xen-devel] [PATCH v2] x86/passthrough: fix migration of MSI when using posted interrupts

[Roger Pau Monné]

On Tue, Oct 29, 2019 at 05:20:18PM -0700, Joe Jin wrote:
> Hi Roger & Jan,
> 
> I got my test env back, and back the patch to stable-4.12, run same
> test, I still seen original issue, guest kernel printed error:
> 
>  kernel:do_IRQ: 20.114 No irq handler for vector (irq -1)
> 
> After that, pass through infiniband VF stopped to work.

Thanks for the testing, TBH I'm not sure what's wrong here, since I
intended my proposed patch to be functionally equivalent to your first
proposed fix.

> My patch as below, please check:

The patch LGTM.

Can you try to add the following debug patch on top of the existing
one and report the output that you get on the Xen console?

---8<---
diff --git a/xen/drivers/passthrough/vtd/intremap.c 
b/xen/drivers/passthrough/vtd/intremap.c
index 07c1c1627a..91a1dde131 100644
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -977,7 +977,13 @@ int pi_update_irte(const struct pi_desc *pi_desc, const 
struct pirq *pirq,
 
 rc = msi_msg_write_remap_rte(msi_desc, &msi_desc->msg);
 if ( !rc && prev )
+{
+ printk("sync PIRR on vcpu#%u\n", prev->vcpu_id);
  vlapic_sync_pir_to_irr(prev);
+}
+else
+ printk("not syncing PIRR rc: %d vcpu#%u\n",
+rc, prev ? prev->vcpu_id : -1);
 
 return rc;
 }

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

Re: [Xen-devel] [PATCH v3 2/7] xen/nospec: Use always_inline to fix code gen for evaluate_nospec

[Jan Beulich]

On 29.10.2019 17:53, Andrew Cooper wrote:
> On 25/10/2019 13:03, Jan Beulich wrote:
>> On 23.10.2019 15:58, Andrew Cooper wrote:
>>> evaluate_nospec() is incredibly fragile, and this is one giant bodge.
>>>
>>> To correctly protect jumps, the generated code needs to be of the form:
>>>
>>> cmp/test 
>>> jcc 1f
>>> lfence
>>> ...
>>>  1: lfence
>>> ...
>>>
>>> Critically, the lfence must be at the head of both basic blocks, later in 
>>> the
>>> instruction stream than the conditional jump in need of protection.
>>>
>>> When a static inline is involved, the optimiser decides to be clever and
>>> rearranges the code as:
>>>
>>>  pred:
>>> lfence
>>> 
>>> ret
>>>
>>> call pred
>>> cmp $0, %eax
>>> jcc 1f
>>> ...
>>>  1: ...
>>>
>>> which breaks the speculative safety.
>> Aiui "pred" is a non-inlined static inline here. There's no "optimiser 
>> decides
>> to be clever" in this case imo - it all is a result of not inlining, when the
>> construct in evaluate_nospec() is specifically assuming this wouldn't happen.
>> Therefore I continue to think that the description is misleading.
>>
>>> Any use of evaluate_nospec() needs all static inline predicates which use it
>>> to be declared always_inline to prevent the optimiser having the flexibility
>>> to generate unsafe code.
>> I agree with this part.
> 
> How about:
> 
> When the compiler chooses to out-of-line the condition calculation (e.g. by
> not inlining a predicate), the code layout can end up as:
>    
>  pred:
>     lfence
>     
>     ret
>    
>     call pred
>     cmp $0, %eax
>     jcc 1f
>     ...
>  1: ...
>    
> which breaks the speculative safety, as the lfences are earlier in the
> instruction stream than the jump in need of protection.
> 
> ?

Sounds good, thanks. With this
Acked-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 v3 5/7] x86/livepatch: Fail the build if duplicate symbols exist

[Jan Beulich]

On 29.10.2019 18:06, Andrew Cooper wrote:
> On 24/10/2019 13:03, Jan Beulich wrote:
>> On 23.10.2019 15:58, Andrew Cooper wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -361,9 +361,23 @@ config FAST_SYMBOL_LOOKUP
>>>  
>>>   If unsure, say Y.
>>>  
>>> +config ENFORCE_UNIQUE_SYMBOLS
>>> +   bool "Enforce unique symbols" if LIVEPATCH
>>> +   default y if LIVEPATCH
>> Instead of two identical "if", why not "depends on LIVEPATCH"?
>>
>>> +   ---help---
>>> + Multiple symbols with the same name aren't generally a problem
>>> + unless Live patching is to be used.
>>> +
>>> + Livepatch loading involves resolving relocations against symbol
>>> + names, and attempting to a duplicate symbol in a livepatch will
>>> + result in incorrect livepatch application.
>>> +
>>> + This option should be used to ensure that a build of Xen can have a
>>> + livepatch build and apply correctly.
>>> +
>>>  config SUPPRESS_DUPLICATE_SYMBOL_WARNINGS
>>> -   bool "Suppress duplicate symbol warnings" if !LIVEPATCH
>>> -   default y if !LIVEPATCH
>>> +   bool "Suppress duplicate symbol warnings" if !ENFORCE_UNIQUE_SYMBOLS
>>> +   default y if !ENFORCE_UNIQUE_SYMBOLS
>> Similarly here then. With this changed, or with a proper reason
>> supplied
>> Reviewed-by: Jan Beulich 
> 
> That's a question for the author of c/s 064a2652233 to answer...  I'm
> merely following the prevailing style.

"Prevailing style" seems a little bold considering that according to
my grep-ing there's exactly on other such instance (VGA). I.e. you'd
grow the "badness" by 50% when you could equally well shrink it by
this same percentage.

Jan

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

Re: [Xen-devel] [xen-4.12-testing test] 143302: regressions - FAIL

[Jan Beulich]

On 29.10.2019 23:52, osstest service owner wrote:
> flight 143302 xen-4.12-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/143302/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 
> 143190
>  test-amd64-amd64-livepatch7 xen-boot fail REGR. vs. 
> 143190
>  test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 
> fail REGR. vs. 143190
>  test-amd64-i386-xl-raw  19 guest-start/debian.repeat fail REGR. vs. 
> 143190

Looking at this one I see

2019-10-29 19:40:59 Z executing ssh ... root@172.16.144.29 mkdir -p 
/var/lib/xen/images/debian
mount /dev/mapper/chardonnay1--vg-debian.stretch.guest.osstest--disk 
/var/lib/xen/images/debian;
 
mount: /dev/mapper/chardonnay1--vg-debian.stretch.guest.osstest--disk is 
already mounted or /var/lib/xen/images/debian busy
   /dev/mapper/chardonnay1--vg-debian.stretch.guest.osstest--disk is 
already mounted on /var/lib/xen/images/debian
2019-10-29 19:41:00 Z command nonzero waitstatus 8192: timeout 60 ssh -o 
StrictHostKeyChecking=no -o BatchMode=yes -o ConnectTimeout=100 -o 
ServerAliveInterval=100 -o PasswordAuthentication=no -o 
ChallengeResponseAuthentication=no -o 
UserKnownHostsFile=tmp/t.known_hosts_143302.test-amd64-i386-xl-raw 
root@172.16.144.29 mkdir -p /var/lib/xen/images/debian
mount /dev/mapper/chardonnay1--vg-debian.stretch.guest.osstest--disk 
/var/lib/xen/images/debian;
 
status 8192 at Osstest/TestSupport.pm line 550.

It shouldn't be timeout, so I assume it's the mount that fails.
Some new glitch in osstest (seen also on the most recent 4.11
flight)? Or am I misreading the above? In any event I can't spot
a similar mkdir invocation in a random other test's
guest-start/debian.repeat step.

What I find further puzzling (albeit not necessarily related to the
test failure, at least the serial logs don't immediately suggest so
except for the guest no longer being there when the debug keys get
processed, but this may well have been a guest of a previous test
step) are instances of

(XEN) d25 L1TF-vulnerable L1e 8002 - Shadowing

both here and again in the corresponding 4.11 branch flight. I also
don't think it's pure coincidence that it's d1, d2, and d25 in both
cases. Yet this occurring pretty soon after the guest starts, I'd
find it more likely if all guest boot instances showed it. In any
event I'd like to ask if anyone (Jürgen in particular) has an idea
what bogus operation 32-bit Linux may be doing here. Is there
possibly still some 2-part PTE update left, where the low half gets
cleared off of a previously fine entry?

Jan

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

Re: [Xen-devel] [PATCH v3 00/20] hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge

[Philippe Mathieu-Daudé]

Hi Aleksandar,

On 10/27/19 8:44 AM, Aleksandar Markovic wrote:
On Saturday, October 26, 2019, Philippe Mathieu-Daudé > wrote:


Changes since v2 [0]:
- Use a #define
- Reword one description
- Added review tags (thanks all for reviewing!)

Changes since v1 [1]:
- Removed patch reintroducing DO_UPCAST() use (thuth)
- Took various patches out to reduce series (thuth)
- Added review tags (thanks all for reviewing!)

$ git backport-diff -u pc_split_i440fx_piix-v2
Key:
[] : patches are identical
[] : number of functional differences between
upstream/downstream patch
[down] : patch is downstream-only
The flags [FC] indicate (F)unctional and (C)ontextual differences,
respectively

001/20:[] [--] 'MAINTAINERS: Keep PIIX4 South Bridge separate
from PC Chipsets'
002/20:[0004] [FC] 'piix4: Add the Reset Control Register'
003/20:[0002] [FC] 'piix4: Add an i8259 Interrupt Controller as
specified in datasheet'
004/20:[] [--] 'Revert "irq: introduce qemu_irq_proxy()"'
005/20:[] [--] 'piix4: Rename PIIX4 object to piix4-isa'
006/20:[] [--] 'piix4: Add an i8257 DMA Controller as specified
in datasheet'
007/20:[] [-C] 'piix4: Add an i8254 PIT Controller as specified
in datasheet'
008/20:[0004] [FC] 'piix4: Add a MC146818 RTC Controller as
specified in datasheet'
009/20:[] [--] 'hw/mips/mips_malta: Create IDE hard drive array
dynamically'
010/20:[] [--] 'hw/mips/mips_malta: Extract the PIIX4 creation
code as piix4_create()'
011/20:[] [-C] 'hw/isa/piix4: Move piix4_create() to hw/isa/piix4.c'
012/20:[] [--] 'hw/i386: Remove obsolete
LoadStateHandler::load_state_old handlers'
013/20:[] [--] 'hw/pci-host/piix: Extract piix3_create()'
014/20:[0002] [FC] 'hw/pci-host/piix: Move RCR_IOPORT register
definition'
015/20:[] [--] 'hw/pci-host/piix: Define and use the PIIX IRQ
Route Control Registers'
016/20:[] [-C] 'hw/pci-host/piix: Move i440FX declarations to
hw/pci-host/i440fx.h'
017/20:[] [--] 'hw/pci-host/piix: Fix code style issues'
018/20:[] [--] 'hw/pci-host/piix: Extract PIIX3 functions to
hw/isa/piix3.c'
019/20:[] [--] 'hw/pci-host: Rename incorrectly named 'piix' as
'i440fx''
020/20:[0004] [FC] 'hw/pci-host/i440fx: Remove the last PIIX3 traces'

Previous cover:

This series is a rework of "piix4: cleanup and improvements" [2]
from Hervé, and my "remove i386/pc dependency: PIIX cleanup" [3].

Still trying to remove the strong X86/PC dependency 2 years later,
one step at a time.
Here we split the PIIX3 southbridge from i440FX northbridge.
The i440FX northbridge is only used by the PC machine, while the
PIIX southbridge is also used by the Malta MIPS machine.

This is also a step forward using KConfig with the Malta board.
Without this split, it was impossible to compile the Malta without
pulling various X86 pieces of code.

The overall design cleanup is not yet perfect, but enough to post
as a series.

Now that the PIIX3 code is extracted, the code duplication with the
PIIX4 chipset is obvious. Not worth improving for now because it
isn't broken.

Based-on: <1572097538-18898-1-git-send-email-pbonz...@redhat.com
>
to include:
mc146818rtc: Allow call object_initialize(MC146818_RTC) instead of
rtc_init()
https://mid.mail-archive.com/20191018133547.10936-1-philmd@redhat.com 


Since Aleksandar offered me to send the pull request [4] I plan to do
it once Paolo's pull [5] is merged.


Philippe,

I attempted the other day the integration of v2 of this series into MIPS 
pull request, but couldn't do it - since another series of yours was 
already merged, acting on the same code, making rebasing difficult. Now 
this, v3, series can't be applied since certain patches in some, on 
surface, unrelated series aren't megred, and v3 assumes they are merged.


If you send a series, it should preferably be based on the latest 
(current) code base, not on some imagined future state.


I used the 'based-on' tag to refer other series, and patchew succeeded
at applying this series on top of it and build/test it.

Based-on: <1572097538-18898-1-git-send-email-pbonz...@redhat.com

Why did you create this such mess with interdependencies of your own 
multiple series, and just right before softfreeze? :( You should have 
distributed submitting those series over longer time interval, and 
absolutely avoid, if possible, this hectic around-softfreeze period. You 
did the opposite: waited for softfreeze to become close, and sent 
several interdependant series in matter of days - creating stress 
without any real technical reason.


This series to

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  f51d4a19427674491eaecef85c551613450188c5
baseline version:
 xen  df663157c638d9778fa3ada9859f968fb240

Last test of basis   143223  2019-10-27 09:19:11 Z3 days
Testing same since   143396  2019-10-30 09:19:37 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  George Dunlap 
  Ian Jackson 
  Julien Grall 
  Oleksandr Andrushchenko 
  Petre Pircalabu 
  Stewart Hildebrand 
  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
   df6631..f51d4a1942  f51d4a19427674491eaecef85c551613450188c5 -> 
coverity-tested/smoke

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

[Xen-devel] [PATCH v3] x86: clear RDRAND CPUID bit on AMD family 15h/16h

[Jan Beulich]

Inspired by Linux commit c49a0a80137c7ca7d6ced4c812c9e07a949f6f24:

There have been reports of RDRAND issues after resuming from suspend on
some AMD family 15h and family 16h systems. This issue stems from a BIOS
not performing the proper steps during resume to ensure RDRAND continues
to function properly.

Update the CPU initialization to clear the RDRAND CPUID bit for any family
15h and 16h processor that supports RDRAND. If it is known that the family
15h or family 16h system does not have an RDRAND resume issue or that the
system will not be placed in suspend, the "cpuid=rdrand" kernel parameter
can be used to stop the clearing of the RDRAND CPUID bit.

Note, that clearing the RDRAND CPUID bit does not prevent a processor
that normally supports the RDRAND instruction from executing it. So any
code that determined the support based on family and model won't #UD.

Warn if no explicit choice was given on affected hardware.

If force-enabled, check RDRAND still functions after S3 resume (the retry
limit chosen is entirely arbitrary).

Signed-off-by: Jan Beulich 
---
Still slightly RFC, and still in particular because of the change to
parse_xen_cpuid(): Alternative approach suggestions are welcome.
---
v3: Add call to warning_add(). If force-enabled, check RDRAND still
functioning after S3 resume.
v2: Re-base.

--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -488,6 +488,10 @@ The Speculation Control hardware feature
 be ignored, e.g. `no-ibrsb`, at which point Xen won't use them itself, and
 won't offer them to guests.
 
+`rdrand` can be used to override the default disabling of the feature on 
certain
+AMD systems.  Its negative form can of course also be used to suppress use and
+exposure of the feature.
+
 ### cpuid_mask_cpu
 > `= fam_0f_rev_[cdefg] | fam_10_rev_[bc] | fam_11_rev_b`
 
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -3,6 +3,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -648,6 +649,25 @@ static void init_amd(struct cpuinfo_x86
if (acpi_smi_cmd && (acpi_enable_value | acpi_disable_value))
amd_acpi_c1e_quirk = true;
break;
+
+   case 0x15: case 0x16:
+   /*
+* There are too many Fam15/Fam16 systems where upon resume
+* from S3 firmware fails to re-setup properly functioning
+* RDRAND.  Clear the feature unless force-enabled on the
+* command line.
+*/
+   if (c == &boot_cpu_data &&
+   cpu_has(c, X86_FEATURE_RDRAND) &&
+   !is_forced_cpu_cap(X86_FEATURE_RDRAND)) {
+   static const char __initconst text[] =
+   "RDRAND may cease to work on this hardware upon 
resume from S3.\n"
+   "Please choose an explicit cpuid={no-}rdrand 
setting.\n";
+
+   setup_clear_cpu_cap(X86_FEATURE_RDRAND);
+   warning_add(text);
+   }
+   break;
}
 
display_cacheinfo(c);
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -97,6 +97,11 @@ void __init setup_force_cpu_cap(unsigned
__set_bit(cap, boot_cpu_data.x86_capability);
 }
 
+bool is_forced_cpu_cap(unsigned int cap)
+{
+   return test_bit(cap, forced_caps);
+}
+
 static void default_init(struct cpuinfo_x86 * c)
 {
/* Not much we can do here... */
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 const uint32_t known_features[] = INIT_KNOWN_FEATURES;
@@ -67,6 +68,9 @@ static int __init parse_xen_cpuid(const
 {
 if ( !val )
 setup_clear_cpu_cap(mid->bit);
+else if ( mid->bit == X86_FEATURE_RDRAND &&
+  (cpuid_ecx(1) & cpufeat_mask(X86_FEATURE_RDRAND)) )
+setup_force_cpu_cap(X86_FEATURE_RDRAND);
 mid = NULL;
 }
 
@@ -464,6 +468,19 @@ bool recheck_cpu_features(unsigned int c
 okay = false;
 }
 
+/*
+ * If RDRAND was force-enabled, make an attempt to check that it
+ * actually still works.
+ */
+if ( is_forced_cpu_cap(X86_FEATURE_RDRAND) )
+{
+for ( i = 0; !arch_get_random() && i < 5; ++i )
+cpu_relax();
+if ( i >= 5 )
+printk(XENLOG_WARNING "CPU%u: RDRAND appears to not work 
anymore\n",
+   cpu);
+}
+
 return okay;
 }
 
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -166,6 +166,7 @@ extern const struct x86_cpu_id *x86_matc
 extern void identify_cpu(struct cpuinfo_x86 *);
 extern void setup_clear_cpu_cap(unsigned int);
 extern void setup_force_cpu_cap(unsigned int);
+extern bool is_forced_cpu_cap(unsigned int

Re: [Xen-devel] [PATCH v3 5/7] x86/livepatch: Fail the build if duplicate symbols exist

[Andrew Cooper]

On 30/10/2019 08:41, Jan Beulich wrote:
> On 29.10.2019 18:06, Andrew Cooper wrote:
>> On 24/10/2019 13:03, Jan Beulich wrote:
>>> On 23.10.2019 15:58, Andrew Cooper wrote:
 --- a/xen/common/Kconfig
 +++ b/xen/common/Kconfig
 @@ -361,9 +361,23 @@ config FAST_SYMBOL_LOOKUP
  
  If unsure, say Y.
  
 +config ENFORCE_UNIQUE_SYMBOLS
 +  bool "Enforce unique symbols" if LIVEPATCH
 +  default y if LIVEPATCH
>>> Instead of two identical "if", why not "depends on LIVEPATCH"?
>>>
 +  ---help---
 +Multiple symbols with the same name aren't generally a problem
 +unless Live patching is to be used.
 +
 +Livepatch loading involves resolving relocations against symbol
 +names, and attempting to a duplicate symbol in a livepatch will
 +result in incorrect livepatch application.
 +
 +This option should be used to ensure that a build of Xen can have a
 +livepatch build and apply correctly.
 +
  config SUPPRESS_DUPLICATE_SYMBOL_WARNINGS
 -  bool "Suppress duplicate symbol warnings" if !LIVEPATCH
 -  default y if !LIVEPATCH
 +  bool "Suppress duplicate symbol warnings" if !ENFORCE_UNIQUE_SYMBOLS
 +  default y if !ENFORCE_UNIQUE_SYMBOLS
>>> Similarly here then. With this changed, or with a proper reason
>>> supplied
>>> Reviewed-by: Jan Beulich 
>> That's a question for the author of c/s 064a2652233 to answer...  I'm
>> merely following the prevailing style.
> "Prevailing style" seems a little bold considering that according to
> my grep-ing there's exactly on other such instance (VGA). I.e. you'd
> grow the "badness" by 50% when you could equally well shrink it by
> this same percentage.

Allow me to be less subtle.

*You* are the author of the code, in this form.

As a consequence, I expect there is a deliberate reason.

And seeing as I've had to reverse engineer the reason myself, it looks
to be related to the fact that other options in the build select these,
so they need not to be dependent on livepatching in the first place.

~Andrew

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

[Xen-devel] [PATCH 0/2] x86: Protected Processor Inventory Number (PPIN) support

[Jan Beulich]

1: include the PPIN in MCE records when available
2: explicitly disallow guest access to PPIN

I will also see to get around to post the Linux side consumer
patch of the interface addition in patch 1.

Jan

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

[Xen-devel] [PATCH 2/2] x86: explicitly disallow guest access to PPIN

[Jan Beulich]

To fulfill the "protected" in its name, don't let the real hardware
values "shine through". Report a control register value expressing this.

Signed-off-by: Jan Beulich 
---
TBD: Do we want to permit Dom0 access?

--- a/xen/arch/x86/msr.c
+++ b/xen/arch/x86/msr.c
@@ -135,6 +135,8 @@ int guest_rdmsr(struct vcpu *v, uint32_t
 case MSR_TSX_FORCE_ABORT:
 case MSR_AMD64_LWP_CFG:
 case MSR_AMD64_LWP_CBADDR:
+case MSR_PPIN:
+case MSR_AMD_PPIN:
 /* Not offered to guests. */
 goto gp_fault;
 
@@ -237,6 +239,18 @@ int guest_rdmsr(struct vcpu *v, uint32_t
ARRAY_SIZE(msrs->dr_mask))];
 break;
 
+case MSR_PPIN_CTL:
+if ( d->arch.cpuid->x86_vendor != X86_VENDOR_INTEL )
+goto gp_fault;
+*val = PPIN_LOCKOUT;
+break;
+
+case MSR_AMD_PPIN_CTL:
+if ( !cp->extd.amd_ppin )
+goto gp_fault;
+*val = PPIN_LOCKOUT;
+break;
+
 /*
  * TODO: Implement when we have better topology representation.
 case MSR_INTEL_CORE_THREAD_COUNT:
@@ -273,10 +287,14 @@ int guest_wrmsr(struct vcpu *v, uint32_t
 case MSR_INTEL_CORE_THREAD_COUNT:
 case MSR_INTEL_PLATFORM_INFO:
 case MSR_ARCH_CAPABILITIES:
+case MSR_PPIN:
+case MSR_AMD_PPIN:
 /* Read-only */
 case MSR_TSX_FORCE_ABORT:
 case MSR_AMD64_LWP_CFG:
 case MSR_AMD64_LWP_CBADDR:
+case MSR_PPIN_CTL:
+case MSR_AMD_PPIN_CTL:
 /* Not offered to guests. */
 goto gp_fault;
 


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

Re: [Xen-devel] [XEN PATCH for-4.13 v2 1/4] tools/libxl: gentypes.py: Prefer init_val to init_fn

[Anthony PERARD]

On Tue, Oct 29, 2019 at 03:54:33PM +, Ian Jackson wrote:
> When both are provided, init_val is likely to be more direct.
> 
> No functional change with existing types: C output is identical.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Anthony PERARD 

-- 
Anthony PERARD

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

[Xen-devel] [PATCH 1/2] x86: include the PPIN in MCE records when available

[Jan Beulich]

Quoting the respective Linux commit:

Intel Xeons from Ivy Bridge onwards support a processor identification
number set in the factory. To the user this is a handy unique number to
identify a particular CPU. Intel can decode this to the fab/production
run to track errors. On systems that have it, include it in the machine
check record. I'm told that this would be helpful for users that run
large data centers with multi-socket servers to keep track of which CPUs
are seeing errors.

Newer AMD CPUs support this too, at different MSR numbers.

Take the opportunity and hide __MC_NMSRS from the public interface going
forward.

[Linux commit 3f5a7896a5096fd50030a04d4c3f28a7441e30a5]
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -35,6 +35,7 @@ bool __read_mostly mce_broadcast;
 bool is_mc_panic;
 DEFINE_PER_CPU_READ_MOSTLY(unsigned int, nr_mce_banks);
 unsigned int __read_mostly firstbank;
+unsigned int __read_mostly ppin_msr;
 uint8_t __read_mostly cmci_apic_vector;
 
 DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, poll_bankmask);
@@ -999,10 +1000,17 @@ static void do_mc_get_cpu_info(void *v)
 /*
  * This part needs to run on the CPU itself.
  */
-xcp->mc_nmsrvals = __MC_NMSRS;
+xcp->mc_nmsrvals = 1;
 xcp->mc_msrvalues[0].reg = MSR_IA32_MCG_CAP;
 rdmsrl(MSR_IA32_MCG_CAP, xcp->mc_msrvalues[0].value);
 
+if ( ppin_msr && xcp->mc_nmsrvals < ARRAY_SIZE(xcp->mc_msrvalues) )
+{
+xcp->mc_msrvalues[xcp->mc_nmsrvals].reg = ppin_msr;
+rdmsrl(ppin_msr, xcp->mc_msrvalues[xcp->mc_nmsrvals].value);
+++xcp->mc_nmsrvals;
+}
+
 if ( c->cpuid_level >= 1 )
 {
 cpuid(1, &junk, &ebx, &junk, &junk);
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -49,6 +49,7 @@ enum mcheck_type intel_mcheck_init(struc
 void amd_nonfatal_mcheck_init(struct cpuinfo_x86 *c);
 
 extern unsigned int firstbank;
+extern unsigned int ppin_msr;
 
 struct mcinfo_extended *intel_get_extended_msrs(
 struct mcinfo_global *mig, struct mc_info *mi);
--- a/xen/arch/x86/cpu/mcheck/mce_amd.c
+++ b/xen/arch/x86/cpu/mcheck/mce_amd.c
@@ -315,6 +315,26 @@ amd_mcheck_init(struct cpuinfo_x86 *ci)
 if ( quirkflag == MCEQUIRK_F10_GART )
 mcequirk_amd_apply(quirkflag);
 
+if ( cpu_has(ci, X86_FEATURE_AMD_PPIN) &&
+ (ci == &boot_cpu_data || ppin_msr) )
+{
+uint64_t val;
+
+rdmsrl(MSR_AMD_PPIN_CTL, val);
+
+/* If PPIN is disabled, but not locked, try to enable. */
+if ( !(val & (PPIN_ENABLE | PPIN_LOCKOUT)) )
+{
+wrmsr_safe(MSR_PPIN_CTL, val | PPIN_ENABLE);
+rdmsrl(MSR_AMD_PPIN_CTL, val);
+}
+
+if ( (val & (PPIN_ENABLE | PPIN_LOCKOUT)) != PPIN_ENABLE )
+ppin_msr = 0;
+else if ( ci == &boot_cpu_data )
+ppin_msr = MSR_AMD_PPIN;
+}
+
 x86_mce_callback_register(amd_f10_handler);
 mce_recoverable_register(mc_amd_recoverable_scan);
 mce_register_addrcheck(mc_amd_addrcheck);
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -853,6 +853,43 @@ static void intel_init_mce(void)
 mce_uhandler_num = ARRAY_SIZE(intel_mce_uhandlers);
 }
 
+static void intel_init_ppin(const struct cpuinfo_x86 *c)
+{
+/*
+ * Even if testing the presence of the MSR would be enough, we don't
+ * want to risk the situation where other models reuse this MSR for
+ * other purposes.
+ */
+switch ( c->x86_model )
+{
+uint64_t val;
+
+case 0x3e: /* IvyBridge X */
+case 0x3f: /* Haswell X */
+case 0x4f: /* Broadwell X */
+case 0x55: /* Skylake X */
+case 0x56: /* Broadwell Xeon D */
+case 0x57: /* Knights Landing */
+case 0x85: /* Knights Mill */
+
+if ( (c != &boot_cpu_data && !ppin_msr) ||
+ rdmsr_safe(MSR_PPIN_CTL, val) )
+return;
+
+/* If PPIN is disabled, but not locked, try to enable. */
+if ( !(val & (PPIN_ENABLE | PPIN_LOCKOUT)) )
+{
+wrmsr_safe(MSR_PPIN_CTL, val | PPIN_ENABLE);
+rdmsr_safe(MSR_PPIN_CTL, val);
+}
+
+if ( (val & (PPIN_ENABLE | PPIN_LOCKOUT)) != PPIN_ENABLE )
+ppin_msr = 0;
+else if ( c == &boot_cpu_data )
+ppin_msr = MSR_PPIN;
+}
+}
+
 static void cpu_mcabank_free(unsigned int cpu)
 {
 struct mca_banks *cmci = per_cpu(no_cmci_banks, cpu);
@@ -941,6 +978,8 @@ enum mcheck_type intel_mcheck_init(struc
 
 intel_init_thermal(c);
 
+intel_init_ppin(c);
+
 return mcheck_intel;
 }
 
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -45,6 +45,13 @@
 #define MSR_PRED_CMD   0x0049
 #define PRED_CMD_IBPB  (_AC(1, ULL) << 0)
 
+/* Intel Protected Processor Inventory Number */
+#define MSR_PPIN_CTL   0x004e
+#define MSR_PPIN  

Re: [Xen-devel] [XEN PATCH for-4.13 v2 2/4] libxl: gentypes.py: Break out field_pass in ..._copy_deprecated

[Anthony PERARD]

On Tue, Oct 29, 2019 at 03:54:34PM +, Ian Jackson wrote:
> We are going to want this in a moment.
> 
> No functional change with existing types: C output is identical.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Anthony PERARD 

-- 
Anthony PERARD

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

[Xen-devel] [linux-4.19 test] 143326: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-intel 12 guest-start/redhat.repeat fail REGR. 
vs. 142932
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 142932
 test-amd64-amd64-xl-qcow2   19 guest-start/debian.repeat fail REGR. vs. 142932
 test-amd64-i386-xl-raw  19 guest-start/debian.repeat fail REGR. vs. 142932
 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 142932

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 142932
 test-armhf-armhf-xl-vhd  15 guest-start/debian.repeatfail  like 142932
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-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-arm64-arm64-libvirt-xsm 13 migrate-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-libvirt-xsm 14 saverestore-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-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 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-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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-xl-qemuu-win7-amd64 17 guest-stop fail 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-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail 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-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail 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-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail 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-amd64-xl-qemut-win10-i386 10 windows-installfail n

Re: [Xen-devel] [XEN PATCH for-4.13 v2 3/4] libxl: gentypes.py: Break out libxl_C_type_do_init

[Anthony PERARD]

On Tue, Oct 29, 2019 at 03:54:35PM +, Ian Jackson wrote:
> This is going to be the common way to initialise things.
> _libxl_C_type_init remains the thing for generating the body of the
> init function, and for some special cases.
> 
> No functional change with existing types: C output is identical.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Anthony PERARD 

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v3 5/7] x86/livepatch: Fail the build if duplicate symbols exist

[Jan Beulich]

On 30.10.2019 11:37, Andrew Cooper wrote:
> On 30/10/2019 08:41, Jan Beulich wrote:
>> On 29.10.2019 18:06, Andrew Cooper wrote:
>>> On 24/10/2019 13:03, Jan Beulich wrote:
 On 23.10.2019 15:58, Andrew Cooper wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -361,9 +361,23 @@ config FAST_SYMBOL_LOOKUP
>  
> If unsure, say Y.
>  
> +config ENFORCE_UNIQUE_SYMBOLS
> + bool "Enforce unique symbols" if LIVEPATCH
> + default y if LIVEPATCH
 Instead of two identical "if", why not "depends on LIVEPATCH"?

> + ---help---
> +   Multiple symbols with the same name aren't generally a problem
> +   unless Live patching is to be used.
> +
> +   Livepatch loading involves resolving relocations against symbol
> +   names, and attempting to a duplicate symbol in a livepatch will
> +   result in incorrect livepatch application.
> +
> +   This option should be used to ensure that a build of Xen can have a
> +   livepatch build and apply correctly.
> +
>  config SUPPRESS_DUPLICATE_SYMBOL_WARNINGS
> - bool "Suppress duplicate symbol warnings" if !LIVEPATCH
> - default y if !LIVEPATCH
> + bool "Suppress duplicate symbol warnings" if !ENFORCE_UNIQUE_SYMBOLS
> + default y if !ENFORCE_UNIQUE_SYMBOLS
 Similarly here then. With this changed, or with a proper reason
 supplied
 Reviewed-by: Jan Beulich 
>>> That's a question for the author of c/s 064a2652233 to answer...  I'm
>>> merely following the prevailing style.
>> "Prevailing style" seems a little bold considering that according to
>> my grep-ing there's exactly on other such instance (VGA). I.e. you'd
>> grow the "badness" by 50% when you could equally well shrink it by
>> this same percentage.
> 
> Allow me to be less subtle.
> 
> *You* are the author of the code, in this form.

I'm sorry for not recalling.

> As a consequence, I expect there is a deliberate reason.
> 
> And seeing as I've had to reverse engineer the reason myself, it looks
> to be related to the fact that other options in the build select these,
> so they need not to be dependent on livepatching in the first place.

It wasn't without reason that I did say "or with a proper reason
supplied" - the select in xen/Kconfig.debug is a proper reason for
SUPPRESS_DUPLICATE_SYMBOL_WARNINGS staying as it is, indeed. But
it's then still not a reason for ENFORCE_UNIQUE_SYMBOLS to be
this same way, as there's no similar select for it anywhere.

Jan

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

Re: [Xen-devel] [XEN PATCH for-4.13 v2 4/4] libxl: gentypes: initialise array elements in json

[Anthony PERARD]

On Tue, Oct 29, 2019 at 03:54:36PM +, Ian Jackson wrote:
> diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
> index 124285cd66..c74445f16e 100644
> --- a/tools/libxl/gentypes.py
> +++ b/tools/libxl/gentypes.py
> @@ -461,6 +461,10 @@ def libxl_C_type_parse_json(ty, w, v, indent = "", 
> parent = None, discrimina
>  s += "goto out;\n"
>  s += "}\n"
>  s += "for (i=0; (t=libxl__json_array_get(x,i)); i++) {\n"
> +s += libxl_C_type_do_init(ty.elem_type,
> +lambda(by): ("&" if by == idl.PASS_BY_REFERENCE else "")+

The syntax for using `lambda' is without "()" for the list of parameters.
python3 complains about it.

With that fix:
Acked-by: Anthony PERARD 

> +("%s[i]" % v),
> +  need_zero=False, indent=indent+"")
>  s += libxl_C_type_parse_json(ty.elem_type, "t", v+"[i]",
>   indent + "", parent)
>  s += "}\n"

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH 2/2] x86: explicitly disallow guest access to PPIN

[Andrew Cooper]

On 30/10/2019 10:39, Jan Beulich wrote:
> To fulfill the "protected" in its name, don't let the real hardware
> values "shine through". Report a control register value expressing this.
>
> Signed-off-by: Jan Beulich 
> ---
> TBD: Do we want to permit Dom0 access?

I would recommend reordering the two patches and putting this one first
(along with the enumeration details, along with a pair of feature
strings in xen-cpuid).  This patch at least wants backporting.

This would be far more simple if we don't permit dom0 access.  Yes, it
shares platform responsibility with Xen, but it also can't do anything
more with the value than Xen can, which is to simply print it out for #MCEs.

Avoiding giving dom0 access would remove the need to attempt to
virtualise something which is model specific on the Intel side, and
allow all 4 MSRs to be unconditional #GP's.  I for one don't want to
have to consider the migration implications of letting guests see this.

~Andrew

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

Re: [Xen-devel] [PATCH 2/2] x86: explicitly disallow guest access to PPIN

[Jan Beulich]

On 30.10.2019 12:43, Andrew Cooper wrote:
> On 30/10/2019 10:39, Jan Beulich wrote:
>> To fulfill the "protected" in its name, don't let the real hardware
>> values "shine through". Report a control register value expressing this.
>>
>> Signed-off-by: Jan Beulich 
>> ---
>> TBD: Do we want to permit Dom0 access?
> 
> I would recommend reordering the two patches and putting this one first
> (along with the enumeration details, along with a pair of feature
> strings in xen-cpuid).  This patch at least wants backporting.

Well, the reason for this ordering is because this way Dom0
doesn't transiently lose all access.

As to xen-cpuid - I admit I simply forgot to update it, largely
due to there not being any CPUID bit on the Intel side. That part
would obviously live in whichever patch we elect to be first.

> This would be far more simple if we don't permit dom0 access.  Yes, it
> shares platform responsibility with Xen, but it also can't do anything
> more with the value than Xen can, which is to simply print it out for #MCEs.

Okay, then let's not expose it. I'll drop the TBD.

> Avoiding giving dom0 access would remove the need to attempt to
> virtualise something which is model specific on the Intel side, and
> allow all 4 MSRs to be unconditional #GP's.  I for one don't want to
> have to consider the migration implications of letting guests see this.

I don't understand the connection between Dom0 access and possible
migration implications. I'm also struggling to see how, for a well
behaved guest, there would need to be any migration considerations
in the first place: Once it has read the control register and found
the lockout bit set, it shouldn't make any further access attempts.
Similarly once it got a #GP(0) upon access, it wouldn't try again.
There would be an issue only if we actually supplied PPIN values,
even if it were just fake ones.

Jan

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

Re: [Xen-devel] [PATCH v3 00/20] hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge

[no-reply]

Patchew URL: https://patchew.org/QEMU/20191026180143.7369-1-phi...@redhat.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Subject: [Xen-devel] [PATCH v3 00/20] hw/i386/pc: Split PIIX3 southbridge from 
i440FX northbridge
Type: series
Message-id: 20191026180143.7369-1-phi...@redhat.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
   1688439..844178e  master -> master
Switched to a new branch 'test'
dff7d02 hw/pci-host/i440fx: Remove the last PIIX3 traces
1867a85 hw/pci-host: Rename incorrectly named 'piix' as 'i440fx'
474b121 hw/pci-host/piix: Extract PIIX3 functions to hw/isa/piix3.c
2be85e3 hw/pci-host/piix: Fix code style issues
8d47836 hw/pci-host/piix: Move i440FX declarations to hw/pci-host/i440fx.h
486b8c8 hw/pci-host/piix: Define and use the PIIX IRQ Route Control Registers
3b8d9a8 hw/pci-host/piix: Move RCR_IOPORT register definition
81f9a29 hw/pci-host/piix: Extract piix3_create()
c52f9e8 hw/i386: Remove obsolete LoadStateHandler::load_state_old handlers
f1f8cc1 hw/isa/piix4: Move piix4_create() to hw/isa/piix4.c
b3e67a2 hw/mips/mips_malta: Extract the PIIX4 creation code as piix4_create()
010fea9 hw/mips/mips_malta: Create IDE hard drive array dynamically
7eb4ef4 piix4: Add a MC146818 RTC Controller as specified in datasheet
081681a piix4: Add an i8254 PIT Controller as specified in datasheet
1324e3c piix4: Add an i8257 DMA Controller as specified in datasheet
1575c16 piix4: Rename PIIX4 object to piix4-isa
94e1fc6 Revert "irq: introduce qemu_irq_proxy()"
97363d5 piix4: Add an i8259 Interrupt Controller as specified in datasheet
a4fae07 piix4: Add the Reset Control Register
cdf07cc MAINTAINERS: Keep PIIX4 South Bridge separate from PC Chipsets

=== OUTPUT BEGIN ===
1/20 Checking commit cdf07cc06443 (MAINTAINERS: Keep PIIX4 South Bridge 
separate from PC Chipsets)
2/20 Checking commit a4fae0781590 (piix4: Add the Reset Control Register)
3/20 Checking commit 97363d58b691 (piix4: Add an i8259 Interrupt Controller as 
specified in datasheet)
4/20 Checking commit 94e1fc693918 (Revert "irq: introduce qemu_irq_proxy()")
5/20 Checking commit 1575c16a5e0a (piix4: Rename PIIX4 object to piix4-isa)
6/20 Checking commit 1324e3c5245d (piix4: Add an i8257 DMA Controller as 
specified in datasheet)
7/20 Checking commit 081681a42b68 (piix4: Add an i8254 PIT Controller as 
specified in datasheet)
8/20 Checking commit 7eb4ef4e008c (piix4: Add a MC146818 RTC Controller as 
specified in datasheet)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#195: 
deleted file mode 100644

total: 0 errors, 1 warnings, 166 lines checked

Patch 8/20 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
9/20 Checking commit 010fea91a9c0 (hw/mips/mips_malta: Create IDE hard drive 
array dynamically)
10/20 Checking commit b3e67a2aee92 (hw/mips/mips_malta: Extract the PIIX4 
creation code as piix4_create())
11/20 Checking commit f1f8cc125a08 (hw/isa/piix4: Move piix4_create() to 
hw/isa/piix4.c)
12/20 Checking commit c52f9e82acd5 (hw/i386: Remove obsolete 
LoadStateHandler::load_state_old handlers)
13/20 Checking commit 81f9a29fcead (hw/pci-host/piix: Extract piix3_create())
14/20 Checking commit 3b8d9a8dcae0 (hw/pci-host/piix: Move RCR_IOPORT register 
definition)
15/20 Checking commit 486b8c8b809e (hw/pci-host/piix: Define and use the PIIX 
IRQ Route Control Registers)
16/20 Checking commit 8d47836f5a7e (hw/pci-host/piix: Move i440FX declarations 
to hw/pci-host/i440fx.h)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#100: 
new file mode 100644

total: 0 errors, 1 warnings, 101 lines checked

Patch 16/20 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
17/20 Checking commit 2be85e397d14 (hw/pci-host/piix: Fix code style issues)
18/20 Checking commit 474b121662e8 (hw/pci-host/piix: Extract PIIX3 functions 
to hw/isa/piix3.c)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#67: 
new file mode 100644

ERROR: spaces required around that '*' (ctx:VxV)
#316: FILE: hw/isa/piix3.c:245:
+.subsections = (const VMStateDescription*[]) {
 ^

total: 1 errors, 1 warnings, 937 lines checked

Patch 18/20 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

19/20 Checking commit 1867a8558d6e (hw/pci-host: Rename incorrectly named 
'piix' as 'i440fx')
WARNING: added, moved or deleted file(s)

[Xen-devel] [PATCH v1] x86/hvm: Update code in HVMOP_altp2m_set_suppress_ve

[Alexandru Stefan ISAILA]

Originally the gfn and altp2m_idx are assigned from the a.u.mem_access union.
This works because it's the same memory used. This patch addresses this
issue by changing the mem_access union with the suppress_ve union for
consistency.

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/hvm/hvm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e4c0425330..06a7b40107 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4685,8 +4685,8 @@ static int do_altp2m_op(
 rc = -EINVAL;
 else
 {
-gfn_t gfn = _gfn(a.u.mem_access.gfn);
-unsigned int altp2m_idx = a.u.mem_access.view;
+gfn_t gfn = _gfn(a.u.suppress_ve.gfn);
+unsigned int altp2m_idx = a.u.suppress_ve.view;
 bool suppress_ve = a.u.suppress_ve.suppress_ve;
 
 rc = p2m_set_suppress_ve(d, gfn, suppress_ve, altp2m_idx);
-- 
2.17.1


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

Re: [Xen-devel] [PATCH v3 00/20] hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge

[Aleksandar Markovic]

>
> In case you, for any reason, can't complete this by softfreeze, I advice
>> you not to rush, and postpone the integration to 5.0.
>>
>
> This series doesn't provide any useful feature, it is a simple cleanup,
> posted and reviewed before soft freeze, so we still have 1 week (until
> hard freeze) to have it merged, or postpone. No need to stress out for
> a cleanup ;)
>
>
I sounded too tight, and I apologize.

You submitted the pull request before softfreeze, so, in my understanding,
it should be merged, after some integration hickups are resolved. And I am
positive you will resolve them.

By 'completing' I meant 'sending the pull request', so you are on time in
my book.

Take it easy, and I welcome this fine work of yours to be integrated.

Aleksandar



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

Re: [Xen-devel] [PATCH v1] x86/hvm: Update code in HVMOP_altp2m_set_suppress_ve

[Andrew Cooper]

On 30/10/2019 13:02, Alexandru Stefan ISAILA wrote:
> Originally the gfn and altp2m_idx are assigned from the a.u.mem_access union.
> This works because it's the same memory used. This patch addresses this
> issue by changing the mem_access union with the suppress_ve union for
> consistency.
>
> Signed-off-by: Alexandru Isaila 

Reviewed-by: Andrew Cooper 

CC Juergen. This wants backporting, so should be included in 4.13

~Andrew

> ---
>  xen/arch/x86/hvm/hvm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index e4c0425330..06a7b40107 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4685,8 +4685,8 @@ static int do_altp2m_op(
>  rc = -EINVAL;
>  else
>  {
> -gfn_t gfn = _gfn(a.u.mem_access.gfn);
> -unsigned int altp2m_idx = a.u.mem_access.view;
> +gfn_t gfn = _gfn(a.u.suppress_ve.gfn);
> +unsigned int altp2m_idx = a.u.suppress_ve.view;
>  bool suppress_ve = a.u.suppress_ve.suppress_ve;
>  
>  rc = p2m_set_suppress_ve(d, gfn, suppress_ve, altp2m_idx);


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

[Xen-devel] [linux-4.14 test] 143327: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow2   19 guest-start/debian.repeat fail REGR. vs. 142849
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 142849
 test-amd64-i386-xl-raw  19 guest-start/debian.repeat fail REGR. vs. 142849
 test-armhf-armhf-libvirt 19 leak-check/check fail REGR. vs. 142849
 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 142849
 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 142849

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-stop   fail REGR. vs. 142849

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   fail  like 142849
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-i386-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-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail 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-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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail 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-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-x

Re: [Xen-devel] [PATCH v1] x86/hvm: Update code in HVMOP_altp2m_set_suppress_ve

[Jan Beulich]

On 30.10.2019 15:14, Andrew Cooper wrote:
> On 30/10/2019 13:02, Alexandru Stefan ISAILA wrote:
>> Originally the gfn and altp2m_idx are assigned from the a.u.mem_access union.
>> This works because it's the same memory used. This patch addresses this
>> issue by changing the mem_access union with the suppress_ve union for
>> consistency.
>>
>> Signed-off-by: Alexandru Isaila 
> 
> Reviewed-by: Andrew Cooper 
> 
> CC Juergen. This wants backporting, so should be included in 4.13

I wouldn't have picked this up as backporting candidate, as
the generated code is correct, and the public interface isn't
supposed to change in the stable trees. I.e. I view this as a
purely cosmetic change, albeit a pretty helpful one.

Jan

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

[Xen-devel] [PATCH v2 for 4.13 1/2] x86/boot: allow early usage of cpu_has_hypervisor

[Sergey Dyasli]

Move early_cpu_init() to be near the top of __start_xen(). Since there
is no serial / vga output at that stage, introduce a new function
to print CPU information at the usual place during boot.

Finally, convert users of cpuid_ecx(1) & X86_FEATURE_HYPERVISOR.

Signed-off-by: Sergey Dyasli 
---
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Wei Liu 
CC: "Roger Pau Monné" 
CC: Juergen Gross 
---
 xen/arch/x86/cpu/common.c   | 25 +
 xen/arch/x86/guest/xen.c|  3 +--
 xen/arch/x86/mm.c   |  2 +-
 xen/arch/x86/setup.c|  4 +++-
 xen/include/asm-x86/setup.h |  1 +
 5 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 6c6bd63301..4f336f64d3 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -109,6 +109,7 @@ static const struct cpu_dev default_cpu = {
.c_init = default_init,
 };
 static const struct cpu_dev *this_cpu = &default_cpu;
+static bool __initdata unrecognised_cpu;
 
 static DEFINE_PER_CPU(uint64_t, msr_misc_features);
 void (* __read_mostly ctxt_switch_masking)(const struct vcpu *next);
@@ -301,9 +302,7 @@ void __init early_cpu_init(void)
case X86_VENDOR_SHANGHAI: this_cpu = &shanghai_cpu_dev; break;
case X86_VENDOR_HYGON:this_cpu = &hygon_cpu_dev;break;
default:
-   printk(XENLOG_ERR
-  "Unrecognised or unsupported CPU vendor '%.12s'\n",
-  c->x86_vendor_id);
+   unrecognised_cpu = true;
}
 
cpuid(0x0001, &eax, &ebx, &ecx, &edx);
@@ -317,11 +316,6 @@ void __init early_cpu_init(void)
c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = edx;
c->x86_capability[cpufeat_word(X86_FEATURE_SSE3)] = ecx;
 
-   printk(XENLOG_INFO
-  "CPU Vendor: %s, Family %u (%#x), Model %u (%#x), Stepping %u 
(raw %08x)\n",
-  x86_cpuid_vendor_to_str(c->x86_vendor), c->x86, c->x86,
-  c->x86_model, c->x86_model, c->x86_mask, eax);
-
eax = cpuid_eax(0x8000);
if ((eax >> 16) == 0x8000 && eax >= 0x8008) {
eax = cpuid_eax(0x8008);
@@ -342,6 +336,21 @@ void __init early_cpu_init(void)
initialize_cpu_data(0);
 }
 
+void __init early_cpu_print_info(void)
+{
+   struct cpuinfo_x86 *c = &boot_cpu_data;
+
+   if (unrecognised_cpu)
+   printk(XENLOG_ERR
+  "Unrecognised or unsupported CPU vendor '%.12s'\n",
+  c->x86_vendor_id);
+
+   printk(XENLOG_INFO "CPU Vendor: %s, Family %u (%#x), Model %u (%#x), "
+  "Stepping %u (raw %08x)\n",
+  x86_cpuid_vendor_to_str(c->x86_vendor), c->x86, c->x86,
+  c->x86_model, c->x86_model, c->x86_mask, cpuid_eax(0x0001));
+}
+
 static void generic_identify(struct cpuinfo_x86 *c)
 {
u32 eax, ebx, ecx, edx, tmp;
diff --git a/xen/arch/x86/guest/xen.c b/xen/arch/x86/guest/xen.c
index 7b7a5badab..9b776afed9 100644
--- a/xen/arch/x86/guest/xen.c
+++ b/xen/arch/x86/guest/xen.c
@@ -72,8 +72,7 @@ void __init probe_hypervisor(void)
 if ( xen_guest )
 return;
 
-/* Too early to use cpu_has_hypervisor */
-if ( !(cpuid_ecx(1) & cpufeat_mask(X86_FEATURE_HYPERVISOR)) )
+if ( !cpu_has_hypervisor )
 return;
 
 find_xen_leaves();
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 99816fc67c..4cdccab8c8 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5943,7 +5943,7 @@ const struct platform_bad_page *__init 
get_platform_badpages(unsigned int *array
 case 0x000806e0: /* erratum KBL??? */
 case 0x000906e0: /* errata KBL??? / KBW114 / CFW103 */
 *array_size = (cpuid_eax(0) >= 7 &&
-   !(cpuid_ecx(1) & cpufeat_mask(X86_FEATURE_HYPERVISOR)) 
&&
+   !cpu_has_hypervisor &&
(cpuid_count_ebx(7, 0) & 
cpufeat_mask(X86_FEATURE_HLE)));
 return &hle_bad_page;
 }
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index dec60d0301..07adfed566 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -723,6 +723,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 /* Enable NMIs.  Our loader (e.g. Tboot) may have left them disabled. */
 enable_nmis();
 
+early_cpu_init();
+
 if ( pvh_boot )
 {
 /*
@@ -1519,7 +1521,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 softirq_init();
 tasklet_subsys_init();
 
-early_cpu_init();
+early_cpu_print_info();
 
 paging_init();
 
diff --git a/xen/include/asm-x86/setup.h b/xen/include/asm-x86/setup.h
index 861d46d6ac..251151508d 100644
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -15,6 +15,7 @@ extern char __2M_rwdata_start[], __2M_rwdata_end[];
 extern unsigned long xenheap_initial_phys_start;
 
 void early_cpu_init(void);
+void early_cpu_print_info(void);
 void early_time_init(void);

[Xen-devel] [PATCH v2 for 4.13 2/2] x86/e820: fix 640k - 1M region reservation logic

[Sergey Dyasli]

Converting a guest from PV to PV-in-PVH makes the guest to have 384k
less memory, which may confuse guest's balloon driver. This happens
because Xen unconditionally reserves 640k - 1M region in E820 despite
the fact that it's really a usable RAM in PVH boot mode.

Fix this by skipping region type change in virtualised environments,
trusting whatever memory map our hypervisor has provided.

Signed-off-by: Sergey Dyasli 
---
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Wei Liu 
CC: "Roger Pau Monné" 
CC: Juergen Gross 
---
 xen/arch/x86/e820.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/e820.c b/xen/arch/x86/e820.c
index 8e8a2c4e1b..30ab8d9b35 100644
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ -318,9 +318,10 @@ static int __init copy_e820_map(struct e820entry * 
biosmap, unsigned int nr_map)
 
 /*
  * Some BIOSes claim RAM in the 640k - 1M region.
- * Not right. Fix it up.
+ * Not right. Fix it up, but only when running on bare metal.
  */
-if (type == E820_RAM) {
+if ( !cpu_has_hypervisor && type == E820_RAM )
+{
 if (start < 0x10ULL && end > 0xAULL) {
 if (start < 0xAULL)
 add_memory_region(start, 0xAULL-start, type);
-- 
2.17.1


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

Re: [Xen-devel] [PATCH v2 for 4.13 1/2] x86/boot: allow early usage of cpu_has_hypervisor

[Jan Beulich]

On 30.10.2019 15:54, Sergey Dyasli wrote:
> @@ -317,11 +316,6 @@ void __init early_cpu_init(void)
>   c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = edx;
>   c->x86_capability[cpufeat_word(X86_FEATURE_SSE3)] = ecx;
>  
> - printk(XENLOG_INFO
> -"CPU Vendor: %s, Family %u (%#x), Model %u (%#x), Stepping %u 
> (raw %08x)\n",
> -x86_cpuid_vendor_to_str(c->x86_vendor), c->x86, c->x86,
> -c->x86_model, c->x86_model, c->x86_mask, eax);

I'm slightly concerned of the code immediately ahead of this
printk() now running _much_ earlier. Did you inspect that there's
no change of the relevant cleared_caps[] entries between the new
and the old call position in setup.c?

> @@ -342,6 +336,21 @@ void __init early_cpu_init(void)
>   initialize_cpu_data(0);
>  }
>  
> +void __init early_cpu_print_info(void)
> +{
> + struct cpuinfo_x86 *c = &boot_cpu_data;

const

> + if (unrecognised_cpu)
> + printk(XENLOG_ERR
> +"Unrecognised or unsupported CPU vendor '%.12s'\n",
> +c->x86_vendor_id);
> +
> + printk(XENLOG_INFO "CPU Vendor: %s, Family %u (%#x), Model %u (%#x), "
> +"Stepping %u (raw %08x)\n",
> +x86_cpuid_vendor_to_str(c->x86_vendor), c->x86, c->x86,
> +c->x86_model, c->x86_model, c->x86_mask, cpuid_eax(0x0001));

May I suggest to use the shorter "1" here?

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -723,6 +723,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  /* Enable NMIs.  Our loader (e.g. Tboot) may have left them disabled. */
>  enable_nmis();
>  
> +early_cpu_init();
> +
>  if ( pvh_boot )
>  {
>  /*
> @@ -1519,7 +1521,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  softirq_init();
>  tasklet_subsys_init();
>  
> -early_cpu_init();
> +early_cpu_print_info();

I agree with splitting the function, but I guess this could still
be moved up by quite a bit, next to the printk()-s right after
console_init_preirq().

Jan

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

Re: [Xen-devel] [PATCH v2 for 4.13 2/2] x86/e820: fix 640k - 1M region reservation logic

[Jan Beulich]

On 30.10.2019 15:54, Sergey Dyasli wrote:
> Converting a guest from PV to PV-in-PVH makes the guest to have 384k
> less memory, which may confuse guest's balloon driver. This happens
> because Xen unconditionally reserves 640k - 1M region in E820 despite
> the fact that it's really a usable RAM in PVH boot mode.
> 
> Fix this by skipping region type change in virtualised environments,
> trusting whatever memory map our hypervisor has provided.
> 
> Signed-off-by: Sergey Dyasli 

Reviewed-by: Jan Beulich 

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

Re: [Xen-devel] Xen-unstable: AMD-Vi: update_paging_mode Try to access pdev_list without aquiring pcidevs_lock.

[Jan Beulich]

On 28.10.2019 11:32, Sander Eikelenboom wrote:
> While testing the latest xen-unstable and starting an HVM guest with 
> pci-passtrough on my AMD machine,
> my eye catched the following messages in xl dmesg I haven't seen before:
> 
> (XEN) [2019-10-28 10:23:16.372] AMD-Vi: update_paging_mode Try to access 
> pdev_list without aquiring pcidevs_lock.

Unfortunately this sits on the map/unmap path, and hence the
violator is far up one of the many call chains. Therefore I'd
like to ask that you rebuild and retry with the debugging
patch below. In case you observe multiple different call
trees, post them all please.

Jan

--- unstable.orig/xen/drivers/passthrough/amd/iommu_map.c
+++ unstable/xen/drivers/passthrough/amd/iommu_map.c
@@ -331,9 +331,12 @@ static int update_paging_mode(struct dom
 hd->arch.paging_mode = level;
 hd->arch.root_table = new_root;
 
-if ( !pcidevs_locked() )
+if ( iommu_debug && !pcidevs_locked() )
+{
 AMD_IOMMU_DEBUG("%s Try to access pdev_list "
 "without aquiring pcidevs_lock.\n", __func__);
+dump_execution_state();
+}
 
 /* Update device table entries using new root table and paging mode */
 for_each_pdev( d, pdev )

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

[Xen-devel] [PATCH 08/12] driver: xen: Replace cpu_up/down with device_online/offline

[Qais Yousef]

The core device API performs extra housekeeping bits that are missing
from directly calling cpu_up/down.

See commit a6717c01ddc2 ("powerpc/rtas: use device model APIs and
serialization during LPM") for an example description of what might go
wrong.

This also prepares to make cpu_up/down a private interface for anything
but the cpu subsystem.

Signed-off-by: Qais Yousef 
CC: Boris Ostrovsky 
CC: Juergen Gross 
CC: Stefano Stabellini 
CC: xen-devel@lists.xenproject.org
CC: linux-ker...@vger.kernel.org
---
 drivers/xen/cpu_hotplug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index f192b6f42da9..ec975decb5de 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -94,7 +94,7 @@ static int setup_cpu_watcher(struct notifier_block *notifier,
 
for_each_possible_cpu(cpu) {
if (vcpu_online(cpu) == 0) {
-   (void)cpu_down(cpu);
+   device_offline(get_cpu_device(cpu));
set_cpu_present(cpu, false);
}
}
-- 
2.17.1


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

[Xen-devel] [PATCH 00/12] Convert cpu_up/down to device_online/offline

[Qais Yousef]

Using cpu_up/down directly to bring cpus online/offline loses synchronization
with sysfs and could suffer from a race similar to what is described in
commit a6717c01ddc2 ("powerpc/rtas: use device model APIs and serialization
during LPM").

cpu_up/down seem to be more of a internal implementation detail for the cpu
subsystem to use to boot up cpus, perform suspend/resume and low level hotplug
operations. Users outside of the cpu subsystem would be better using the device
core API to bring a cpu online/offline which is the interface used to hotplug
memory and other system devices.

Several users have already migrated to use the device core API, this series
converts the remaining users and hides cpu_up/down from internal users at the
end.

I still need to update the documentation to remove references to cpu_up/down
and advocate for device_online/offline instead if this series will make its way
through.

I noticed this problem while working on a hack to disable offlining
a particular CPU but noticed that setting the offline_disabled attribute in the
device struct isn't enough because users can easily bypass the device core.
While my hack isn't a valid use case but it did highlight the inconsistency in
the way cpus are being onlined/offlined and this attempt hopefully improves on
this.

The first 6 patches fixes arch users.

The next 5 patches fixes generic code users. Particularly creating a new
special exported API for the device core to use instead of cpu_up/down.
Maybe we can do something more restrictive than that.

The last patch removes cpu_up/down from cpu.h and unexport the functions.

In some cases where the use of cpu_up/down seemed legitimate, I encapsulated
the logic in a higher level - special purposed function; and converted the code
to use that instead.

I did run the rcu torture, lock torture and psci checker tests and no problem
was noticed. I did perform build tests on all arch affected except for parisc.

Hopefully I got the CC list right for all the patches. Apologies in advance if
some people were omitted from some patches but they should have been CCed.

CC: Armijn Hemel 
CC: Benjamin Herrenschmidt 
CC: Bjorn Helgaas 
CC: Borislav Petkov 
CC: Boris Ostrovsky 
CC: Catalin Marinas 
CC: Christophe Leroy 
CC: Daniel Lezcano 
CC: Davidlohr Bueso 
CC: "David S. Miller" 
CC: Eiichi Tsukata 
CC: Enrico Weigelt 
CC: Fenghua Yu 
CC: Greg Kroah-Hartman 
CC: Helge Deller 
CC: "H. Peter Anvin" 
CC: Ingo Molnar 
CC: "James E.J. Bottomley" 
CC: James Morse 
CC: Jiri Kosina 
CC: Josh Poimboeuf 
CC: Josh Triplett 
CC: Juergen Gross 
CC: Lorenzo Pieralisi 
CC: Mark Rutland 
CC: Michael Ellerman 
CC: Nadav Amit 
CC: Nicholas Piggin 
CC: "Paul E. McKenney" 
CC: Paul Mackerras 
CC: Pavankumar Kondeti 
CC: "Peter Zijlstra (Intel)" 
CC: "Rafael J. Wysocki" 
CC: Ram Pai 
CC: Richard Fontana 
CC: Sakari Ailus 
CC: Stefano Stabellini 
CC: Steve Capper 
CC: Thiago Jung Bauermann 
CC: Thomas Gleixner 
CC: Tony Luck 
CC: Will Deacon 
CC: Zhenzhong Duan 
CC: linux-arm-ker...@lists.infradead.org
CC: linux-i...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: linux-par...@vger.kernel.org
CC: linuxppc-...@lists.ozlabs.org
CC: sparcli...@vger.kernel.org
CC: x...@kernel.org
CC: xen-devel@lists.xenproject.org


Qais Yousef (12):
  arm64: hibernate.c: create a new function to handle cpu_up(sleep_cpu)
  x86: Replace cpu_up/down with devcie_online/offline
  powerpc: Replace cpu_up/down with device_online/offline
  ia64: Replace cpu_down with freeze_secondary_cpus
  sparc: Replace cpu_up/down with device_online/offline
  parisc: Replace cpu_up/down with device_online/offline
  driver: base: cpu: export device_online/offline
  driver: xen: Replace cpu_up/down with device_online/offline
  firmware: psci: Replace cpu_up/down with device_online/offline
  torture: Replace cpu_up/down with device_online/offline
  smp: Create a new function to bringup nonboot cpus online
  cpu: Hide cpu_up/down

 arch/arm64/kernel/hibernate.c  | 13 +++
 arch/ia64/kernel/process.c |  8 +---
 arch/parisc/kernel/processor.c |  4 +-
 arch/powerpc/kernel/machine_kexec_64.c |  4 +-
 arch/sparc/kernel/ds.c |  8 +++-
 arch/x86/kernel/topology.c |  4 +-
 arch/x86/mm/mmio-mod.c |  8 +++-
 arch/x86/xen/smp.c |  4 +-
 drivers/base/core.c|  4 ++
 drivers/base/cpu.c |  4 +-
 drivers/firmware/psci/psci_checker.c   |  6 ++-
 drivers/xen/cpu_hotplug.c  |  2 +-
 include/linux/cpu.h|  6 ++-
 kernel/cpu.c   | 53 --
 kernel/smp.c   |  9 +
 kernel/torture.c   | 15 ++--
 16 files changed, 106 insertions(+), 46 deletions(-)

-- 
2.17.1


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

Re: [Xen-devel] [osstest test] 143311: regressions - FAIL

[Ian Jackson]

osstest service owner writes ("[osstest test] 143311: regressions - FAIL"):
> flight 143311 osstest real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/143311/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-pvshim   12 guest-start  fail REGR. vs. 
> 143267

This is the only problem here, and is the known issue in unstable, so
I am going to force push this.

Ian.

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

[Xen-devel] [OSSTEST PATCH] xl guest creation: Pause 10s to work around libxl/blkback races

[Ian Jackson]

In ea6626f7edd9eb40a3510eaf6816a77cac4f63d0
  guest_prepare_disk: Only do the umount if we set an env var
we removed (in the usual case) a check for the guest disk
already being mounted in dom0 etc.  This check is there for
ad-hoc testing.

We removed it because it exposes what we think is an annoying race in
blkback.

Unfortunately this change seems to have made guest-rapid-restart races
worse rather than better.  Steps test-* guest-start/debian.repeat seem
to fail a lot more now.

We are in the throes of preparing the Xen 4.13 release.  These guest
restart races have existed for a long time.

Bodge this for now by adding a sleep :-/.

We do this in the xl toolstack, during domain creation.  And also in
the libvirt toolstack because that uses xl but doesn't inherit the
sleep from the Osstest module.

CC: Jürgen Groß 
CC: Wei Liu 
CC: Anthony PERARD 
Signed-off-by: Ian Jackson 
---
 Osstest/Toolstack/libvirt.pm | 1 +
 Osstest/Toolstack/xl.pm  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index e817f5b4..23c76cc0 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -55,6 +55,7 @@ sub create ($$) {
 my $lcfg = $cfg;
 $lcfg =~ s,/,-,g;
 $lcfg = hostnamepath($ho)."--$lcfg";
+sleep(10);
 target_cmd_root($ho, "virsh domxml-from-native xen-xl $cfg > $cfg.xml", 
30);
 target_getfile_root($ho,60,"$cfg.xml", "$stash/$lcfg");
 target_cmd_root($ho, "virsh create --file $cfg.xml", 100);
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index 85972753..517b0f4d 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -43,6 +43,7 @@ sub destroy ($$) {
 sub _create ($$$) {
 my ($self,$gho,$options) = @_;
 my $cfg = $gho->{CfgPath};
+sleep(10);
 target_cmd_root($self->{Host},
$self->{_VerboseCommand}." create $options $cfg", 100);
 }
-- 
2.11.0


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

[Xen-devel] rochester boot loader serial output issue (was Re: [xen-unstable test] 143061: regressions - trouble: broken/fail/pass)

[Ian Jackson]

Stefano Stabellini writes ("Re: [Xen-devel] [xen-unstable test] 143061: 
regressions - trouble: broken/fail/pass"):
> And I do have a suggestion for somebody else to pick this up: Brian
> (CC'ed) has joined Xilinx recently and might be willing to help on this.
> However, we would need to give him access to the colo for him to be able
> to make any progress.

Hi.  Offline we exchanged details and Brian now has access to the
colo.  I'll send a briefing by private email.

Brian, are you available to work on this now ?  If so I will set up a
an automatic repro of the problem on one of our two affected boxes.
This will book out the box for you to play with.

It's probably best if we negotiate in detail on #xendevel, so, Brian,
please reply there.  In particular I am often on IRC out of my usual
working hours, when I may not be reading my email.

Ian.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-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-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  ece1d5cda17c2815dd194909569deb254ddae575
baseline version:
 xen  f51d4a19427674491eaecef85c551613450188c5

Last test of basis   143367  2019-10-29 22:01:03 Z0 days
Testing same since   143407  2019-10-30 14:13:08 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Ross Lagerwall 

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-amd64pass
 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
   f51d4a1942..ece1d5cda1  ece1d5cda17c2815dd194909569deb254ddae575 -> smoke

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

Re: [Xen-devel] [PATCH v2] x86/passthrough: fix migration of MSI when using posted interrupts

[Joe Jin]

On 10/30/19 1:24 AM, Roger Pau Monné wrote:
> Can you try to add the following debug patch on top of the existing
> one and report the output that you get on the Xen console?

Applied debug patch and run the test again, not of any log printed,
attached Xen log on serial console, seems pi_update_irte() not been
called for iommu_intpost was false.

Thanks,
Joe
(XEN) Xen version 4.12.2-pre (root@) (gcc (GCC) 4.4.7 20120313 (Red Hat 
4.4.7-23.0.1)) debug=n  Tue Oct 29 02:43:40 PDT 2019
(XEN) Latest ChangeSet: 
(XEN) Bootloader: GRUB 2.02~beta2   
(XEN) Command line: placeholder dom0_mem=max:3456M allowsuperpage 
dom0_vcpus_pin=numa dom0_max_vcpus=4 crashkernel=512M@1024M iommu=1 
hvm_debug=832 guest_loglvl=all com1=115200,8n1 console=com1 conring_size=1m 
console_to_ring 
(XEN) Xen image load base address: 0x7720   
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds 
(XEN)  EDID info not retrieved because no DDC retrieval method detected 
(XEN) Disc information: 
(XEN)  Found 2 MBR signatures   
(XEN)  Found 2 EDD information structures   
(XEN) Xen-e820 RAM map: 
(XEN)   - 0009b000 (usable) 
(XEN)  0009b000 - 000a (reserved)   
(XEN)  000e - 0010 (reserved)   
(XEN)  0010 - 77928000 (usable) 
(XEN)  77928000 - 79356000 (reserved)  
(XEN)  79356000 - 79391000 (ACPI data)
(XEN)  79391000 - 7990 (ACPI NVS)
(XEN)  7990 - 7bd4d000 (reserved)
(XEN)  7bd4d000 - 7bd58000 (usable)
(XEN)  7bd58000 - 7bd59000 (reserved)
(XEN)  7bd59000 - 7bd5c000 (usable)
(XEN)  7bd5c000 - 7bd5d000 (reserved)
(XEN)  7bd5d000 - 7bd5e000 (usable)
(XEN)  7bd5e000 - 7bde4000 (reserved)
(XEN)  7bde4000 - 7c00 (usable)
(XEN)  8000 - 9000 (reserved)
(XEN)  fed1c000 - fed2 (reserved)
(XEN)  ff00 - 0001 (reserved)
(XEN)  0001 - 00208000 (usable)
(XEN) Kdump: 512MB (524288kB) at 0x4000
(XEN) ACPI: RSDP 000F0530, 0024 (r2 ORACLE)
(XEN) ACPI: XSDT 7936C0B0, 00E4 (r1 ORACLE X5-2 30130200 AMI 10013)
(XEN) ACPI: FACP 7937F608, 010C (r5 ORACLE X5-2 30130200 AMI 10013)
(XEN) ACPI: DSDT 7936C228, 133DE (r2 ORACLE X5-2 30130200 INTL 20091013)
(XEN) ACPI: FACS 798FDF80, 0040
(XEN) ACPI: APIC 7937F718, 0224 (r3 ORACLE X5-2 30130200 AMI 10013)
(XEN) ACPI: FPDT 7937F940, 0044 (r1 ORACLE X5-2 30130200 AMI 10013)
(XEN) ACPI: FIDT 7937F988, 009C (r1 ORACLE X5-2 30130200 AMI 10013)
(XEN) ACPI: SPMI 7937FA28, 0041 (r5 ORACLE X5-2 30130200 AMI.0)
(XEN) ACPI: MCFG 7937FA70, 003C (r1 ORACLE X5-2 30130200 MSFT   97)
(XEN) ACPI: OEMS 7937FAB0, 07DC (r1 ORACLE X5-2 30130200 ORCL1)
(XEN) ACPI: UEFI 79380290, 0042 (r1 ORACLE X5-2 30130200 0)
(XEN) ACPI: BDAT 793802D8, 0030 (r1 ORACLE X5-2 30130200 INTL 20091013)
(XEN) ACPI: HPET 79380308, 0038 (r1 ORACLE X5-2 30130200 INTL 20091013)
(XEN) ACPI: MSCT 79380340, 0090 (r1 ORACLE X5-2 30130200 INTL 20091013)
(XEN) ACPI: PCCT 793803D0, 006E (r1 ORACLE X5-2 30130200 INTL 20091013)
(XEN) ACPI: PMCT 79380440, 0064 (r1 ORACLE X5-2 30130200 INTL 20091013)
(XEN) ACPI: PMTT 793804A8, 0268 (r1 ORACLE X5-2 30130200 INTL 20091013)
(XEN) ACPI: SLIT 79380710, 0030 (r1 ORACLE X5-2 30130200 INTL 20091013)
(XEN) ACPI: SRAT 79380740, 0E58 (r3 ORACLE X5-2 30130200 INTL 20091013)
(XEN) ACPI: WDDT 79381598, 0040 (r1 ORACLE X5-2 30130200 INTL 20091013)
(XEN) ACPI: SSDT 793815D8, ED2F (r1 ORACLEPmMgt 30130200 INTL 20120913)
(XEN) ACPI: OEMP 79390308, 0158 (r1 ORACLE X5-2 30130200 ORCL1)
(XEN) ACPI: DMAR 79390460, 0148 (r1 ORACLE X5-2 30130200 INTL 20091013)
(XEN) ACPI: HEST 793905A8, 013C (r1 ORACLE X5-2 30130200 INTL1)
(XEN) ACPI: BERT 793906E8, 0030 (r1 ORACLE X5-2 30130200 INTL1)
(XEN) ACPI: ERST 79390718, 0230 (r1 ORACLE X5-2 30130200 INTL1)
(XEN) ACPI: EINJ 79390948, 0130 (r1 ORACLE X5-2 30130200 INTL1)
(XEN) System RAM: 130938MB (134081464kB)
(XEN) Domain heap initialised DMA width 32 bits
(XEN) Allocated co

Re: [Xen-devel] [PATCH v2 09/15] xen/gntdev: use mmu_range_notifier_insert

[Boris Ostrovsky]

On 10/28/19 4:10 PM, Jason Gunthorpe wrote:
> From: Jason Gunthorpe 
>
> gntdev simply wants to monitor a specific VMA for any notifier events,
> this can be done straightforwardly using mmu_range_notifier_insert() over
> the VMA's VA range.
>
> The notifier should be attached until the original VMA is destroyed.
>
> It is unclear if any of this is even sane, but at least a lot of duplicate
> code is removed.

I didn't have a chance to look at the patch itself yet but as a heads-up
--- it crashes dom0.

-boris


>
> Cc: Oleksandr Andrushchenko 
> Cc: Boris Ostrovsky 
> Cc: xen-devel@lists.xenproject.org
> Cc: Juergen Gross 
> Cc: Stefano Stabellini 
> Signed-off-by: Jason Gunthorpe 
> ---
>  drivers/xen/gntdev-common.h |   8 +-
>  drivers/xen/gntdev.c| 180 ++--
>  2 files changed, 49 insertions(+), 139 deletions(-)
>
> diff --git a/drivers/xen/gntdev-common.h b/drivers/xen/gntdev-common.h
> index 2f8b949c3eeb14..b201fdd20b667b 100644
> --- a/drivers/xen/gntdev-common.h
> +++ b/drivers/xen/gntdev-common.h
> @@ -21,15 +21,8 @@ struct gntdev_dmabuf_priv;
>  struct gntdev_priv {
>   /* Maps with visible offsets in the file descriptor. */
>   struct list_head maps;
> - /*
> -  * Maps that are not visible; will be freed on munmap.
> -  * Only populated if populate_freeable_maps == 1
> -  */
> - struct list_head freeable_maps;
>   /* lock protects maps and freeable_maps. */
>   struct mutex lock;
> - struct mm_struct *mm;
> - struct mmu_notifier mn;
>  
>  #ifdef CONFIG_XEN_GRANT_DMA_ALLOC
>   /* Device for which DMA memory is allocated. */
> @@ -49,6 +42,7 @@ struct gntdev_unmap_notify {
>  };
>  
>  struct gntdev_grant_map {
> + struct mmu_range_notifier notifier;
>   struct list_head next;
>   struct vm_area_struct *vma;
>   int index;
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index a446a7221e13e9..12d626670bebbc 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -65,7 +65,6 @@ MODULE_PARM_DESC(limit, "Maximum number of grants that may 
> be mapped by "
>  static atomic_t pages_mapped = ATOMIC_INIT(0);
>  
>  static int use_ptemod;
> -#define populate_freeable_maps use_ptemod
>  
>  static int unmap_grant_pages(struct gntdev_grant_map *map,
>int offset, int pages);
> @@ -251,12 +250,6 @@ void gntdev_put_map(struct gntdev_priv *priv, struct 
> gntdev_grant_map *map)
>   evtchn_put(map->notify.event);
>   }
>  
> - if (populate_freeable_maps && priv) {
> - mutex_lock(&priv->lock);
> - list_del(&map->next);
> - mutex_unlock(&priv->lock);
> - }
> -
>   if (map->pages && !use_ptemod)
>   unmap_grant_pages(map, 0, map->count);
>   gntdev_free_map(map);
> @@ -445,17 +438,9 @@ static void gntdev_vma_close(struct vm_area_struct *vma)
>   struct gntdev_priv *priv = file->private_data;
>  
>   pr_debug("gntdev_vma_close %p\n", vma);
> - if (use_ptemod) {
> - /* It is possible that an mmu notifier could be running
> -  * concurrently, so take priv->lock to ensure that the vma won't
> -  * vanishing during the unmap_grant_pages call, since we will
> -  * spin here until that completes. Such a concurrent call will
> -  * not do any unmapping, since that has been done prior to
> -  * closing the vma, but it may still iterate the unmap_ops list.
> -  */
> - mutex_lock(&priv->lock);
> + if (use_ptemod && map->vma == vma) {
> + mmu_range_notifier_remove(&map->notifier);
>   map->vma = NULL;
> - mutex_unlock(&priv->lock);
>   }
>   vma->vm_private_data = NULL;
>   gntdev_put_map(priv, map);
> @@ -477,109 +462,44 @@ static const struct vm_operations_struct gntdev_vmops 
> = {
>  
>  /* -- */
>  
> -static bool in_range(struct gntdev_grant_map *map,
> -   unsigned long start, unsigned long end)
> -{
> - if (!map->vma)
> - return false;
> - if (map->vma->vm_start >= end)
> - return false;
> - if (map->vma->vm_end <= start)
> - return false;
> -
> - return true;
> -}
> -
> -static int unmap_if_in_range(struct gntdev_grant_map *map,
> -   unsigned long start, unsigned long end,
> -   bool blockable)
> +static bool gntdev_invalidate(struct mmu_range_notifier *mn,
> +   const struct mmu_notifier_range *range,
> +   unsigned long cur_seq)
>  {
> + struct gntdev_grant_map *map =
> + container_of(mn, struct gntdev_grant_map, notifier);
>   unsigned long mstart, mend;
>   int err;
>  
> - if (!in_range(map, start, end))
> - return 0;
> + if (!mmu_notifier_range_b

Re: [Xen-devel] [PATCH v2 for 4.13 1/2] x86/boot: allow early usage of cpu_has_hypervisor

[Sergey Dyasli]

On 30/10/2019 15:32, Jan Beulich wrote:
> On 30.10.2019 15:54, Sergey Dyasli wrote:
>> @@ -317,11 +316,6 @@ void __init early_cpu_init(void)
>>  c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = edx;
>>  c->x86_capability[cpufeat_word(X86_FEATURE_SSE3)] = ecx;
>>  
>> -printk(XENLOG_INFO
>> -   "CPU Vendor: %s, Family %u (%#x), Model %u (%#x), Stepping %u 
>> (raw %08x)\n",
>> -   x86_cpuid_vendor_to_str(c->x86_vendor), c->x86, c->x86,
>> -   c->x86_model, c->x86_model, c->x86_mask, eax);
> 
> I'm slightly concerned of the code immediately ahead of this
> printk() now running _much_ earlier. Did you inspect that there's
> no change of the relevant cleared_caps[] entries between the new
> and the old call position in setup.c?

You are right, this idea requires a more sophisticated approach.
Please disregard this patch. For now I'll add something like
early_cpu_has_hypervisor(). Will send a v3 soon.

--
Thanks,
Sergey

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

Re: [Xen-devel] [PATCH v2] x86/passthrough: fix migration of MSI when using posted interrupts

[Roger Pau Monné]

On Wed, Oct 30, 2019 at 09:38:16AM -0700, Joe Jin wrote:
> On 10/30/19 1:24 AM, Roger Pau Monné wrote:
> > Can you try to add the following debug patch on top of the existing
> > one and report the output that you get on the Xen console?
> 
> Applied debug patch and run the test again, not of any log printed,
> attached Xen log on serial console, seems pi_update_irte() not been
> called for iommu_intpost was false.

I have to admit I'm lost at this point. Does it mean the original
issue had nothing to do with posted interrupts?

Where you booting using iommu=intpost in your previous tests? Note
that posted interrupts is not enabled by default according to the
command line documentation.

Can you confirm whether you also see weird behavior without using
posted interrupts, and can you turn posted interrupts on and give the
patch a try?

Thanks, Roger.

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

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-qemut-ws16-amd64

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-ws16-amd64
testid xen-boot

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: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  d6d5df1db6e9d7f8f76d2911707f7d5877251b02
  Bug not present: 223cea6a4f0552b86fb25e3b8bbd00469816cd7a
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/143411/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-xl-qemut-ws16-amd64.xen-boot.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-i386-xl-qemut-ws16-amd64.xen-boot
 --summary-out=tmp/143411.bisection-summary --basis-template=133580 
--blessings=real,real-bisect linux-linus test-amd64-i386-xl-qemut-ws16-amd64 
xen-boot
Searching for failure / basis pass:
 143277 fail [host=fiano1] / 138849 ok.
Failure / basis pass flights: 143277 / 138849
(tree with no url: minios)
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: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest d6d5df1db6e9d7f8f76d2911707f7d5877251b02 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
6996ec88a244a2428beb81d126ee55d152f62a07 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
933ebad2470a169504799a1d95b8e410bd9847ef 
120996f147131eca8af90e30c900bc14bc824d9f 
518c935fac4d30b3ec35d4b6add82b17b7d7aca3
Basis pass 223cea6a4f0552b86fb25e3b8bbd00469816cd7a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d031fc07eb83c9d13bff3ebac25da458d5a47917 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
9cca02d8ffc23e9688a971d858e4ffdff5389b11 
30f1e41f04fb4c715d27f987f003cfc31c9ff4f3 
843cec0de800a5f925f8071a7f58f3fb1c6b6eb6
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#223cea6a4f0552b86fb25e3b8bbd00469816cd7a-d6d5df1db6e9d7f8f76d2911707f7d5877251b02
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/osstest/ovmf.git#d031fc07eb83c9d13bff3ebac25da458d5a47917-6996ec88a244a2428beb81d126ee55d152f62a07
 git://xenbits.xen.org/qemu-xen-traditional.\
 
git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798
 
git://xenbits.xen.org/qemu-xen.git#9cca02d8ffc23e9688a971d858e4ffdff5389b11-933ebad2470a169504799a1d95b8e410bd9847ef
 
git://xenbits.xen.org/osstest/seabios.git#30f1e41f04fb4c715d27f987f003cfc31c9ff4f3-120996f147131eca8af90e30c900bc14bc824d9f
 
git://xenbits.xen.org/xen.git#843cec0de800a5f925f8071a7f58f3fb1c6b6eb6-518c935fac4d30b3ec35d4b6add82b17b7d7aca3
adhoc-revtuple-generator: tree discontiguous: linux-2.6
From git://cache:9419/git://xenbits.xen.org/xen
   f51d4a1942..ece1d5cda1  smoke  -> origin/smoke
Loaded 10425 nodes in revision graph
Searching for test results:
 138780 pass irrelevant
 138813 pass irrelevant
 138849 pass 223cea6a4f0552b86fb25e3b8bbd00469816cd7a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d031fc07eb83c9d13bff3ebac25da458d5a47917 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
9cca02d8ffc23e9688a971d858e4ffdff5389b11 
30f1e41f04fb4c715d27f987f003cfc31c9ff4f3 
843cec0de800a5f925f8071a7f58f3fb1c6b6eb6
 138878 fail irrelevant
 138902 fail irrelevant
 138962 fail irrelevant
 139003 fail irrelevant
 139068 fail irrelevant
 139134 fail irrelevant
 139237 fail irrelevant
 139223 fail irrelevant
 139257 fail irrelevant
 139324 fail irrelevant
 139306 fail irrelevant
 139286 fail irrelevant
 139338 fail irrelevant
 139361 fail irrelevant
 139383 fail irrelevant
 139408 fail irrelevant
 139478 fail irrelevant
 139532 fail irrelevant
 139584 fail irrelevant
 139555 fail irrelevant
 139687 fail irrelevant
 139616 fail irrelevant
 139669 fail irrelevant
 139711 fail irrelevant
 139735 fail irrelevant
 139792 fail irrelevant
 139832 fail irrelevant
 139942 fail irrelevant
 139866 fail irrelevant
 139907 fail irrelevant
 139996 fail irrelevant
 140038 fail irrelevant
 140128 fail irrelevant
 140163 fail irrelevant
 140251 fail irrelevant
 140188 fail irrelevant
 140216 fa

Re: [Xen-devel] [PATCH v2] x86/passthrough: fix migration of MSI when using posted interrupts

[Joe Jin]

On 10/30/19 10:23 AM, Roger Pau Monné wrote:
> On Wed, Oct 30, 2019 at 09:38:16AM -0700, Joe Jin wrote:
>> On 10/30/19 1:24 AM, Roger Pau Monné wrote:
>>> Can you try to add the following debug patch on top of the existing
>>> one and report the output that you get on the Xen console?
>>
>> Applied debug patch and run the test again, not of any log printed,
>> attached Xen log on serial console, seems pi_update_irte() not been
>> called for iommu_intpost was false.
> 
> I have to admit I'm lost at this point. Does it mean the original
> issue had nothing to do with posted interrupts?

Looks when inject irq by vlapic_set_irq(), it checked by
hvm_funcs.deliver_posted_intr rather than iommu_intpost:

 176 if ( hvm_funcs.deliver_posted_intr )
 177 hvm_funcs.deliver_posted_intr(target, vec);

And deliver_posted_intr() would be there, when vmx enabled:

(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB

So original issue still used posted interrupts?

> 
> Where you booting using iommu=intpost in your previous tests? Note
> that posted interrupts is not enabled by default according to the
> command line documentation.
> 

No, from xen command line you can see I only had iommu=1 for xen.

> Can you confirm whether you also see weird behavior without using
> posted interrupts, and can you turn posted interrupts on and give the
> patch a try?

I disabled apicv, looks posted interrupts been disables as well, then
I could not reproduced it anymore:

(XEN) Command line: placeholder dom0_mem=max:3456M allowsuperpage 
dom0_vcpus_pin=numa dom0_max_vcpus=4 crashkernel=512M@1024M 
iommu=verbose,debug,force,intremap,intpost hvm_debug=832 guest_loglvl=all 
com1=115200,8n1 console=com1 conring_size=1m console_to_ring apicv=0
...
(XEN) Initing memory sharing.
(XEN) Intel VT-d iommu 0 supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d iommu 1 supported page sizes: 4kB, 2MB, 1GB.
(XEN) Intel VT-d Snoop Control enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping enabled.
(XEN) Intel VT-d Posted Interrupt not enabled.
(XEN) Intel VT-d Shared EPT tables enabled.
...
(XEN) VMX: Supported advanced features:
(XEN)  - APIC MMIO access virtualisation
(XEN)  - APIC TPR shadow
(XEN)  - Extended Page Tables (EPT)
(XEN)  - Virtual-Processor Identifiers (VPID)
(XEN)  - Virtual NMI
(XEN)  - MSR direct-access bitmap
(XEN)  - Unrestricted Guest
(XEN)  - VMCS shadowing
(XEN)  - VM Functions
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled

Thanks,
Joe


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

[Xen-devel] [XEN PATCH for-4.13 v2 6/6] libxl_qmp: Have a lock for QMP socket access

[Anthony PERARD]

This patch workaround the fact that it's not possible to connect
multiple time to a single QMP socket. QEMU listen on the socket with
a backlog value of 1, which mean that on Linux when concurrent thread
call connect() on the socket, they get EAGAIN.

Background:
This happens when attempting to create a guest with multiple
pci devices passthrough, libxl creates one connection per device to
attach and execute connect() on all at once before any single
connection has finished.

To work around this, we use a new lock.

Error handling of connect() and lock() is a bit awkward as
libxl__ev_qmp_send() doesn't allow to call the callback synchronously.
So we setup a timer to have a callback that has been called
asynchronously. We use the _abs variant it does strictly less than
_rel, thus avoiding unnecessary code that could return an error
(unnecessary because we only need to have the callback been called
ASAP).

Reported-by: Sander Eikelenboom 
Signed-off-by: Anthony PERARD 
---

Notes:
v2:
- Handle error path

 tools/libxl/libxl_internal.c |   5 ++
 tools/libxl/libxl_internal.h |   9 +++
 tools/libxl/libxl_qmp.c  | 109 ++-
 3 files changed, 108 insertions(+), 15 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index b2084157e4cd..ba5637358e7c 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -590,6 +590,11 @@ void libxl__ev_devlock_init(libxl__ev_slowlock *lock)
 ev_slowlock_init_internal(lock, "libxl-device-changes-lock");
 }
 
+void libxl__ev_qmplock_init(libxl__ev_slowlock *lock)
+{
+ev_slowlock_init_internal(lock, "qmp-socket-lock");
+}
+
 static void ev_lock_prepare_fork(libxl__egc *egc, libxl__ev_slowlock *lock);
 static void ev_lock_child_callback(libxl__egc *egc, libxl__ev_child *child,
pid_t pid, int status);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f95895eae17d..b244b508f4c6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -371,6 +371,9 @@ struct libxl__ev_child {
  * which may take a significant amount time.
  * It is to be acquired by an ao event callback.
  *
+ * If libxl__ev_devlock is needed, it should be acquired while every
+ * libxl__ev_qmp are Idle for the current domain.
+ *
  * It is to be acquired when adding/removing devices or making changes
  * to them when this is a slow operation and json_lock isn't appropriate.
  *
@@ -411,6 +414,7 @@ struct libxl__ev_slowlock {
 bool held;
 };
 _hidden void libxl__ev_devlock_init(libxl__ev_slowlock *);
+_hidden void libxl__ev_qmplock_init(libxl__ev_slowlock *);
 _hidden void libxl__ev_slowlock_lock(libxl__egc *, libxl__ev_slowlock *);
 _hidden void libxl__ev_slowlock_unlock(libxl__gc *, libxl__ev_slowlock *);
 _hidden void libxl__ev_slowlock_dispose(libxl__gc *, libxl__ev_slowlock *);
@@ -479,6 +483,8 @@ _hidden void libxl__ev_qmp_dispose(libxl__gc *gc, 
libxl__ev_qmp *ev);
 typedef enum {
 /* initial state */
 qmp_state_disconnected = 1,
+/* waiting for lock */
+qmp_state_waiting_lock,
 /* connected to QMP socket, waiting for greeting message */
 qmp_state_connecting,
 /* qmp_capabilities command sent, waiting for reply */
@@ -512,6 +518,9 @@ struct libxl__ev_qmp {
 libxl__carefd *cfd;
 libxl__ev_fd efd;
 libxl__qmp_state state;
+libxl__ev_slowlock lock;
+libxl__ev_time etime;
+int rc;
 int id;
 int next_id;/* next id to use */
 /* receive buffer */
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f0e0b50bd1c5..2087a85e321d 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1084,6 +1084,7 @@ static void dm_state_saved(libxl__egc *egc, libxl__ev_qmp 
*ev,
  *
  * qmp_state External   cfdefd id rx_buf* tx_buf* msg*
  * disconnected   Idle   NULL   Idlereset  freefreefree
+ * waiting_lock   Active open   Idlereset  usedfreeset
  * connecting Active open   IN  reset  usedfreeset
  * cap.negActive open   IN|OUT  sent   usedcap_neg set
  * cap.negActive open   IN  sent   usedfreeset
@@ -1118,7 +1119,8 @@ static void dm_state_saved(libxl__egc *egc, libxl__ev_qmp 
*ev,
  * msg_id   0 id assoctiated with the command in `msg`
  *
  * - Allowed internal state transition:
- * disconnected -> connecting
+ * disconnected -> waiting_lock
+ * waiting_lock -> connecting
  * connection   -> capability_negotiation
  * capability_negotiation/connected -> waiting_reply
  * waiting_reply-> connected
@@ -1153,6 +1155,10 @@ static void qmp_ev_ensure_reading_writing(libxl__gc *gc, 
libxl__ev_qmp *ev)
 {
 short events = POLLIN;
 
+if (ev->state == qmp_state_waiting_lock)
+/* We can't modifi

[Xen-devel] [XEN PATCH for-4.13 v2 4/6] libxl: Introduce libxl__ev_slowlock_dispose

[Anthony PERARD]

Which allow to cancel the lock operation while it is in Active state.

Signed-off-by: Anthony PERARD 
---

Notes:
v2:
- Renamed libxl__ev_qmplock_dispose to libxl__ev_slowlock_dispose
- This new API was part of the patch "Introduce libxl__ev_qmplock" in v1.

 tools/libxl/libxl_internal.c | 6 ++
 tools/libxl/libxl_internal.h | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 9520ac36149e..b2084157e4cd 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -765,6 +765,12 @@ void libxl__ev_slowlock_unlock(libxl__gc *gc, 
libxl__ev_slowlock *lock)
 ev_slowlock_init_internal(lock, lock->userdata_userid);
 }
 
+void libxl__ev_slowlock_dispose(libxl__gc *gc, libxl__ev_slowlock *lock)
+{
+libxl__ev_child_kill_deregister(lock->ao, &lock->child, SIGKILL);
+libxl__ev_slowlock_unlock(gc, lock);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a0f99252c39c..9b843b7d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -393,6 +393,8 @@ struct libxl__ev_child {
  *  libxl__ev_slowlock_lock: Idle -> Active
  *May call callback synchronously.
  *  libxl__ev_slowlock_unlock: LockAcquired/Idle -> Idle
+ *  libxl__ev_slowlock_dispose: Idle/Active/LockAcquired -> Idle
+ *The callback will not be called anymore.
  *  callback: When called: Active -> LockAcquired (on error: Idle)
  *The callback is only called once.
  */
@@ -411,6 +413,7 @@ struct libxl__ev_slowlock {
 _hidden void libxl__ev_devlock_init(libxl__ev_slowlock *);
 _hidden void libxl__ev_slowlock_lock(libxl__egc *, libxl__ev_slowlock *);
 _hidden void libxl__ev_slowlock_unlock(libxl__gc *, libxl__ev_slowlock *);
+_hidden void libxl__ev_slowlock_dispose(libxl__gc *, libxl__ev_slowlock *);
 
 /*
  * QMP asynchronous calls
-- 
Anthony PERARD


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

[Xen-devel] [XEN PATCH for-4.13 v2 0/6] Fix: libxl workaround, multiple connection to single QMP socket

[Anthony PERARD]

Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git 
br.fix-ev_qmp-multi-connect-v2

Hi,

QEMU's QMP socket doesn't allow multiple concurrent connection. Also, it
listen() on the socket with a `backlog' of only 1. On Linux at least, once that
backlog is filled connect() will return EAGAIN if the socket fd is
non-blocking. libxl may attempt many concurrent connect() attempt if for
example a guest is started with several PCI passthrough devices, and a
connect() failure lead to a failure to start the guest.

Since we can't change the listen()'s `backlog' that QEMU use, we need other
ways to workaround the issue. This patch series introduce a lock to acquire
before attempting to connect() to the QMP socket. Since the lock might be held
for to long, the series also introduce a way to cancel the acquisition of the
lock, this means killing the process that tries to get the lock.

See thread[1] for discussed alternative.
[1] https://lists.xenproject.org/archives/html/xen-devel/2019-10/msg01815.html

Cheers,

Anthony PERARD (6):
  libxl: Introduce libxl__ev_child_kill_deregister
  libxl: Move libxl__ev_devlock declaration
  libxl: Rename ev_devlock to ev_slowlock
  libxl: Introduce libxl__ev_slowlock_dispose
  libxl: libxl__ev_qmp_send now takes an egc
  libxl_qmp: Have a lock for QMP socket access

 tools/libxl/libxl_disk.c|  16 ++--
 tools/libxl/libxl_dm.c  |   8 +-
 tools/libxl/libxl_dom_save.c|   2 +-
 tools/libxl/libxl_dom_suspend.c |   2 +-
 tools/libxl/libxl_domain.c  |  18 ++---
 tools/libxl/libxl_event.c   |   6 +-
 tools/libxl/libxl_fork.c|  48 
 tools/libxl/libxl_internal.c|  41 +++---
 tools/libxl/libxl_internal.h| 130 +++-
 tools/libxl/libxl_pci.c |   8 +-
 tools/libxl/libxl_qmp.c | 119 -
 tools/libxl/libxl_usb.c |  28 ---
 12 files changed, 301 insertions(+), 125 deletions(-)

-- 
Anthony PERARD


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

[Xen-devel] [XEN PATCH for-4.13 v2 1/6] libxl: Introduce libxl__ev_child_kill_deregister

[Anthony PERARD]

Allow to deregister the callback associated with a child death event.

The death isn't immediate will need to be collected later, so the
ev_child machinery register its own callback.

libxl__ev_child_kill_deregister() might be called by an AO operation
that is finishing/cleaning up without a chance for libxl to be
notified of the child death (via SIGCHLD). So it is possible that the
application calls libxl_ctx_free() while there are still child around.
To avoid the application getting unexpected SIGCHLD, the libxl__ao
responsible for killing a child will have to wait until it has been
properly reaped.

Signed-off-by: Anthony PERARD 
---

Notes:
v2:
- Rename new fn to libxl__ev_child_kill_deregister
- Rework documentation of the new API and if ev_child
- Add debug log in libxl__ao_complete
- Always call libxl_report_child_exitstatus() in child callback.

 tools/libxl/libxl_event.c|  6 -
 tools/libxl/libxl_fork.c | 48 
 tools/libxl/libxl_internal.h | 15 ---
 3 files changed, 65 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 0370b6acdd1c..43155368de76 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -1878,6 +1878,9 @@ void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, 
int rc)
 ao->complete = 1;
 ao->rc = rc;
 LIBXL_LIST_REMOVE(ao, inprogress_entry);
+if (ao->outstanding_killed_child)
+LOG(DEBUG, "ao %p: .. but waiting for %d fork to exit",
+ao, ao->outstanding_killed_child);
 libxl__ao_complete_check_progress_reports(egc, ao);
 }
 
@@ -1891,7 +1894,8 @@ static bool ao_work_outstanding(libxl__ao *ao)
  * decrement progress_reports_outstanding, and call
  * libxl__ao_complete_check_progress_reports.
  */
-return !ao->complete || ao->progress_reports_outstanding;
+return !ao->complete || ao->progress_reports_outstanding
+|| ao->outstanding_killed_child;
 }
 
 void libxl__ao_complete_check_progress_reports(libxl__egc *egc, libxl__ao *ao)
diff --git a/tools/libxl/libxl_fork.c b/tools/libxl/libxl_fork.c
index eea3d5d4e68e..0f1b6b518c5c 100644
--- a/tools/libxl/libxl_fork.c
+++ b/tools/libxl/libxl_fork.c
@@ -678,6 +678,54 @@ int libxl__ev_child_xenstore_reopen(libxl__gc *gc, const 
char *what) {
 return rc;
 }
 
+typedef struct ev_child_killed {
+libxl__ao *ao;
+libxl__ev_child ch;
+} ev_child_killed;
+static void deregistered_child_callback(libxl__egc *, libxl__ev_child *,
+pid_t, int status);
+
+void libxl__ev_child_kill_deregister(libxl__ao *ao, libxl__ev_child *ch,
+ int sig)
+{
+AO_GC;
+
+if (!libxl__ev_child_inuse(ch))
+return;
+
+pid_t pid = ch->pid;
+
+ev_child_killed *new_ch = GCNEW(new_ch);
+new_ch->ao = ao;
+new_ch->ch.pid = pid;
+new_ch->ch.callback = deregistered_child_callback;
+LIBXL_LIST_INSERT_HEAD(&CTX->children, &new_ch->ch, entry);
+ao->outstanding_killed_child++;
+
+LIBXL_LIST_REMOVE(ch, entry);
+ch->pid = -1;
+int r = kill(pid, sig);
+if (r)
+LOGED(ERROR, ao->domid,
+  "failed to kill child [%ld] with signal %d",
+ (unsigned long)pid, sig);
+}
+
+static void deregistered_child_callback(libxl__egc *egc,
+libxl__ev_child *ch,
+pid_t pid,
+int status)
+{
+ev_child_killed *ck = CONTAINER_OF(ch, *ck, ch);
+EGC_GC;
+
+libxl_report_child_exitstatus(CTX, XTL_ERROR,
+  "killed fork (dying as expected)",
+  pid, status);
+ck->ao->outstanding_killed_child--;
+libxl__ao_complete_check_progress_reports(egc, ck->ao);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 6a614658c25d..4e433e110664 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -730,6 +730,7 @@ struct libxl__ao {
 libxl__poller *poller;
 uint32_t domid;
 LIBXL_TAILQ_ENTRY(libxl__ao) entry_for_callback;
+int outstanding_killed_child;
 };
 
 #define LIBXL_INIT_GC(gc,ctx) do{   \
@@ -1155,9 +1156,14 @@ _hidden int libxl__ctx_evtchn_init(libxl__gc *gc); /* 
for libxl_ctx_alloc */
  * The parent may signal the child but it must not reap it.  That will
  * be done by the event machinery.
  *
- * It is not possible to "deregister" the child death event source.
- * It will generate exactly one event callback; until then the childw
- * is Active and may not be reused.
+ * The child death event will generate exactly one event callback; until
+ * then the childw is Active and may not be reused.
+ *
+ * libxl__ev_child_kill_deregister: Active -> Idle
+ *   This will transfer ownership of the child process death event from
+ *

[Xen-devel] [XEN PATCH for-4.13 v2 3/6] libxl: Rename ev_devlock to ev_slowlock

[Anthony PERARD]

We are going to introduce a different lock based on the same
implementation as the ev_devlock but with a different path. The
different slowlock will be differentiated by calling different _init()
functions.

So we rename libxl__ev_devlock to lib__ev_slowlock, but keep
libxl__ev_devlock_init().

Some log messages produced ev_slowlock are changed to print the
name of the lock file (userdata_userid).

Signed-off-by: Anthony PERARD 
---

Notes:
New patch in v2.
Instead of introducing many libxl__ev_qmplock*.

 tools/libxl/libxl_disk.c | 10 +-
 tools/libxl/libxl_domain.c   | 10 +-
 tools/libxl/libxl_internal.c | 30 +++---
 tools/libxl/libxl_internal.h | 33 +
 4 files changed, 46 insertions(+), 37 deletions(-)

diff --git a/tools/libxl/libxl_disk.c b/tools/libxl/libxl_disk.c
index 733ad284c866..77ae3a59bfb6 100644
--- a/tools/libxl/libxl_disk.c
+++ b/tools/libxl/libxl_disk.c
@@ -648,13 +648,13 @@ typedef struct {
 libxl_domid domid;
 libxl_device_disk *disk;
 libxl_device_disk disk_saved;
-libxl__ev_devlock qmp_lock;
+libxl__ev_slowlock qmp_lock;
 int dm_ver;
 libxl__ev_time time;
 libxl__ev_qmp qmp;
 } libxl__cdrom_insert_state;
 
-static void cdrom_insert_lock_acquired(libxl__egc *, libxl__ev_devlock *,
+static void cdrom_insert_lock_acquired(libxl__egc *, libxl__ev_slowlock *,
int rc);
 static void cdrom_insert_ejected(libxl__egc *egc, libxl__ev_qmp *,
  const libxl__json_object *, int rc);
@@ -746,13 +746,13 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, 
libxl_device_disk *disk,
 cdrom_insert_done(egc, cis, rc); /* must be last */
 } else {
 cis->qmp_lock.callback = cdrom_insert_lock_acquired;
-libxl__ev_devlock_lock(egc, &cis->qmp_lock); /* must be last */
+libxl__ev_slowlock_lock(egc, &cis->qmp_lock); /* must be last */
 }
 return AO_INPROGRESS;
 }
 
 static void cdrom_insert_lock_acquired(libxl__egc *egc,
-   libxl__ev_devlock *lock,
+   libxl__ev_slowlock *lock,
int rc)
 {
 libxl__cdrom_insert_state *cis = CONTAINER_OF(lock, *cis, qmp_lock);
@@ -1052,7 +1052,7 @@ static void cdrom_insert_done(libxl__egc *egc,
 libxl__ev_time_deregister(gc, &cis->time);
 libxl__ev_qmp_dispose(gc, &cis->qmp);
 if (cis->qmp.payload_fd >= 0) close(cis->qmp.payload_fd);
-libxl__ev_devlock_unlock(gc, &cis->qmp_lock);
+libxl__ev_slowlock_unlock(gc, &cis->qmp_lock);
 libxl_device_disk_dispose(&cis->disk_saved);
 libxl__ao_complete(egc, cis->ao, rc);
 }
diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index 9d0eb5aed11d..84ebfcceb83e 100644
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -1874,12 +1874,12 @@ typedef struct {
 libxl__ev_qmp qmp;
 libxl__ev_time timeout;
 libxl_domain_config *d_config; /* user pointer */
-libxl__ev_devlock devlock;
+libxl__ev_slowlock devlock;
 libxl_bitmap qemuu_cpus;
 } retrieve_domain_configuration_state;
 
 static void retrieve_domain_configuration_lock_acquired(
-libxl__egc *egc, libxl__ev_devlock *, int rc);
+libxl__egc *egc, libxl__ev_slowlock *, int rc);
 static void retrieve_domain_configuration_cpu_queried(
 libxl__egc *egc, libxl__ev_qmp *qmp,
 const libxl__json_object *response, int rc);
@@ -1907,12 +1907,12 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, 
uint32_t domid,
 rdcs->devlock.ao = ao;
 rdcs->devlock.domid = domid;
 rdcs->devlock.callback = retrieve_domain_configuration_lock_acquired;
-libxl__ev_devlock_lock(egc, &rdcs->devlock);
+libxl__ev_slowlock_lock(egc, &rdcs->devlock);
 return AO_INPROGRESS;
 }
 
 static void retrieve_domain_configuration_lock_acquired(
-libxl__egc *egc, libxl__ev_devlock *devlock, int rc)
+libxl__egc *egc, libxl__ev_slowlock *devlock, int rc)
 {
 retrieve_domain_configuration_state *rdcs =
 CONTAINER_OF(devlock, *rdcs, devlock);
@@ -2202,7 +2202,7 @@ static void retrieve_domain_configuration_end(libxl__egc 
*egc,
 }
 
 out:
-libxl__ev_devlock_unlock(gc, &rdcs->devlock);
+libxl__ev_slowlock_unlock(gc, &rdcs->devlock);
 if (lock) libxl__unlock_domain_userdata(lock);
 libxl_bitmap_dispose(&rdcs->qemuu_cpus);
 libxl__ev_qmp_dispose(gc, &rdcs->qmp);
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 0750b69cba61..9520ac36149e 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -575,25 +575,32 @@ void libxl__update_domain_configuration(libxl__gc *gc,
 dst->b_info.video_memkb = src->b_info.video_memkb;
 }
 
-void libxl__ev_devlock_init(libxl__ev_devlock *lock)
+static void ev_slowlock_init_internal(libxl__ev_slowlock *lock,
+  

[Xen-devel] [XEN PATCH for-4.13 v2 2/6] libxl: Move libxl__ev_devlock declaration

[Anthony PERARD]

We are going to want to include libxl__ev_devlock into libxl__ev_qmp.

No functional changes.

Signed-off-by: Anthony PERARD 
---

Notes:
New patch in v2:
Move of the struct was done in "libxl_qmp: Have a lock for QMP
socket access" before.

 tools/libxl/libxl_internal.h | 96 ++--
 1 file changed, 48 insertions(+), 48 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4e433e110664..69d572c1866a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -363,6 +363,54 @@ struct libxl__ev_child {
 LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
 };
 
+/*
+ * Lock for device hotplug, qmp_lock.
+ *
+ * libxl__ev_devlock implement a lock that is outside of CTX_LOCK in the
+ * lock hierarchy. It can be used when one want to make QMP calls to QEMU,
+ * which may take a significant amount time.
+ * It is to be acquired by an ao event callback.
+ *
+ * It is to be acquired when adding/removing devices or making changes
+ * to them when this is a slow operation and json_lock isn't appropriate.
+ *
+ * Possible states of libxl__ev_devlock:
+ *   Undefined
+ *Might contain anything.
+ *  Idle
+ *Struct contents are defined enough to pass to any
+ *libxl__ev_devlock_* function.
+ *The struct does not contain references to any allocated private
+ *resources so can be thrown away.
+ *  Active
+ *Waiting to get a lock.
+ *Needs to wait until the callback is called.
+ *  LockAcquired
+ *libxl__ev_devlock_unlock will need to be called to release the lock
+ *and the resources of libxl__ev_devlock.
+ *
+ *  libxl__ev_devlock_init: Undefined/Idle -> Idle
+ *  libxl__ev_devlock_lock: Idle -> Active
+ *May call callback synchronously.
+ *  libxl__ev_devlock_unlock: LockAcquired/Idle -> Idle
+ *  callback: When called: Active -> LockAcquired (on error: Idle)
+ *The callback is only called once.
+ */
+struct libxl__ev_devlock {
+/* filled by user */
+libxl__ao *ao;
+libxl_domid domid;
+void (*callback)(libxl__egc *, libxl__ev_devlock *, int rc);
+/* private to libxl__ev_devlock* */
+libxl__ev_child child;
+char *path; /* path of the lock file itself */
+int fd;
+bool held;
+};
+_hidden void libxl__ev_devlock_init(libxl__ev_devlock *);
+_hidden void libxl__ev_devlock_lock(libxl__egc *, libxl__ev_devlock *);
+_hidden void libxl__ev_devlock_unlock(libxl__gc *, libxl__ev_devlock *);
+
 /*
  * QMP asynchronous calls
  *
@@ -4689,54 +4737,6 @@ static inline const char *libxl__qemu_qmp_path(libxl__gc 
*gc, int domid)
 return GCSPRINTF("%s/qmp-libxl-%d", libxl__run_dir_path(), domid);
 }
 
-/*
- * Lock for device hotplug, qmp_lock.
- *
- * libxl__ev_devlock implement a lock that is outside of CTX_LOCK in the
- * lock hierarchy. It can be used when one want to make QMP calls to QEMU,
- * which may take a significant amount time.
- * It is to be acquired by an ao event callback.
- *
- * It is to be acquired when adding/removing devices or making changes
- * to them when this is a slow operation and json_lock isn't appropriate.
- *
- * Possible states of libxl__ev_devlock:
- *   Undefined
- *Might contain anything.
- *  Idle
- *Struct contents are defined enough to pass to any
- *libxl__ev_devlock_* function.
- *The struct does not contain references to any allocated private
- *resources so can be thrown away.
- *  Active
- *Waiting to get a lock.
- *Needs to wait until the callback is called.
- *  LockAcquired
- *libxl__ev_devlock_unlock will need to be called to release the lock
- *and the resources of libxl__ev_devlock.
- *
- *  libxl__ev_devlock_init: Undefined/Idle -> Idle
- *  libxl__ev_devlock_lock: Idle -> Active
- *May call callback synchronously.
- *  libxl__ev_devlock_unlock: LockAcquired/Idle -> Idle
- *  callback: When called: Active -> LockAcquired (on error: Idle)
- *The callback is only called once.
- */
-struct libxl__ev_devlock {
-/* filled by user */
-libxl__ao *ao;
-libxl_domid domid;
-void (*callback)(libxl__egc *, libxl__ev_devlock *, int rc);
-/* private to libxl__ev_devlock* */
-libxl__ev_child child;
-char *path; /* path of the lock file itself */
-int fd;
-bool held;
-};
-_hidden void libxl__ev_devlock_init(libxl__ev_devlock *);
-_hidden void libxl__ev_devlock_lock(libxl__egc *, libxl__ev_devlock *);
-_hidden void libxl__ev_devlock_unlock(libxl__gc *, libxl__ev_devlock *);
-
 /* Send control commands over xenstore and wait for an Ack. */
 _hidden int libxl__domain_pvcontrol(libxl__egc *egc,
 libxl__xswait_state *pvcontrol,
-- 
Anthony PERARD


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

[Xen-devel] [XEN PATCH for-4.13 v2 5/6] libxl: libxl__ev_qmp_send now takes an egc

[Anthony PERARD]

No functionnal changes.

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---
 tools/libxl/libxl_disk.c|  6 +++---
 tools/libxl/libxl_dm.c  |  8 
 tools/libxl/libxl_dom_save.c|  2 +-
 tools/libxl/libxl_dom_suspend.c |  2 +-
 tools/libxl/libxl_domain.c  |  8 
 tools/libxl/libxl_internal.h|  2 +-
 tools/libxl/libxl_pci.c |  8 
 tools/libxl/libxl_qmp.c | 10 +-
 tools/libxl/libxl_usb.c | 28 
 9 files changed, 39 insertions(+), 35 deletions(-)

diff --git a/tools/libxl/libxl_disk.c b/tools/libxl/libxl_disk.c
index 77ae3a59bfb6..64a66914240a 100644
--- a/tools/libxl/libxl_disk.c
+++ b/tools/libxl/libxl_disk.c
@@ -776,7 +776,7 @@ static void cdrom_insert_lock_acquired(libxl__egc *egc,
 
 QMP_PARAMETERS_SPRINTF(&args, "device", "ide-%i", devid);
 cis->qmp.callback = cdrom_insert_ejected;
-rc = libxl__ev_qmp_send(gc, &cis->qmp, "eject", args);
+rc = libxl__ev_qmp_send(egc, &cis->qmp, "eject", args);
 if (rc) goto out;
 } else {
 cdrom_insert_ejected(egc, &cis->qmp, NULL, 0); /* must be last */
@@ -884,7 +884,7 @@ static void cdrom_insert_ejected(libxl__egc *egc,
libxl_disk_format_to_string(disk->format),
disk->pdev_path);
 qmp->callback = cdrom_insert_addfd_cb;
-rc = libxl__ev_qmp_send(gc, qmp, "add-fd", args);
+rc = libxl__ev_qmp_send(egc, qmp, "add-fd", args);
 if (rc) goto out;
 has_callback = true;
 } else {
@@ -938,7 +938,7 @@ static void cdrom_insert_addfd_cb(libxl__egc *egc,
 libxl__qmp_param_add_string(gc, &args, "arg",
 libxl__qemu_disk_format_string(disk->format));
 qmp->callback = cdrom_insert_inserted;
-rc = libxl__ev_qmp_send(gc, qmp, "change", args);
+rc = libxl__ev_qmp_send(egc, qmp, "change", args);
 out:
 if (rc)
 cdrom_insert_done(egc, cis, rc); /* must be last */
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 7e52f0973172..ebfe98ebc237 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2649,7 +2649,7 @@ void libxl__spawn_local_dm(libxl__egc *egc, 
libxl__dm_spawn_state *dmss)
 dmss->qmp.callback = device_model_qmp_cb;
 dmss->qmp.domid = domid;
 dmss->qmp.payload_fd = -1;
-rc = libxl__ev_qmp_send(gc, &dmss->qmp, "query-status", NULL);
+rc = libxl__ev_qmp_send(egc, &dmss->qmp, "query-status", NULL);
 if (rc) goto out_close;
 }
 
@@ -2807,7 +2807,7 @@ static void device_model_spawn_outcome(libxl__egc *egc,
 dmss->qmp.domid = dmss->guest_domid;
 dmss->qmp.payload_fd = -1;
 dmss->qmp.callback = device_model_postconfig_chardev;
-rc = libxl__ev_qmp_send(gc, &dmss->qmp, "query-chardev", NULL);
+rc = libxl__ev_qmp_send(egc, &dmss->qmp, "query-chardev", NULL);
 if (rc) goto out;
 return;
 }
@@ -2879,7 +2879,7 @@ static void device_model_postconfig_chardev(libxl__egc 
*egc,
 }
 
 qmp->callback = device_model_postconfig_vnc;
-rc = libxl__ev_qmp_send(gc, qmp, "query-vnc", NULL);
+rc = libxl__ev_qmp_send(egc, qmp, "query-vnc", NULL);
 if (rc) goto out;
 return;
 
@@ -2939,7 +2939,7 @@ static void device_model_postconfig_vnc(libxl__egc *egc,
 if (vnc && vnc->passwd) {
 qmp->callback = device_model_postconfig_vnc_passwd;
 libxl__qmp_param_add_string(gc, &args, "password", vnc->passwd);
-rc = libxl__ev_qmp_send(gc, qmp, "change-vnc-password", args);
+rc = libxl__ev_qmp_send(egc, qmp, "change-vnc-password", args);
 if (rc) goto out;
 return;
 }
diff --git a/tools/libxl/libxl_dom_save.c b/tools/libxl/libxl_dom_save.c
index e70aa1585976..65610e6055a7 100644
--- a/tools/libxl/libxl_dom_save.c
+++ b/tools/libxl/libxl_dom_save.c
@@ -226,7 +226,7 @@ static void domain_suspend_switch_qemu_xen_logdirty
 qmp->payload_fd = -1;
 qmp->callback = switch_qemu_xen_logdirty_done;
 libxl__qmp_param_add_bool(gc, &args, "enable", enable);
-rc = libxl__ev_qmp_send(gc, qmp, "xen-set-global-dirty-log", args);
+rc = libxl__ev_qmp_send(egc, qmp, "xen-set-global-dirty-log", args);
 if (rc) goto out;
 
 return;
diff --git a/tools/libxl/libxl_dom_suspend.c b/tools/libxl/libxl_dom_suspend.c
index 248dbc33e384..940ac334f4b1 100644
--- a/tools/libxl/libxl_dom_suspend.c
+++ b/tools/libxl/libxl_dom_suspend.c
@@ -545,7 +545,7 @@ void libxl__dm_resume(libxl__egc *egc,
 qmp->domid = domid;
 qmp->callback = dm_resume_qmp_done;
 qmp->payload_fd = -1;
-rc = libxl__ev_qmp_send(gc, qmp, "cont", NULL);
+rc = libxl__ev_qmp_send(egc, qmp, "cont", NULL);
 if (rc) goto out;
 break;
 default:
diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index 84ebfcceb83e..723ad3bf8edb 100644
--- a/tools/libxl/libxl_domain.c
+++ b/to

[Xen-devel] [ovmf test] 143348: all pass - PUSHED

[osstest service owner]

flight 143348 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143348/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 6f3ac73cd3792c7eeccb4533e545270d640bef4c
baseline version:
 ovmf 4976a776b283021c252be794e90947732b6f8a92

Last test of basis   143294  2019-10-28 19:11:36 Z1 days
Testing same since   143348  2019-10-29 15:24:00 Z1 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Julien Grall 
  Siyuan Fu 
  Siyuan, Fu 

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-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-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/osstest/ovmf.git
   4976a776b2..6f3ac73cd3  6f3ac73cd3792c7eeccb4533e545270d640bef4c -> 
xen-tested-master

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

Re: [Xen-devel] Xen >4.10 bricks onboard NIC of Dell Optiplex 7060

[Bell, Oren]

Running Xen Dom0-less leaves the NIC intact, so you're correct in assessing 
that Xen by itself is not the cause.
As for running without the driver, I'm not sure that's possible (at least for 
my competency). It uses the Intel Base Gigabit driver that's built into the 
kernel.
And running the machine without using the NIC will still break it.

As for the IOMMU suggestion: we still got basic pinging to work, assuming an IP 
address was statically allocated, so I don't think IOMMU is a valid route for 
investigation, as any aberrations there should leave the NIC totally 
non-functional.

From: Jan Beulich 
Sent: Monday, October 28, 2019 4:03 AM
To: Bell, Oren 
Cc: xen-devel@lists.xenproject.org 
Subject: Re: [Xen-devel] Xen >4.10 bricks onboard NIC of Dell Optiplex 7060

On 27.10.2019 17:09,  Bell, Oren  wrote:
> I've encountered an issue where installing Xen >4.10 on a Dell Optiplex will 
> break the onboard NIC. This issue persists if the computer is booted without 
> Xen, after OS reinstall, and even if removing the SSD and HDD completely to 
> boot from a LiveUSB. The only way to fix the issue is to install Windows 10 
> on the machine. This appears to "fix" the firmware of the NIC. After 
> reinstalling Ubuntu, the NIC continues to work (until Xen is installed again).
>
> This bug was confirmed with both Xen 4.10 and 4.12 installed on Ubuntu 18.04.
>
> If this is a known issue, is there some "in-work patch" I can be pointed to?

This is a rather strange problem you're facing - Xen itself doesn't
do anything to NICs. Therefore I'm afraid some more experimenting
may be needed to somehow narrow where things go wrong. In particular
I'd be curious to understand whether it's indeed Xen that breaks
things, or whether e.g. other software misbehaves if run on top of
Xen. As a first step, could you boot
- Xen without a Dom0 kernel,
- Xen with a Dom0 kernel, but without a driver for the NIC,
- Xen with a Dom0 kernel and with a driver for the NIC, but without
  actually configuring/using the NIC?
Could you further check whether Xen using the presumably present
IOMMU matters? (Providing maximum verbosity hypervisor and kernel
logs would of course also help, in particular e.g. to know whether
there is an IOMMU in the system, and also to see whether any
anomalies get logged.)

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

[Xen-devel] [linux-4.9 test] 143328: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow2   19 guest-start/debian.repeat fail REGR. vs. 142947
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 142947
 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 142947
 test-amd64-i386-xl-raw  19 guest-start/debian.repeat fail REGR. vs. 142947
 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 142947

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds 16 guest-localmigrate   fail  like 142893
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 142947
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 142947
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142947
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 142947
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142947
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail 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-xl-pvhv2-amd 12 guest-start  fail  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-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  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-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  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-vhd 12 migrate-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-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  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-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail 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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-check

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail REGR. vs. 142994

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 142994
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142994
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142994
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 142994
 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  c1ab7d7ed5306641784a9ed8972db5151a49a1a1
baseline version:
 seabios  120996f147131eca8af90e30c900bc14bc824d9f

Last test of basis   142994  2019-10-21 07:08:49 Z9 days
Failing since143281  2019-10-28 14:38:51 Z2 days2 attempts
Testing same since   143330  2019-10-29 09:05:54 Z1 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Kevin O'Connor 

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-i386-xsm pass
 test-amd64-i386-xl-qemuu-debianhvm-i386-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-dmrestrict-amd64-dmrestrictpass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 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
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  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 c1ab7d7ed5306641784a9ed8972db5151a49a1a1
Author: Kevin O'Connor 
Date:   Mon Oct 28 11:18:32 2019 -0400

docs: Note release date for v1.12.1

Signed-off-by: Kevin O'Connor 

commit 00df082921e138af39a9d309ab7d969bc036b0b5
Author: Kevin O'Connor 
Date:   Mon Oct 21 11:27:39 2019 -0400

docs: Add developer-certificate-of-origin

Update the documentation to be explicit about the signed-off-by
convention.

Signed-off-by: Kevin O'Connor 

commit 51eb916e120c49dead28ccac7079624243d922cd
Author: Gerd Hoffmann 
Date:   Wed Oct 23 07:50:39 2019 +0200

cp437: add license to cp437.c

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Gerd Hoffmann 

commit 0c480648e3beb6828da8c7d

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  f20237784839c65f2b6ea0bfad1c472d0b101d3e
baseline version:
 xtf  9060b0d1d4a32e7a06b5ea5c7093a042fc536580

Last test of basis   139875  2019-08-09 18:39:54 Z   82 days
Testing same since   143358  2019-10-29 18:09:43 Z1 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
   9060b0d..f202377  f20237784839c65f2b6ea0bfad1c472d0b101d3e -> 
xen-tested-master

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

Re: [Xen-devel] Xen-unstable: AMD-Vi: update_paging_mode Try to access pdev_list without aquiring pcidevs_lock.

[Sander Eikelenboom]

On 30/10/2019 16:48, Jan Beulich wrote:
> On 28.10.2019 11:32, Sander Eikelenboom wrote:
>> While testing the latest xen-unstable and starting an HVM guest with 
>> pci-passtrough on my AMD machine,
>> my eye catched the following messages in xl dmesg I haven't seen before:
>>
>> (XEN) [2019-10-28 10:23:16.372] AMD-Vi: update_paging_mode Try to access 
>> pdev_list without aquiring pcidevs_lock.
> 
> Unfortunately this sits on the map/unmap path, and hence the
> violator is far up one of the many call chains. Therefore I'd
> like to ask that you rebuild and retry with the debugging
> patch below. In case you observe multiple different call
> trees, post them all please.
> 
> Jan

Hi Jan,

Call trace seems to be the same in all cases.

--
Sander


(XEN) [2019-10-30 22:07:05.748] AMD-Vi: update_paging_mode Try to access 
pdev_list without aquiring pcidevs_lock.
(XEN) [2019-10-30 22:07:05.748] [ Xen-4.13.0-rc  x86_64  debug=y   Not 
tainted ]
(XEN) [2019-10-30 22:07:05.748] CPU:1
(XEN) [2019-10-30 22:07:05.748] RIP:e008:[] 
iommu_map.c#update_paging_mode+0x1f2/0x3eb
(XEN) [2019-10-30 22:07:05.748] RFLAGS: 00010286   CONTEXT: hypervisor 
(d0v2)
(XEN) [2019-10-30 22:07:05.748] rax: 830523f9   rbx: 82e004905f00   
rcx: 
(XEN) [2019-10-30 22:07:05.748] rdx: 0001   rsi: 000a   
rdi: 82d0804a0698
(XEN) [2019-10-30 22:07:05.748] rbp: 830523f9f848   rsp: 830523f9f808   
r8:  8305320a
(XEN) [2019-10-30 22:07:05.748] r9:  0038   r10: 0002   
r11: 000a
(XEN) [2019-10-30 22:07:05.748] r12: 82e004905f00   r13: 0003   
r14: 0003
(XEN) [2019-10-30 22:07:05.748] r15: 83041fb83000   cr0: 80050033   
cr4: 06e0
(XEN) [2019-10-30 22:07:05.748] cr3: 00040a58d000   cr2: 8880604835a0
(XEN) [2019-10-30 22:07:05.748] fsb: 7f4b8f899bc0   gsb: 88807d48   
gss: 
(XEN) [2019-10-30 22:07:05.748] ds:    es:    fs:    gs:    ss: 
e010   cs: e008
(XEN) [2019-10-30 22:07:05.748] Xen code around  
(iommu_map.c#update_paging_mode+0x1f2/0x3eb):
(XEN) [2019-10-30 22:07:05.748]  3d 3b 7b 22 00 00 75 07 <0f> 0b e9 c2 01 00 00 
48 8d 35 1a ce 13 00 48 8d
(XEN) [2019-10-30 22:07:05.748] Xen stack trace from rsp=830523f9f808:
(XEN) [2019-10-30 22:07:05.748]82e00a6bc6e0 82e00a6bc6e0 
83041fb83000 83041fb83000
(XEN) [2019-10-30 22:07:05.748]83041fb83148 000feff8 
83041fb83150 830523f9f93c
(XEN) [2019-10-30 22:07:05.748]830523f9f8c8 82d080265ded 
000380240580 002482f9
(XEN) [2019-10-30 22:07:05.748]  
 
(XEN) [2019-10-30 22:07:05.748]  
 
(XEN) [2019-10-30 22:07:05.748]83041fb83000 000feff8 
000feff8 002482f9
(XEN) [2019-10-30 22:07:05.748]830523f9f928 82d0802583b6 
000feff8 0001
(XEN) [2019-10-30 22:07:05.748]0003802405da 002482f9 
830523f9f93c 0003
(XEN) [2019-10-30 22:07:05.748]83041fb83000 000feff8 
 
(XEN) [2019-10-30 22:07:05.748]830523f9f960 82d0802586fb 
48834780 0003
(XEN) [2019-10-30 22:07:05.748] 830248834780 
000feff8 830523f9f9f8
(XEN) [2019-10-30 22:07:05.748]82d08034a4a6 8038a845 
 820040024fc0
(XEN) [2019-10-30 22:07:05.748]83041fb83000 002482f9 
 8002484b5367
(XEN) [2019-10-30 22:07:05.748]82004002d5a0 8002484b5367 
 
(XEN) [2019-10-30 22:07:05.748]820040024000  
002482f9 000feff8
(XEN) [2019-10-30 22:07:05.748]0001 830248834780 
830523f9fa50 82d080342e13
(XEN) [2019-10-30 22:07:05.748] 0007 
83041fb83000 0023
(XEN) [2019-10-30 22:07:05.748]002482fa 830248834780 
 002482f9
(XEN) [2019-10-30 22:07:05.748]000feff8 830523f9fac8 
82d080343c52 23f9fa78
(XEN) [2019-10-30 22:07:05.748]0001 002482f9 
000feff8 830523f9fa98
(XEN) [2019-10-30 22:07:05.748] Xen call trace:
(XEN) [2019-10-30 22:07:05.748][] R 
iommu_map.c#update_paging_mode+0x1f2/0x3eb
(XEN) [2019-10-30 22:07:05.748][] F 
amd_iommu_map_page+0x72/0x1c2
(XEN) [2019-10-30 22:07:05.748][] F iommu_map+0x98/0x17e
(XEN) [2019-10-30 22:07:05.748][] F 
iommu_legacy_map+0x28/0x73
(XEN) [2019-10-30 22:07:05.748][] F 
p2m-pt.c#p2m_pt_set_entry+0x4d3/0x844
(XEN) [2019-10-30 22:07:05.748][] F 
p2m_set_entry+0x91/0x128
(XEN) [2019-10-30 22:07:05.748][] F 
guest_physmap_add_entry+0x39f/0x5a3
(XEN) [

Re: [Xen-devel] [XEN PATCH for-4.13 v2 0/6] Fix: libxl workaround, multiple connection to single QMP socket

[Sander Eikelenboom]

On 30/10/2019 19:06, Anthony PERARD wrote:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git 
> br.fix-ev_qmp-multi-connect-v2
> 
> Hi,
> 
> QEMU's QMP socket doesn't allow multiple concurrent connection. Also, it
> listen() on the socket with a `backlog' of only 1. On Linux at least, once 
> that
> backlog is filled connect() will return EAGAIN if the socket fd is
> non-blocking. libxl may attempt many concurrent connect() attempt if for
> example a guest is started with several PCI passthrough devices, and a
> connect() failure lead to a failure to start the guest.
> 
> Since we can't change the listen()'s `backlog' that QEMU use, we need other
> ways to workaround the issue. This patch series introduce a lock to acquire
> before attempting to connect() to the QMP socket. Since the lock might be held
> for to long, the series also introduce a way to cancel the acquisition of the
> lock, this means killing the process that tries to get the lock.
> 
> See thread[1] for discussed alternative.
> [1] https://lists.xenproject.org/archives/html/xen-devel/2019-10/msg01815.html
> 
> Cheers,
> 
> Anthony PERARD (6):

Hi Anthony,

Re-tested, especially the pci-pt part, still works for me.
Thanks again (and thanks for providing a git branch)

--
Sander

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

[Xen-devel] [linux-4.4 test] 143351: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvshim   18 guest-localmigrate/x10   fail REGR. vs. 139698
 test-amd64-amd64-qemuu-nested-amd 14 xen-boot/l1 fail REGR. vs. 139698
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
139698
 test-amd64-amd64-i386-pvgrub 11 guest-start  fail REGR. vs. 139698
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
REGR. vs. 139698
 test-amd64-amd64-xl-qcow2   19 guest-start/debian.repeat fail REGR. vs. 139698
 test-amd64-amd64-xl-qemut-debianhvm-amd64 18 guest-start/debianhvm.repeat fail 
REGR. vs. 139698
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 18 
guest-start/debianhvm.repeat fail REGR. vs. 139698
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 139698
 test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail 
REGR. vs. 139698
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 18 guest-start/debianhvm.repeat 
fail REGR. vs. 139698
 test-armhf-armhf-xl-arndale   8 host-ping-check-xen  fail REGR. vs. 139698
 test-amd64-i386-xl-raw  19 guest-start/debian.repeat fail REGR. vs. 139698
 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 139698
 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 139698

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   fail REGR. vs. 139698

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-arm64-arm64-xl-credit2   7 xen-boot fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle   7 xen-boot fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl   7 xen-boot fail   never pass
 test-arm64-arm64-examine  8 reboot   fail   never pass
 test-arm64-arm64-xl-xsm   7 xen-boot fail   never pass
 test-arm64-arm64-libvirt-xsm  7 xen-boot fail   never pass
 test-arm64-arm64-xl-credit1   7 xen-boot fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx  7 xen-boot fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop 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-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail 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-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  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-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail 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-checkfai

[Xen-devel] [libvirt bisection] complete test-amd64-i386-libvirt-pair

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt-pair
testid guest-start/debian

Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  18981877d2e20390a79d068861a24e716f8ee422
  Bug not present: c8007fdc5d2ce43fec2753cda60fb4963f55abd5
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/143429/


  commit 18981877d2e20390a79d068861a24e716f8ee422
  Author: Pavel Hrdina 
  Date:   Wed Oct 9 14:09:38 2019 +0200
  
  m4: virt-driver-libxl: remove Fedora 28 check
  
  Signed-off-by: Pavel Hrdina 
  Reviewed-by: Ján Tomko 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/libvirt/test-amd64-i386-libvirt-pair.guest-start--debian.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/libvirt/test-amd64-i386-libvirt-pair.guest-start--debian
 --summary-out=tmp/143429.bisection-summary --basis-template=143023 
--blessings=real,real-bisect libvirt test-amd64-i386-libvirt-pair 
guest-start/debian
Searching for failure / basis pass:
 143316 fail [dst_host=pinot1,src_host=pinot0] / 143051 
[dst_host=chardonnay1,src_host=chardonnay0] 143023 
[dst_host=debina1,src_host=debina0] 142949 [dst_host=fiano1,src_host=fiano0] 
142904 [dst_host=huxelrebe0,src_host=huxelrebe1] 142862 
[dst_host=chardonnay0,src_host=chardonnay1] 142840 
[dst_host=italia1,src_host=italia0] 142798 [dst_host=albana0,src_host=albana1] 
142761 [dst_host=baroque1,src_host=baroque0] 142644 
[dst_host=albana1,src_host=albana0] 142584 [dst_host=pinot0,src_host=pinot1] 1\
 42535 [dst_host=fiano0,src_host=fiano1] 142476 ok.
Failure / basis pass flights: 143316 / 142476
(tree with no url: minios)
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest bf0e7bdeeb790bc6ba5732623be0d9ff26a5961a 
1f6fb368c04919243e2c70f2aa514a5f88e95309 
6280c94f306df6a20bbc100ba15a5a81af0366e6 
b98aebd298246df37b472c52a2ee1023256d02e3 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
9e639c1cb6abd5ffed0f9017de26f93d2ee99eac 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
933ebad2470a169504799a1d95b8e410bd9847ef 
120996f147131eca8af90e30c900bc14bc824d9f 
518c935fac4d30b3ec35d4b6add82b17b7d7aca3
Basis pass 412cc0f4038875aa1b0a3c176c309a7e777e9c3f 
1f6fb368c04919243e2c70f2aa514a5f88e95309 
6280c94f306df6a20bbc100ba15a5a81af0366e6 
42327896f194f256e5a361e0069985bc8d209b42 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
410c4d00d9f7e369d1ce183e9e8de98cb59c4d20 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
933ebad2470a169504799a1d95b8e410bd9847ef 
43f5df79dad6738d52ea79d072de2b56eb96a91f 
f93abf0315efef861270c25d83c8047fd6a54ec4
Generating revisions with ./adhoc-revtuple-generator  
git://libvirt.org/libvirt.git#412cc0f4038875aa1b0a3c176c309a7e777e9c3f-bf0e7bdeeb790bc6ba5732623be0d9ff26a5961a
 
https://git.savannah.gnu.org/git/gnulib.git/#1f6fb368c04919243e2c70f2aa514a5f88e95309-1f6fb368c04919243e2c70f2aa514a5f88e95309
 
https://gitlab.com/keycodemap/keycodemapdb.git#6280c94f306df6a20bbc100ba15a5a81af0366e6-6280c94f306df6a20bbc100ba15a5a81af0366e6
 git://xenbits.xen.org/linux-pvops.git#42327896f194f256e5a361e0069985bc8d209b42\
 -b98aebd298246df37b472c52a2ee1023256d02e3 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/osstest/ovmf.git#410c4d00d9f7e369d1ce183e9e8de98cb59c4d20-9e639c1cb6abd5ffed0f9017de26f93d2ee99eac
 
git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798
 git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e410bd9847ef-9\
 33ebad2470a169504799a1d95b8e410bd9847ef 
git://xenbits.xen.org/osstest/seabios.git#43f5df79dad6738d52ea79d072de2b56eb96a91f-120996f147131ec

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 142750
 test-amd64-amd64-pair21 guest-start/debian   fail REGR. vs. 142750
 test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 142750
 test-amd64-i386-xl-shadow   20 guest-start/debian.repeat fail REGR. vs. 142750
 test-amd64-i386-libvirt-xsm 18 guest-start/debian.repeat fail REGR. vs. 142750
 test-arm64-arm64-xl 16 guest-start/debian.repeat fail REGR. vs. 142750
 test-armhf-armhf-xl-arndale 16 guest-start/debian.repeat fail REGR. vs. 142750
 test-amd64-amd64-xl-qcow2   19 guest-start/debian.repeat fail REGR. vs. 142750
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 142750
 test-amd64-i386-xl-raw  19 guest-start/debian.repeat fail REGR. vs. 142750
 test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail REGR. vs. 
142750
 test-armhf-armhf-xl-credit1 16 guest-start/debian.repeat fail REGR. vs. 142750
 test-armhf-armhf-xl 16 guest-start/debian.repeat fail REGR. vs. 142750
 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 142750
 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 142750

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 142750

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 142750
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 142750
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142750
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 142750
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 142750
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 142750
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142750
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 142750
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 142750
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 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-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-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-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 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-amd64-libvirt-vhd 12 migrate-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-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  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 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-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-ar