RE: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately

[Paul Durrant]

> -Original Message-
> From: Jan Beulich 
> Sent: 03 June 2020 11:03
> To: Igor Druzhinin 
> Cc: xen-devel@lists.xenproject.org; andrew.coop...@citrix.com; w...@xen.org; 
> roger@citrix.com;
> george.dun...@citrix.com; Paul Durrant 
> Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults 
> immediately
> 
> On 02.06.2020 18:56, Igor Druzhinin wrote:
> > A recalculation NPT fault doesn't always require additional handling
> > in hvm_hap_nested_page_fault(), moreover in general case if there is no
> > explicit handling done there - the fault is wrongly considered fatal.
> >
> > This covers a specific case of migration with vGPU assigned on AMD:
> > at a moment log-dirty is enabled globally, recalculation is requested
> > for the whole guest memory including directly mapped MMIO regions of vGPU
> > which causes a page fault being raised at the first access to those;
> > but due to MMIO P2M type not having any explicit handling in
> > hvm_hap_nested_page_fault() a domain is erroneously crashed with unhandled
> > SVM violation.
> >
> > Instead of trying to be opportunistic - use safer approach and handle
> > P2M recalculation in a separate NPT fault by attempting to retry after
> > making the necessary adjustments. This is aligned with Intel behavior
> > where there are separate VMEXITs for recalculation and EPT violations
> > (faults) and only faults are handled in hvm_hap_nested_page_fault().
> > Do it by also unifying do_recalc return code with Intel implementation
> > where returning 1 means P2M was actually changed.
> >
> > Since there was no case previously where p2m_pt_handle_deferred_changes()
> > could return a positive value - it's safe to replace ">= 0" with just "== 0"
> > in VMEXIT_NPF handler. finish_type_change() is also not affected by the
> > change as being able to deal with >0 return value of p2m->recalc from
> > EPT implementation.
> >
> > Reviewed-by: Roger Pau Monné 
> > Signed-off-by: Igor Druzhinin 
> 
> Reviewed-by: Jan Beulich 
> albeit preferably with ...
> 
> > @@ -448,12 +451,14 @@ static int do_recalc(struct p2m_domain *p2m, unsigned 
> > long gfn)
> >  clear_recalc(l1, e);
> >  err = p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1);
> >  ASSERT(!err);
> > +
> > +recalc_done = true;
> >  }
> >
> >   out:
> >  unmap_domain_page(table);
> >
> > -return err;
> > +return err ?: (recalc_done ? 1 : 0);
> 
> ... this shrunk to
> 
> return err ?: recalc_done;
> 
> (easily doable while committing).
> 
> Also Cc Paul.
> 

paging_log_dirty_enable() still fails global enable if has_arch_pdevs() is 
true, so presumably there's no desperate need for this to go in 4.14?

  Paul

> Jan

Re: Keystone Issue

[Julien Grall]

(+Bertrand and Stefano)

On 01/06/2020 18:38, CodeWiz2280 wrote:

Hi Julien,


Hi Dave,



As requested please see log below from the eval board booting dom0, some 
notes are as follows:


Thanks for the logs and the notes. They are useful to understand your issue.

1. The offset that gets applied to the 32-bit address to translate it 
to 36-bits is 0x7_8000_


Is this offset present in the Device-Tree?

2. Uboot has been setup to not change the address of the memory in the 
device tree prior to launching xen, otherwise it would 
automatically offset it and replace it with a 36-bit address and xen 
would immediately panic at the 36-bit address for a 32-bit processor.


What is the list of the memory banks Xen will see?

Xen is able to support 36-bit address, can you point to the panic() you 
are hitting?


3. The RAM starting address placed in the device tree is 0x8000_, 
which gets carved up by xen and replaced with 0xA000_ prior to 
booting dom0..  I had to put in test code to have the kernel offset the 
0xA000_ 32-bit starting address to the 36-bit address needed before 
the kernel will attempt to switch.  If it stays 32-bit then it will not 
switch over the address space.  Note that without xen in play uboot 
would normally replace the address in the device tree with the 36-bit one.


IIUC, in the case of Linux boot directly, the Device-Tree will not 
describe the low memory range. Is that correct?


4. The dom0 kernel will boot from xen if the early_paging_init switch 
step is skipped, and the low mem stays in 32-bitbut there is a 
problem with the peripherals so this is not an acceptable solution.


Can you details a bit more the problem with the peripherals?



It seems that either the kernel would need some API to tell xen that 
there is going to be a change in the memory its using prior to call 
early_paging_init(), 


From my understanding, the problem is very specific to the KeyStone. So 
I would rather avoid to introduce an hypercall specific to your 
platform. But...


or Xen would need to add the additional 36-bit 
addresses during the memory bank allocation stepbut recognize that 
they are not actually different physical memory but just aliased to a 
different address.


... I think it is possible to fix it entirely in Xen without any 
modification in the device-tree.


It is seems better that Xen treats the low memory region as "not usable" 
and only use the high memory region internally. When allocating a Dom0 
memory banks, it would need to ensure that there is a corresponding 
alias in low memory.


Xen will also need to do two mappings in the Dom0 stage-2 page-tables. 
The extra one is for the alias.


This approach will prevent to use hypercall buffer from low memory and 
therefore require your guest to support LPAE. Is it going to be an issue 
for you?


Cheers,

--
Julien Grall

Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately

[Igor Druzhinin]

On 03/06/2020 12:28, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich 
>> Sent: 03 June 2020 12:22
>> To: p...@xen.org
>> Cc: 'Igor Druzhinin' ; 
>> xen-devel@lists.xenproject.org;
>> andrew.coop...@citrix.com; w...@xen.org; roger@citrix.com; 
>> george.dun...@citrix.com
>> Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults 
>> immediately
>>
>> On 03.06.2020 12:26, Paul Durrant wrote:
 -Original Message-
 From: Jan Beulich 
 Sent: 03 June 2020 11:03
 To: Igor Druzhinin 
 Cc: xen-devel@lists.xenproject.org; andrew.coop...@citrix.com; 
 w...@xen.org; roger@citrix.com;
 george.dun...@citrix.com; Paul Durrant 
 Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults 
 immediately

 On 02.06.2020 18:56, Igor Druzhinin wrote:
> A recalculation NPT fault doesn't always require additional handling
> in hvm_hap_nested_page_fault(), moreover in general case if there is no
> explicit handling done there - the fault is wrongly considered fatal.
>
> This covers a specific case of migration with vGPU assigned on AMD:
> at a moment log-dirty is enabled globally, recalculation is requested
> for the whole guest memory including directly mapped MMIO regions of vGPU
> which causes a page fault being raised at the first access to those;
> but due to MMIO P2M type not having any explicit handling in
> hvm_hap_nested_page_fault() a domain is erroneously crashed with unhandled
> SVM violation.
>
> Instead of trying to be opportunistic - use safer approach and handle
> P2M recalculation in a separate NPT fault by attempting to retry after
> making the necessary adjustments. This is aligned with Intel behavior
> where there are separate VMEXITs for recalculation and EPT violations
> (faults) and only faults are handled in hvm_hap_nested_page_fault().
> Do it by also unifying do_recalc return code with Intel implementation
> where returning 1 means P2M was actually changed.
>
> Since there was no case previously where p2m_pt_handle_deferred_changes()
> could return a positive value - it's safe to replace ">= 0" with just "== 
> 0"
> in VMEXIT_NPF handler. finish_type_change() is also not affected by the
> change as being able to deal with >0 return value of p2m->recalc from
> EPT implementation.
>
> Reviewed-by: Roger Pau Monné 
> Signed-off-by: Igor Druzhinin 

 Reviewed-by: Jan Beulich 
 albeit preferably with ...

> @@ -448,12 +451,14 @@ static int do_recalc(struct p2m_domain *p2m, 
> unsigned long gfn)
>  clear_recalc(l1, e);
>  err = p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1);
>  ASSERT(!err);
> +
> +recalc_done = true;
>  }
>
>   out:
>  unmap_domain_page(table);
>
> -return err;
> +return err ?: (recalc_done ? 1 : 0);

 ... this shrunk to

 return err ?: recalc_done;

 (easily doable while committing).

 Also Cc Paul.

>>>
>>> paging_log_dirty_enable() still fails global enable if has_arch_pdevs()
>>> is true, so presumably there's no desperate need for this to go in 4.14?
>>
>> The MMIO case is just the particular situation here. Aiui the same issue
>> could potentially surface with other p2m types. Also given I'd consider
>> this a backporting candidate, while it may not be desperately needed for
>> the release, I think it deserves considering beyond the specific aspect
>> you mention.
>>
> 
> In which case I think the commit message probably ought to be rephrased, 
> since it appears to focus on a case that cannot currently happen.

This can happen without has_arch_pdevs() being true. It's enough to just
directly map some physical memory into a guest to get p2m_direct_mmio
type present in the page tables.

Igor

Re: Re [PATCH] x86/CET: Fix build following c/s 43b98e7190

[Andrew Cooper]

On 03/06/2020 10:50, Jan Beulich wrote:
> On 02.06.2020 19:15, Andrew Cooper wrote:
>> On 02/06/2020 15:21, Jan Beulich wrote:
 OSSTest reports:

   x86_64.S: Assembler messages:
   x86_64.S:57: Error: no such instruction: `setssbsy'
   /home/osstest/build.150510.build-amd64/xen/xen/Rules.mk:183: recipe for 
 target 'head.o' failed
   make[4]: Leaving directory 
 '/home/osstest/build.150510.build-amd64/xen/xen/arch/x86/boot'
   make[4]: *** [head.o] Error 1

 All use of CET instructions, even those inside alternative blocks, needs 
 to be
 behind CONFIG_XEN_SHSTK, as it indicates suitable toolchain support.

 Signed-off-by: Andrew Cooper 
>>> That's quite a bit of #ifdef-ary here. Simple (operand-less) insns
>>> like SETSSBSY could easily be made available via .byte directives.
>>> Would you be amenable to to ack-ing a patch to replace some of the
>>> #ifdef-s (at least the ones at the lstar, cstar, and sysenter
>>> entry points), after 4.14?
>> Yeah - that was a bit of a mess in the end.  (But given the
>> circumstances, and that I've got past form typo'ing the SETSSBSY opcode,
>> it probably was the right move even in hindsight).
>>
>> Reducing it to .byte should be fine so long as some form of /* setssbsy
>> */ comment appears.
> Sure.
>
>> One other option would be to introduce a SETSSBSY macro, but that hides
>> the alternative so is something I'd prefer to avoid.
> With this you mean you'd rather not see us go the CLAC/STAC route?
> I was instead thinking of a pure assembly macro named "setssbsy".
> In fact we could switch the CLAC/STAC ugliness to some such, if we
> end up being happy with the model.

The thing about the current STAC / CLAC is that, as written, they give
the impression of being unconditional.  This is poor in terms of code
clarity.

Furthermore, making them indistinguishable from the plain instructions
is definitely a no-go, because then we've got assembly source (again,
which appears unconditional) which doesn't match its disassembly (the
backing nops) - at least with the macros in upper case, it is obvious
that something is up, even if you have to searching for why.

If we went for pure assembly macros with an alt_ or maybe_ prefix, then
that would be reasonable.  It looks as close to regular instruction as
possible, but also makes it explicitly clear that it is conditional.

~Andrew

RE: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately

[Paul Durrant]

> -Original Message-
> From: Igor Druzhinin 
> Sent: 03 June 2020 12:45
> To: p...@xen.org; 'Jan Beulich' 
> Cc: xen-devel@lists.xenproject.org; andrew.coop...@citrix.com; w...@xen.org; 
> roger@citrix.com;
> george.dun...@citrix.com
> Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults 
> immediately
> 
> On 03/06/2020 12:28, Paul Durrant wrote:
> >> -Original Message-
> >> From: Jan Beulich 
> >> Sent: 03 June 2020 12:22
> >> To: p...@xen.org
> >> Cc: 'Igor Druzhinin' ; 
> >> xen-devel@lists.xenproject.org;
> >> andrew.coop...@citrix.com; w...@xen.org; roger@citrix.com; 
> >> george.dun...@citrix.com
> >> Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults 
> >> immediately
> >>
> >> On 03.06.2020 12:26, Paul Durrant wrote:
>  -Original Message-
>  From: Jan Beulich 
>  Sent: 03 June 2020 11:03
>  To: Igor Druzhinin 
>  Cc: xen-devel@lists.xenproject.org; andrew.coop...@citrix.com; 
>  w...@xen.org; roger@citrix.com;
>  george.dun...@citrix.com; Paul Durrant 
>  Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults 
>  immediately
> 
>  On 02.06.2020 18:56, Igor Druzhinin wrote:
> > A recalculation NPT fault doesn't always require additional handling
> > in hvm_hap_nested_page_fault(), moreover in general case if there is no
> > explicit handling done there - the fault is wrongly considered fatal.
> >
> > This covers a specific case of migration with vGPU assigned on AMD:
> > at a moment log-dirty is enabled globally, recalculation is requested
> > for the whole guest memory including directly mapped MMIO regions of 
> > vGPU
> > which causes a page fault being raised at the first access to those;
> > but due to MMIO P2M type not having any explicit handling in
> > hvm_hap_nested_page_fault() a domain is erroneously crashed with 
> > unhandled
> > SVM violation.
> >
> > Instead of trying to be opportunistic - use safer approach and handle
> > P2M recalculation in a separate NPT fault by attempting to retry after
> > making the necessary adjustments. This is aligned with Intel behavior
> > where there are separate VMEXITs for recalculation and EPT violations
> > (faults) and only faults are handled in hvm_hap_nested_page_fault().
> > Do it by also unifying do_recalc return code with Intel implementation
> > where returning 1 means P2M was actually changed.
> >
> > Since there was no case previously where 
> > p2m_pt_handle_deferred_changes()
> > could return a positive value - it's safe to replace ">= 0" with just 
> > "== 0"
> > in VMEXIT_NPF handler. finish_type_change() is also not affected by the
> > change as being able to deal with >0 return value of p2m->recalc from
> > EPT implementation.
> >
> > Reviewed-by: Roger Pau Monné 
> > Signed-off-by: Igor Druzhinin 
> 
>  Reviewed-by: Jan Beulich 
>  albeit preferably with ...
> 
> > @@ -448,12 +451,14 @@ static int do_recalc(struct p2m_domain *p2m, 
> > unsigned long gfn)
> >  clear_recalc(l1, e);
> >  err = p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1);
> >  ASSERT(!err);
> > +
> > +recalc_done = true;
> >  }
> >
> >   out:
> >  unmap_domain_page(table);
> >
> > -return err;
> > +return err ?: (recalc_done ? 1 : 0);
> 
>  ... this shrunk to
> 
>  return err ?: recalc_done;
> 
>  (easily doable while committing).
> 
>  Also Cc Paul.
> 
> >>>
> >>> paging_log_dirty_enable() still fails global enable if has_arch_pdevs()
> >>> is true, so presumably there's no desperate need for this to go in 4.14?
> >>
> >> The MMIO case is just the particular situation here. Aiui the same issue
> >> could potentially surface with other p2m types. Also given I'd consider
> >> this a backporting candidate, while it may not be desperately needed for
> >> the release, I think it deserves considering beyond the specific aspect
> >> you mention.
> >>
> >
> > In which case I think the commit message probably ought to be rephrased, 
> > since it appears to focus
> on a case that cannot currently happen.
> 
> This can happen without has_arch_pdevs() being true. It's enough to just
> directly map some physical memory into a guest to get p2m_direct_mmio
> type present in the page tables.

OK, that's fine, but when will that happen without pass-through? If we can have 
a commit message justifying the change based on what can actually happen now, 
then I would not be opposed to it going in 4.14.

  Paul

> 
> Igor

Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update)

[Pavel Hrdina]

On Tue, Jun 02, 2020 at 04:47:45PM +0100, Ian Jackson wrote:
> Prior to 2621d48f005a "gnulib: delete all gnulib integration",
> one could pass ./autogen.sh --no-git to prevent the libvirt build
> system from running git submodule update.
> 
> This feature is needed by systems like the Xen Project CI which want
> to explicitly control the revisions of every tree.  These will
> typically arrange to initialise the submodules check out the right
> version of everything, and then expect the build system not to mess
> with it any more.

To be honest I don't understand why would anyone want to keep track of
all submodules of all projects for any CI and update it manually every
time the upstream project changes these submodules. Sounds like a lot
of unnecessary work but maybe I'm missing something.

> Despite to the old documentation comments referring only to gnulib,
> the --no-git feature is required not only because of gnulib but also
> because of the other submodule, src/keycodemapdb.
> 
> (And in any case, even if it were no longer required because all the
> submodules were removed, it ought ideally to have been retained as a
> no-op for compaibility reasons.)

Well, we will break a lot more by switching to Meson build system where
everyone building libvirt will have to change their scripts as it will
not be compatible at all.

Pavel

> So restore the --no-git feature.
> 
> Because of the way the argument parsing of autogen.sh works, it is
> easiest to recognise this option only if it comes first.  This works
> for the Xen Project CI, which has always passed this option first.
> 
> If something else is using this option (and hasn't introduced a
> different workaround in the meantime), not in the first position,
> then perhaps a more sophisticated approach will be needed.  But I
> think this will do for now.
> 
> Signed-off-by: Ian Jackson 
> ---
>  autogen.sh | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/autogen.sh b/autogen.sh
> index 4e1bbceb0a..1c98273452 100755
> --- a/autogen.sh
> +++ b/autogen.sh
> @@ -1,5 +1,10 @@
>  #!/bin/sh
>  # Run this to generate all the initial makefiles, etc.
> +#
> +# THe following options must come first.  All other or subsequent
> +# arguments are passed to configure:
> +#   --no-git   skip `git submodule update --init`
> +
>  test -n "$srcdir" || srcdir=$(dirname "$0")
>  test -n "$srcdir" || srcdir=.
>  
> @@ -13,7 +18,11 @@ cd "$srcdir"
>  exit 1
>  }
>  
> -git submodule update --init || exit 1
> +if [ "x$1" = x--no-git ]; then
> + shift
> +else
> + git submodule update --init || exit 1
> +fi
>  
>  autoreconf --verbose --force --install || exit 1
>  
> -- 
> 2.11.0
> 


signature.asc
Description: PGP signature

Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately

[Jan Beulich]

On 03.06.2020 12:26, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich 
>> Sent: 03 June 2020 11:03
>> To: Igor Druzhinin 
>> Cc: xen-devel@lists.xenproject.org; andrew.coop...@citrix.com; w...@xen.org; 
>> roger@citrix.com;
>> george.dun...@citrix.com; Paul Durrant 
>> Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults 
>> immediately
>>
>> On 02.06.2020 18:56, Igor Druzhinin wrote:
>>> A recalculation NPT fault doesn't always require additional handling
>>> in hvm_hap_nested_page_fault(), moreover in general case if there is no
>>> explicit handling done there - the fault is wrongly considered fatal.
>>>
>>> This covers a specific case of migration with vGPU assigned on AMD:
>>> at a moment log-dirty is enabled globally, recalculation is requested
>>> for the whole guest memory including directly mapped MMIO regions of vGPU
>>> which causes a page fault being raised at the first access to those;
>>> but due to MMIO P2M type not having any explicit handling in
>>> hvm_hap_nested_page_fault() a domain is erroneously crashed with unhandled
>>> SVM violation.
>>>
>>> Instead of trying to be opportunistic - use safer approach and handle
>>> P2M recalculation in a separate NPT fault by attempting to retry after
>>> making the necessary adjustments. This is aligned with Intel behavior
>>> where there are separate VMEXITs for recalculation and EPT violations
>>> (faults) and only faults are handled in hvm_hap_nested_page_fault().
>>> Do it by also unifying do_recalc return code with Intel implementation
>>> where returning 1 means P2M was actually changed.
>>>
>>> Since there was no case previously where p2m_pt_handle_deferred_changes()
>>> could return a positive value - it's safe to replace ">= 0" with just "== 0"
>>> in VMEXIT_NPF handler. finish_type_change() is also not affected by the
>>> change as being able to deal with >0 return value of p2m->recalc from
>>> EPT implementation.
>>>
>>> Reviewed-by: Roger Pau Monné 
>>> Signed-off-by: Igor Druzhinin 
>>
>> Reviewed-by: Jan Beulich 
>> albeit preferably with ...
>>
>>> @@ -448,12 +451,14 @@ static int do_recalc(struct p2m_domain *p2m, unsigned 
>>> long gfn)
>>>  clear_recalc(l1, e);
>>>  err = p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1);
>>>  ASSERT(!err);
>>> +
>>> +recalc_done = true;
>>>  }
>>>
>>>   out:
>>>  unmap_domain_page(table);
>>>
>>> -return err;
>>> +return err ?: (recalc_done ? 1 : 0);
>>
>> ... this shrunk to
>>
>> return err ?: recalc_done;
>>
>> (easily doable while committing).
>>
>> Also Cc Paul.
>>
> 
> paging_log_dirty_enable() still fails global enable if has_arch_pdevs()
> is true, so presumably there's no desperate need for this to go in 4.14?

The MMIO case is just the particular situation here. Aiui the same issue
could potentially surface with other p2m types. Also given I'd consider
this a backporting candidate, while it may not be desperately needed for
the release, I think it deserves considering beyond the specific aspect
you mention.

Jan

Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update)

[Pavel Hrdina]

On Wed, Jun 03, 2020 at 11:37:08AM +0100, Daniel P. Berrangé wrote:
> On Wed, Jun 03, 2020 at 12:31:09PM +0200, Pavel Hrdina wrote:
> > On Tue, Jun 02, 2020 at 04:47:45PM +0100, Ian Jackson wrote:
> > > Prior to 2621d48f005a "gnulib: delete all gnulib integration",
> > > one could pass ./autogen.sh --no-git to prevent the libvirt build
> > > system from running git submodule update.
> > > 
> > > This feature is needed by systems like the Xen Project CI which want
> > > to explicitly control the revisions of every tree.  These will
> > > typically arrange to initialise the submodules check out the right
> > > version of everything, and then expect the build system not to mess
> > > with it any more.
> > 
> > To be honest I don't understand why would anyone want to keep track of
> > all submodules of all projects for any CI and update it manually every
> > time the upstream project changes these submodules. Sounds like a lot
> > of unnecessary work but maybe I'm missing something.
> 
> Two possible scenarios that I think are valid
> 
>  - The CI job script does not have network access
>  - The CI job script sees the source dir as read-only
> 
> In both cases the CI harness would have to initialize the submodule
> before runing the CI job.
> 
> I don't know if this is what Xen CI is hitting, but I think the
> request is reasonable none the less.
> 
> Both Jenkins and GitLab CI have option to make the harness init
> submodules prior to the job running.

My point was that running 'git submodule update --init' will not change
anything if all submodules are updated to the correct revision and if
the repository was pre-created with submodules and is read-only when the
test is executed the git command will not fail as well and everything
will be fine.

If the submodules are not updated to the correct revision then it will
fail and notify the CI users that something is broken.

There should not be any need to disable this explicitly unless you want
to build libvirt with different revisions of submodules.

> > > Despite to the old documentation comments referring only to gnulib,
> > > the --no-git feature is required not only because of gnulib but also
> > > because of the other submodule, src/keycodemapdb.
> > > 
> > > (And in any case, even if it were no longer required because all the
> > > submodules were removed, it ought ideally to have been retained as a
> > > no-op for compaibility reasons.)
> > 
> > Well, we will break a lot more by switching to Meson build system where
> > everyone building libvirt will have to change their scripts as it will
> > not be compatible at all.
> 
> Yes, but I think that's tangential, as the two above reasons will
> still apply, and Meson will cope with having submodules pre-initialized.

Yes, these are unrelated and I just wanted to point out that
compaibility reasons are in most cases not valid to changes to build
system or moving files around in git repository and so on.

Pavel


signature.asc
Description: PGP signature

Re: [PATCH v3 for-4.14] x86/monitor: revert default behavior when monitoring register write events

[Roger Pau Monné]

On Tue, Jun 02, 2020 at 07:49:09AM -0600, Tamas K Lengyel wrote:
> For the last couple years we have received numerous reports from users of
> monitor vm_events of spurious guest crashes when using events. In particular,
> it has observed that the problem occurs when vm_events are being disabled. The
> nature of the guest crash varied widely and has only occured occasionally. 
> This
> made debugging the issue particularly hard. We had discussions about this 
> issue
> even here on the xen-devel mailinglist with no luck figuring it out.
> 
> The bug has now been identified as a race-condition between register event
> handling and disabling the monitor vm_event interface.
> 
> Patch 96760e2fba100d694300a81baddb5740e0f8c0ee, "vm_event: deny register 
> writes
> if refused by  vm_event reply" is the patch that introduced the error. In this

FWIW, we use the 'Fixes:' tag in order to make it easier for
maintainers of stable trees to know which bugfixes to pick. This
should have:

Fixes: 96760e2fba10 ('vm_event: deny register writes if refused by vm_event 
reply')

Before the SoB.

> patch the default behavior regarding emulation of register write events is
> changed so that they get postponed until the corresponding vm_event handler
> decides whether to allow such write to take place. Unfortunately this can only
> be implemented by performing the deny/allow step when the vCPU gets scheduled.
> Due to that postponed emulation of the event if the user decides to pause the
> VM in the vm_event handler and then disable events, the entire emulation step
> is skipped the next time the vCPU is resumed. Even if the user doesn't pause
> during the vm_event handling but exits immediately and disables vm_event, the
> situation becomes racey as disabling vm_event may succeed before the guest's
> vCPUs get scheduled with the pending emulation task. This has been 
> particularly
> the case with VMS that have several vCPUs as after the VM is unpaused it may
> actually take a long time before all vCPUs get scheduled.
> 
> In this patch we are reverting the default behavior to always perform 
> emulation
> of register write events when the event occurs. To postpone them can be turned
> on as an option. In that case the user of the interface still has to take care
> of only disabling the interface when its safe as it remains buggy.
> 
> Signed-off-by: Tamas K Lengyel 

Thanks for taking care of this!

> ---
>  xen/arch/x86/hvm/hvm.c| 14 --
>  xen/arch/x86/hvm/monitor.c| 13 -
>  xen/arch/x86/monitor.c| 10 +-
>  xen/include/asm-x86/domain.h  |  1 +
>  xen/include/asm-x86/hvm/monitor.h |  7 +++
>  xen/include/public/domctl.h   |  1 +
>  6 files changed, 30 insertions(+), 16 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 74c9f84462..5bb47583b3 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3601,13 +3601,15 @@ int hvm_msr_write_intercept(unsigned int msr, 
> uint64_t msr_content,
>  
>  ASSERT(v->arch.vm_event);
>  
> -/* The actual write will occur in hvm_do_resume() (if permitted). */
> -v->arch.vm_event->write_data.do_write.msr = 1;
> -v->arch.vm_event->write_data.msr = msr;
> -v->arch.vm_event->write_data.value = msr_content;
> +if ( hvm_monitor_msr(msr, msr_content, msr_old_content) )
> +{
> +/* The actual write will occur in hvm_do_resume(), if permitted. 
> */
> +v->arch.vm_event->write_data.do_write.msr = 1;
> +v->arch.vm_event->write_data.msr = msr;
> +v->arch.vm_event->write_data.value = msr_content;
>  
> -hvm_monitor_msr(msr, msr_content, msr_old_content);
> -return X86EMUL_OKAY;
> +return X86EMUL_OKAY;
> +}
>  }
>  
>  if ( (ret = guest_wrmsr(v, msr, msr_content)) != X86EMUL_UNHANDLEABLE )
> diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
> index 8aa14137e2..36894b33a4 100644
> --- a/xen/arch/x86/hvm/monitor.c
> +++ b/xen/arch/x86/hvm/monitor.c
> @@ -53,11 +53,11 @@ bool hvm_monitor_cr(unsigned int index, unsigned long 
> value, unsigned long old)
>  .u.write_ctrlreg.old_value = old
>  };
>  
> -if ( monitor_traps(curr, sync, ) >= 0 )
> -return 1;
> +return monitor_traps(curr, sync, ) >= 0 &&
> +curr->domain->arch.monitor.control_register_values;

Nit (it can be fixed while committing IMO): curr should be aligned to
monitor.

>  }
>  
> -return 0;
> +return false;
>  }
>  
>  bool hvm_monitor_emul_unimplemented(void)
> @@ -77,7 +77,7 @@ bool hvm_monitor_emul_unimplemented(void)
>  monitor_traps(curr, true, ) == 1;
>  }
>  
> -void hvm_monitor_msr(unsigned int msr, uint64_t new_value, uint64_t 
> old_value)
> +bool hvm_monitor_msr(unsigned int msr, uint64_t new_value, uint64_t 
> old_value)
>  {
>  struct vcpu *curr = current;
>  

Re: Re [PATCH] x86/CET: Fix build following c/s 43b98e7190

[Jan Beulich]

On 02.06.2020 19:15, Andrew Cooper wrote:
> On 02/06/2020 15:21, Jan Beulich wrote:
>>> OSSTest reports:
>>>
>>>   x86_64.S: Assembler messages:
>>>   x86_64.S:57: Error: no such instruction: `setssbsy'
>>>   /home/osstest/build.150510.build-amd64/xen/xen/Rules.mk:183: recipe for 
>>> target 'head.o' failed
>>>   make[4]: Leaving directory 
>>> '/home/osstest/build.150510.build-amd64/xen/xen/arch/x86/boot'
>>>   make[4]: *** [head.o] Error 1
>>>
>>> All use of CET instructions, even those inside alternative blocks, needs to 
>>> be
>>> behind CONFIG_XEN_SHSTK, as it indicates suitable toolchain support.
>>>
>>> Signed-off-by: Andrew Cooper 
>> That's quite a bit of #ifdef-ary here. Simple (operand-less) insns
>> like SETSSBSY could easily be made available via .byte directives.
>> Would you be amenable to to ack-ing a patch to replace some of the
>> #ifdef-s (at least the ones at the lstar, cstar, and sysenter
>> entry points), after 4.14?
> 
> Yeah - that was a bit of a mess in the end.  (But given the
> circumstances, and that I've got past form typo'ing the SETSSBSY opcode,
> it probably was the right move even in hindsight).
> 
> Reducing it to .byte should be fine so long as some form of /* setssbsy
> */ comment appears.

Sure.

> One other option would be to introduce a SETSSBSY macro, but that hides
> the alternative so is something I'd prefer to avoid.

With this you mean you'd rather not see us go the CLAC/STAC route?
I was instead thinking of a pure assembly macro named "setssbsy".
In fact we could switch the CLAC/STAC ugliness to some such, if we
end up being happy with the model.

Jan

Re: [PATCH 0/2] osstest: update FreeBSD guest tests

[Ian Jackson]

Roger Pau Monne writes ("[PATCH 0/2] osstest: update FreeBSD guest tests"):
> The following series adds FreeBSD 11 and 12 guests tests to osstest.
> ATM this is only tested on amd64, since the i386 versions had a bug.
> 
> The result can be seen at:
> 
> http://logs.test-lab.xenproject.org/osstest/logs/150428/

Oh, I forgot to say, both patches

Acked-by: Ian Jackson 

Re: [PATCH 0/2] osstest: update FreeBSD guest tests

[Ian Jackson]

Roger Pau Monne writes ("[PATCH 0/2] osstest: update FreeBSD guest tests"):
> The following series adds FreeBSD 11 and 12 guests tests to osstest.
> ATM this is only tested on amd64, since the i386 versions had a bug.
> 
> The result can be seen at:
> 
> http://logs.test-lab.xenproject.org/osstest/logs/150428/

Thanks, Roger.

I think that for this change I ought to get an ack from Paul as the
RM.

Paul: how do you want to handle osstest changes during the freeze ?  I
already pushed on Monday - without asking you - a series to fix a
problem with bisection which was stopping osstest from bisecting the
libvirt failure in the smoke tests.  Please let me know if you think I
should have checked with you.

I think we should take this change from Roger.  Right now we are still
waiting for even the smoke tests from staging to pass.  I don't
think this would interfere with that nor will it get in the way of the
osstest buster upgrade.

Thanks,
Ian.

[XTF] xenbus: fix xenbus_write() ring overflow

[Pawel Wieczorkiewicz]

Currently the xenbus_write() does not handle ring wrapping around
correctly. When ring buffer is almost full and there is not enough
space for next packet (e.g. there is 12 bytes of space left, but the
packet header needs to transmit 16 bytes) the memcpy() goes out of the
ring buffer boundry.
Instead, the part variable should be limited to the space available in
the ring buffer, so the memcpy() can fill up the buffer, update len
variable (to indicate that there is still some data to be copied) and
thereby the xenbus_write() loop can iterate again to finish copying
the remainder of data to the beginning of the ring buffer.

Signed-off-by: Pawel Wieczorkiewicz 
---
 common/xenbus.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/common/xenbus.c b/common/xenbus.c
index 59159f2..24fff48 100644
--- a/common/xenbus.c
+++ b/common/xenbus.c
@@ -31,9 +31,7 @@ static void xenbus_write(const void *data, size_t len)
 uint32_t prod = ACCESS_ONCE(xb_ring->req_prod);
 uint32_t cons = ACCESS_ONCE(xb_ring->req_cons);
 
-uint32_t used = mask_xenbus_idx(prod - cons);
-
-part = (XENBUS_RING_SIZE - 1) - used;
+part = (XENBUS_RING_SIZE - 1) - mask_xenbus_idx(prod - cons);
 
 /* No space?  Kick xenstored and wait for it to consume some data. */
 if ( !part )
@@ -47,7 +45,7 @@ static void xenbus_write(const void *data, size_t len)
 }
 
 /* Don't overrun the ring. */
-part = min(part, XENBUS_RING_SIZE - used);
+part = min(part, XENBUS_RING_SIZE - mask_xenbus_idx(prod));
 
 /* Don't write more than necessary. */
 part = min(part, (unsigned int)len);
-- 
2.16.6




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

[libvirt test] 150639: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 146182
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 146182
 build-arm64-libvirt   6 libvirt-buildfail REGR. vs. 146182
 build-armhf-libvirt   6 libvirt-buildfail REGR. vs. 146182

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  a5a297f387fee9e9aa4cbc2df6788c330fd33ad1
baseline version:
 libvirt  a1cd25b919509be2645dbe6f952d5263e0d4e4e5

Last test of basis   146182  2020-01-17 06:00:23 Z  138 days
Failing since146211  2020-01-18 04:18:52 Z  137 days  128 attempts
Testing same since   150639  2020-06-03 04:26:10 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Arnaud Patard 
  Artur Puzio 
  Bjoern Walk 
  Boris Fiuczynski 
  Chen Hanxiao 
  Chris Jester-Young 
  Christian Borntraeger 
  Christian Ehrhardt 
  Christian Schoenebeck 
  Collin Walling 
  Cornelia Huck 
  Daniel Henrique Barboza 
  Daniel P. Berrangé 
  Daniel Veillard 
  Dario Faggioli 
  Erik Skultety 
  Gaurav Agrawal 
  Han Han 
  Jaak Ristioja 
  Jamie Strandboge 
  Jim Fehlig 
  Jiri Denemark 
  Jonathon Jongsma 
  Julio Faracco 
  Ján Tomko 
  Laine Stump 
  Leonid Bloch 
  Liao Pingfang 
  Lin Ma 
  Marc-André Lureau 
  Marek Marczykowski-Górecki 
  Mark Asselstine 
  Mauro S. M. Rodrigues 
  Michal Privoznik 
  Nikolay Shirokovskiy 
  Paolo Bonzini 
  Pavel Hrdina 
  Pavel Mores 
  Peter Krempa 
  Philipp Hahn 
  Pino Toscano 
  Prathamesh Chavan 
  Rafael Fonseca 
  Richard W.M. Jones 
  Rikard Falkeborn 
  Ryan Moeller 
  Sahid Orentino Ferdjaoui 
  Sebastian Mitterle 
  Seeteena Thoufeek 
  Stefan Berger 
  Stefan Berger 
  Stefan Hajnoczi 
  Thomas Huth 
  Tobin Feldman-Fitzthum 
  Tomáš Golembiovský 
  Wu Qingliang 
  Xu Yandong 
  Yan Wang 
  Yi Li 
  Your Name 
  Zhang Bo 
  zhenwei pi 
  Zhenyu Zheng 
  Zhimin Feng 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-arm64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm blocked 
 test-arm64-arm64-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt blocked 
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt blocked 
 test-amd64-i386-libvirt  

[xen-unstable-smoke test] 150643: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 12 guest-start  fail REGR. vs. 150438

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

version targeted for testing:
 xen  99a76a88d5e7f4693bb6b286e366006e1da1c954
baseline version:
 xen  1497e78068421d83956f8e82fb6e1bf1fc3b1199

Last test of basis   150438  2020-05-28 14:01:19 Z5 days
Failing since150465  2020-05-29 09:02:14 Z5 days   37 attempts
Testing same since   150629  2020-06-02 21:00:40 Z0 days4 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andrew Cooper 
  Anthony PERARD 
  Dario Faggioli 
  Ian Jackson 
  Jan Beulich 
  Jason Andryuk 
  Juergen Gross 
  Julien Grall 
  Olaf Hering 
  Paul Durrant 
  Paul Durrant 
  Roger Pau Monné 
  Tamas K Lengyel 
  Wei Liu 

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 fail



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.

(No revision log; it would be 1494 lines long.)

RE: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately

[Paul Durrant]

> -Original Message-
> From: Jan Beulich 
> Sent: 03 June 2020 12:22
> To: p...@xen.org
> Cc: 'Igor Druzhinin' ; 
> xen-devel@lists.xenproject.org;
> andrew.coop...@citrix.com; w...@xen.org; roger@citrix.com; 
> george.dun...@citrix.com
> Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults 
> immediately
> 
> On 03.06.2020 12:26, Paul Durrant wrote:
> >> -Original Message-
> >> From: Jan Beulich 
> >> Sent: 03 June 2020 11:03
> >> To: Igor Druzhinin 
> >> Cc: xen-devel@lists.xenproject.org; andrew.coop...@citrix.com; 
> >> w...@xen.org; roger@citrix.com;
> >> george.dun...@citrix.com; Paul Durrant 
> >> Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults 
> >> immediately
> >>
> >> On 02.06.2020 18:56, Igor Druzhinin wrote:
> >>> A recalculation NPT fault doesn't always require additional handling
> >>> in hvm_hap_nested_page_fault(), moreover in general case if there is no
> >>> explicit handling done there - the fault is wrongly considered fatal.
> >>>
> >>> This covers a specific case of migration with vGPU assigned on AMD:
> >>> at a moment log-dirty is enabled globally, recalculation is requested
> >>> for the whole guest memory including directly mapped MMIO regions of vGPU
> >>> which causes a page fault being raised at the first access to those;
> >>> but due to MMIO P2M type not having any explicit handling in
> >>> hvm_hap_nested_page_fault() a domain is erroneously crashed with unhandled
> >>> SVM violation.
> >>>
> >>> Instead of trying to be opportunistic - use safer approach and handle
> >>> P2M recalculation in a separate NPT fault by attempting to retry after
> >>> making the necessary adjustments. This is aligned with Intel behavior
> >>> where there are separate VMEXITs for recalculation and EPT violations
> >>> (faults) and only faults are handled in hvm_hap_nested_page_fault().
> >>> Do it by also unifying do_recalc return code with Intel implementation
> >>> where returning 1 means P2M was actually changed.
> >>>
> >>> Since there was no case previously where p2m_pt_handle_deferred_changes()
> >>> could return a positive value - it's safe to replace ">= 0" with just "== 
> >>> 0"
> >>> in VMEXIT_NPF handler. finish_type_change() is also not affected by the
> >>> change as being able to deal with >0 return value of p2m->recalc from
> >>> EPT implementation.
> >>>
> >>> Reviewed-by: Roger Pau Monné 
> >>> Signed-off-by: Igor Druzhinin 
> >>
> >> Reviewed-by: Jan Beulich 
> >> albeit preferably with ...
> >>
> >>> @@ -448,12 +451,14 @@ static int do_recalc(struct p2m_domain *p2m, 
> >>> unsigned long gfn)
> >>>  clear_recalc(l1, e);
> >>>  err = p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1);
> >>>  ASSERT(!err);
> >>> +
> >>> +recalc_done = true;
> >>>  }
> >>>
> >>>   out:
> >>>  unmap_domain_page(table);
> >>>
> >>> -return err;
> >>> +return err ?: (recalc_done ? 1 : 0);
> >>
> >> ... this shrunk to
> >>
> >> return err ?: recalc_done;
> >>
> >> (easily doable while committing).
> >>
> >> Also Cc Paul.
> >>
> >
> > paging_log_dirty_enable() still fails global enable if has_arch_pdevs()
> > is true, so presumably there's no desperate need for this to go in 4.14?
> 
> The MMIO case is just the particular situation here. Aiui the same issue
> could potentially surface with other p2m types. Also given I'd consider
> this a backporting candidate, while it may not be desperately needed for
> the release, I think it deserves considering beyond the specific aspect
> you mention.
> 

In which case I think the commit message probably ought to be rephrased, since 
it appears to focus on a case that cannot currently happen.

  Paul

Re: UEFI support in ARM DomUs

[Julien Grall]

On 01/06/2020 05:11, Roman Shaposhnik wrote:

Hi Julien!


Hi Roman,



On Sun, May 31, 2020 at 3:24 PM Julien Grall  wrote:


On Sun, 31 May 2020 at 23:05, Roman Shaposhnik  wrote:

Hi!

with a lot of help from Stefano, we're getting RPi4 support in
Project EVE pretty much on par between KVM and Xen.

One big area that still remains is supporting UEFI boot sequence
for DomUs. With KVM, given the qemu virt device model this is
as simple as using either stock UEFI build for arm or even U-Boot
EFI emulation environment and passing it via -bios option.

Obviously with Xen on ARM we don't have the device model so
my understanding is that the easiest way we can support it would
be to port UEFI's OvmfPkg/OvmfXen target to ARM (it seems to
be currently exclusively X64).


EDK2 has been supporting Xen on Arm for the past 5 years. We don't use
OvmfPkg/OvmfXen but ArmVirtPkg/ArmVirtXen (see [1]).
I haven't tried to build it recently, but I should be able to help if
there is any issue with it.

Cheers,

[1] https://github.com/tianocore/edk2/blob/master/ArmVirtPkg/ArmVirtXen.fdf


This is really, really awesome -- I guess it would be really helpful to document
this someplace on the ARM/Xen wiki (I can volunteer if someone can grant
me the karma).


There used to be a page on the Linaro wiki when they did the port. But 
it looks like any Xen pages have been removed/relocated :(.


Anyway, a page on Xen Project wiki would definitely be appreciated.



I've built XEN_EFI.fd and the rest worked out like a charm.


Glad to hear that it worked :).

Cheers,

--
Julien Grall

Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update)

[Daniel P . Berrangé]

On Wed, Jun 03, 2020 at 12:31:09PM +0200, Pavel Hrdina wrote:
> On Tue, Jun 02, 2020 at 04:47:45PM +0100, Ian Jackson wrote:
> > Prior to 2621d48f005a "gnulib: delete all gnulib integration",
> > one could pass ./autogen.sh --no-git to prevent the libvirt build
> > system from running git submodule update.
> > 
> > This feature is needed by systems like the Xen Project CI which want
> > to explicitly control the revisions of every tree.  These will
> > typically arrange to initialise the submodules check out the right
> > version of everything, and then expect the build system not to mess
> > with it any more.
> 
> To be honest I don't understand why would anyone want to keep track of
> all submodules of all projects for any CI and update it manually every
> time the upstream project changes these submodules. Sounds like a lot
> of unnecessary work but maybe I'm missing something.

Two possible scenarios that I think are valid

 - The CI job script does not have network access
 - The CI job script sees the source dir as read-only

In both cases the CI harness would have to initialize the submodule
before runing the CI job.

I don't know if this is what Xen CI is hitting, but I think the
request is reasonable none the less.

Both Jenkins and GitLab CI have option to make the harness init
submodules prior to the job running.

> > Despite to the old documentation comments referring only to gnulib,
> > the --no-git feature is required not only because of gnulib but also
> > because of the other submodule, src/keycodemapdb.
> > 
> > (And in any case, even if it were no longer required because all the
> > submodules were removed, it ought ideally to have been retained as a
> > no-op for compaibility reasons.)
> 
> Well, we will break a lot more by switching to Meson build system where
> everyone building libvirt will have to change their scripts as it will
> not be compatible at all.

Yes, but I think that's tangential, as the two above reasons will
still apply, and Meson will cope with having submodules pre-initialized.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

RE: [PATCH 0/2] osstest: update FreeBSD guest tests

[Paul Durrant]

> -Original Message-
> From: Ian Jackson 
> Sent: 03 June 2020 10:51
> To: Roger Pau Monne 
> Cc: xen-devel@lists.xenproject.org; Paul Durrant 
> Subject: Re: [PATCH 0/2] osstest: update FreeBSD guest tests
> 
> Roger Pau Monne writes ("[PATCH 0/2] osstest: update FreeBSD guest tests"):
> > The following series adds FreeBSD 11 and 12 guests tests to osstest.
> > ATM this is only tested on amd64, since the i386 versions had a bug.
> >
> > The result can be seen at:
> >
> > http://logs.test-lab.xenproject.org/osstest/logs/150428/
> 
> Thanks, Roger.
> 
> I think that for this change I ought to get an ack from Paul as the
> RM.
> 
> Paul: how do you want to handle osstest changes during the freeze ?  I
> already pushed on Monday - without asking you - a series to fix a
> problem with bisection which was stopping osstest from bisecting the
> libvirt failure in the smoke tests.  Please let me know if you think I
> should have checked with you.
> 

I'm no expert in osstest so I need to trust your judgement as to whether a 
patch is needed for 4.14 testing. That fix was clearly
necessary to help diagnose the libvirt issue so I don't think you need check 
with me for such things.

> I think we should take this change from Roger.  Right now we are still
> waiting for even the smoke tests from staging to pass.  I don't
> think this would interfere with that nor will it get in the way of the
> osstest buster upgrade.

We should certainly try to limit changes to only those where really are 
beneficial for 4.14 at this stage, but it looks like this
series is adding more relevant testing (i.e. on newer OS) so I think it 
qualifies.

  Paul

> 
> Thanks,
> Ian.

Re: [PATCH v2 for-4.14 1/3] xen/monitor: Control register values

[Roger Pau Monné]

On Tue, Jun 02, 2020 at 07:10:07AM -0600, Tamas K Lengyel wrote:
> On Tue, Jun 2, 2020 at 7:00 AM Jan Beulich  wrote:
> >
> > On 02.06.2020 14:51, Tamas K Lengyel wrote:
> > > On Tue, Jun 2, 2020 at 6:47 AM Jan Beulich  wrote:
> > >>
> > >> On 02.06.2020 14:40, Tamas K Lengyel wrote:
> > >>> On Tue, Jun 2, 2020 at 5:08 AM Roger Pau Monné  
> > >>> wrote:
> > 
> >  On Wed, May 20, 2020 at 08:31:52PM -0600, Tamas K Lengyel wrote:
> > > Extend the monitor_op domctl to include option that enables
> > > controlling what values certain registers are permitted to hold
> > > by a monitor subscriber.
> > 
> >  I think the change could benefit for some more detail commit message
> >  here. Why is this useful?
> > >>>
> > >>> You would have to ask the Bitdefender folks who made the feature. I
> > >>> don't use it. Here we are just making it optional as it is buggy so it
> > >>> is disabled by default.
> > >>
> > >> Now that's exactly the opposite of what I had derived from the
> > >> description here so far. Perhaps an at least weak indication
> > >> that you want to reword this. For example, from your reply to
> > >> Roger I understand it's rather that the new flag allows to
> > >> "suppress" the controlling (since presumably you don't change
> > >> default behavior), rather then "enabling" it.
> > >
> > > What we are adding is a domctl you need to call that enables this
> > > feature. It's not an option to suppress it. It shouldn't have been
> > > enabled by default to begin with. That was a mistake when the feature
> > > was contributed and it is buggy.
> >
> > Okay, in this case it's important to point out that you alter
> > default behavior. The BitDefender folks may not like this, yet
> > they've been surprisingly silent so far.
> 
> Well, it was Bitdefender who altered the default behavior. We are
> reverting their mistake and making it optional. But I can certainly
> make that more clear.

I would like some input from the Bitdefender guys. Is there a bugfix
planned for this feature?

It would be nice to get this in before 4.14 releases.

Roger.

Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately

[Jan Beulich]

On 02.06.2020 18:56, Igor Druzhinin wrote:
> A recalculation NPT fault doesn't always require additional handling
> in hvm_hap_nested_page_fault(), moreover in general case if there is no
> explicit handling done there - the fault is wrongly considered fatal.
> 
> This covers a specific case of migration with vGPU assigned on AMD:
> at a moment log-dirty is enabled globally, recalculation is requested
> for the whole guest memory including directly mapped MMIO regions of vGPU
> which causes a page fault being raised at the first access to those;
> but due to MMIO P2M type not having any explicit handling in
> hvm_hap_nested_page_fault() a domain is erroneously crashed with unhandled
> SVM violation.
> 
> Instead of trying to be opportunistic - use safer approach and handle
> P2M recalculation in a separate NPT fault by attempting to retry after
> making the necessary adjustments. This is aligned with Intel behavior
> where there are separate VMEXITs for recalculation and EPT violations
> (faults) and only faults are handled in hvm_hap_nested_page_fault().
> Do it by also unifying do_recalc return code with Intel implementation
> where returning 1 means P2M was actually changed.
> 
> Since there was no case previously where p2m_pt_handle_deferred_changes()
> could return a positive value - it's safe to replace ">= 0" with just "== 0"
> in VMEXIT_NPF handler. finish_type_change() is also not affected by the
> change as being able to deal with >0 return value of p2m->recalc from
> EPT implementation.
> 
> Reviewed-by: Roger Pau Monné 
> Signed-off-by: Igor Druzhinin 

Reviewed-by: Jan Beulich 
albeit preferably with ...

> @@ -448,12 +451,14 @@ static int do_recalc(struct p2m_domain *p2m, unsigned 
> long gfn)
>  clear_recalc(l1, e);
>  err = p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1);
>  ASSERT(!err);
> +
> +recalc_done = true;
>  }
>  
>   out:
>  unmap_domain_page(table);
>  
> -return err;
> +return err ?: (recalc_done ? 1 : 0);

... this shrunk to

return err ?: recalc_done;

(easily doable while committing).

Also Cc Paul.

Jan

Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately

[Igor Druzhinin]

On 03/06/2020 12:48, Paul Durrant wrote:
>> -Original Message-
>> From: Igor Druzhinin 
>> Sent: 03 June 2020 12:45
>> To: p...@xen.org; 'Jan Beulich' 
>> Cc: xen-devel@lists.xenproject.org; andrew.coop...@citrix.com; w...@xen.org; 
>> roger@citrix.com;
>> george.dun...@citrix.com
>> Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults 
>> immediately
>>
>> On 03/06/2020 12:28, Paul Durrant wrote:
 -Original Message-
 From: Jan Beulich 
 Sent: 03 June 2020 12:22
 To: p...@xen.org
 Cc: 'Igor Druzhinin' ; 
 xen-devel@lists.xenproject.org;
 andrew.coop...@citrix.com; w...@xen.org; roger@citrix.com; 
 george.dun...@citrix.com
 Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults 
 immediately

 On 03.06.2020 12:26, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich 
>> Sent: 03 June 2020 11:03
>> To: Igor Druzhinin 
>> Cc: xen-devel@lists.xenproject.org; andrew.coop...@citrix.com; 
>> w...@xen.org; roger@citrix.com;
>> george.dun...@citrix.com; Paul Durrant 
>> Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults 
>> immediately
>>
>> On 02.06.2020 18:56, Igor Druzhinin wrote:
>>> A recalculation NPT fault doesn't always require additional handling
>>> in hvm_hap_nested_page_fault(), moreover in general case if there is no
>>> explicit handling done there - the fault is wrongly considered fatal.
>>>
>>> This covers a specific case of migration with vGPU assigned on AMD:
>>> at a moment log-dirty is enabled globally, recalculation is requested
>>> for the whole guest memory including directly mapped MMIO regions of 
>>> vGPU
>>> which causes a page fault being raised at the first access to those;
>>> but due to MMIO P2M type not having any explicit handling in
>>> hvm_hap_nested_page_fault() a domain is erroneously crashed with 
>>> unhandled
>>> SVM violation.
>>>
>>> Instead of trying to be opportunistic - use safer approach and handle
>>> P2M recalculation in a separate NPT fault by attempting to retry after
>>> making the necessary adjustments. This is aligned with Intel behavior
>>> where there are separate VMEXITs for recalculation and EPT violations
>>> (faults) and only faults are handled in hvm_hap_nested_page_fault().
>>> Do it by also unifying do_recalc return code with Intel implementation
>>> where returning 1 means P2M was actually changed.
>>>
>>> Since there was no case previously where 
>>> p2m_pt_handle_deferred_changes()
>>> could return a positive value - it's safe to replace ">= 0" with just 
>>> "== 0"
>>> in VMEXIT_NPF handler. finish_type_change() is also not affected by the
>>> change as being able to deal with >0 return value of p2m->recalc from
>>> EPT implementation.
>>>
>>> Reviewed-by: Roger Pau Monné 
>>> Signed-off-by: Igor Druzhinin 
>>
>> Reviewed-by: Jan Beulich 
>> albeit preferably with ...
>>
>>> @@ -448,12 +451,14 @@ static int do_recalc(struct p2m_domain *p2m, 
>>> unsigned long gfn)
>>>  clear_recalc(l1, e);
>>>  err = p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1);
>>>  ASSERT(!err);
>>> +
>>> +recalc_done = true;
>>>  }
>>>
>>>   out:
>>>  unmap_domain_page(table);
>>>
>>> -return err;
>>> +return err ?: (recalc_done ? 1 : 0);
>>
>> ... this shrunk to
>>
>> return err ?: recalc_done;
>>
>> (easily doable while committing).
>>
>> Also Cc Paul.
>>
>
> paging_log_dirty_enable() still fails global enable if has_arch_pdevs()
> is true, so presumably there's no desperate need for this to go in 4.14?

 The MMIO case is just the particular situation here. Aiui the same issue
 could potentially surface with other p2m types. Also given I'd consider
 this a backporting candidate, while it may not be desperately needed for
 the release, I think it deserves considering beyond the specific aspect
 you mention.

>>>
>>> In which case I think the commit message probably ought to be rephrased, 
>>> since it appears to focus
>> on a case that cannot currently happen.
>>
>> This can happen without has_arch_pdevs() being true. It's enough to just
>> directly map some physical memory into a guest to get p2m_direct_mmio
>> type present in the page tables.
> 
> OK, that's fine, but when will that happen without pass-through? If we can 
> have a commit message justifying the change based on what can actually happen 
> now, then I would not be opposed to it going in 4.14.

Yes, it can happen now - we had regular (not SR-IOV) vGPU migration totally
broken because of this on AMD - never got tested before at all. You don't need
special patches on top of Xen or anything.

[linux-5.4 test] 150642: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt  broken
 test-amd64-i386-qemuu-rhel6hvm-amd broken
 test-amd64-i386-libvirt   4 host-install(4)broken REGR. vs. 150508
 test-amd64-i386-qemuu-rhel6hvm-amd  4 host-install(4)  broken REGR. vs. 150508

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   fail  like 150423
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 150508
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-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-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-libvirt-vhd 12 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 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   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-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-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-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-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-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 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-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 linux55852b3fd146ce90d4d4306b467261f2c4869293
baseline version:
 linuxe0d81ce760044efd3f26004aa32821c34968512a

Last test of basis   150508  2020-05-29 22:40:26 Z4 days
Testing same since   

[linux-linus test] 150641: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10  fail blocked in 150606
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 150606
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 150606
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 150606
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150606
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 150606
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 150606
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 150606
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150606
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 150606
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-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-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-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-arm64-arm64-xl-thunderx 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-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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  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-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  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-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-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 linuxd6f9469a03d832dcd17041ed67774ffb5f3e73b3
baseline version:
 linux9bf9511e3d9f328c03f6f79bfb741c3d18f2f2c0

Last test of basis   150606  2020-06-01 19:40:10 Z1 days
Failing since150613  2020-06-02 05:14:57 Z1 days3 attempts
Testing same since   150641  2020-06-03 06:35:03 Z0 days1 attempts


719 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm 

RE: [PATCH v3] xen: fix build without pci passthrough

[Paul Durrant]

> -Original Message-
> From: Anthony PERARD 
> Sent: 03 June 2020 17:05
> To: qemu-de...@nongnu.org
> Cc: Anthony PERARD ; Roger Pau Monne 
> ; Michael S.
> Tsirkin ; Marcel Apfelbaum ; 
> Paolo Bonzini
> ; Richard Henderson ; Eduardo Habkost 
> ;
> Stefano Stabellini ; Paul Durrant ; xen-
> de...@lists.xenproject.org
> Subject: [PATCH v3] xen: fix build without pci passthrough
> 
> From: Roger Pau Monne 
> 
> Xen PCI passthrough support may not be available and thus the global
> variable "has_igd_gfx_passthru" might be compiled out. Common code
> should not access it in that case.
> 
> Unfortunately, we can't use CONFIG_XEN_PCI_PASSTHROUGH directly in
> xen-common.c so this patch instead move access to the
> has_igd_gfx_passthru variable via function and those functions are
> also implemented as stubs. The stubs will be used when QEMU is built
> without passthrough support.
> 
> Now, when one will want to enable igd-passthru via the -machine
> property, they will get an error message if QEMU is built without
> passthrough support.
> 
> Fixes: 46472d82322d0 ('xen: convert "-machine igd-passthru" to an accelerator 
> property')
> Reported-by: Roger Pau Monné 
> Signed-off-by: Anthony PERARD 

Acked-by: Paul Durrant 

> ---
> 
> Notes:
> Changes in v3:
> - reworked to use stubs instead of #ifdef CONFIG_XEN_PCI_PASSTHROUGH
>   CONFIG_XEN_PCI_PASSTHROUGH isn't available in xen-common.c
> 
>   moving CONFIG_XEN_PCI_PASSTHROUGH to be in config_host_mak isn't
>   really possible, or at least I didn't managed to make that work.
> 
>  hw/i386/pc_piix.c   |  2 +-
>  hw/xen/xen-common.c |  4 ++--
>  hw/xen/xen_pt.c | 12 +++-
>  hw/xen/xen_pt.h |  6 --
>  stubs/Makefile.objs |  1 +
>  stubs/xen-pt.c  | 22 ++
>  6 files changed, 41 insertions(+), 6 deletions(-)
>  create mode 100644 stubs/xen-pt.c
> 
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index f66e1d73ce0b..347fb8c6c807 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -375,7 +375,7 @@ static void pc_init_isa(MachineState *machine)
>  #ifdef CONFIG_XEN
>  static void pc_xen_hvm_init_pci(MachineState *machine)
>  {
> -const char *pci_type = has_igd_gfx_passthru ?
> +const char *pci_type = xen_igd_gfx_pt_enabled() ?
>  TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE : 
> TYPE_I440FX_PCI_DEVICE;
> 
>  pc_init1(machine,
> diff --git a/hw/xen/xen-common.c b/hw/xen/xen-common.c
> index 70564cc952d5..dd2c22cc4c0b 100644
> --- a/hw/xen/xen-common.c
> +++ b/hw/xen/xen-common.c
> @@ -129,12 +129,12 @@ static void xen_change_state_handler(void *opaque, int 
> running,
> 
>  static bool xen_get_igd_gfx_passthru(Object *obj, Error **errp)
>  {
> -return has_igd_gfx_passthru;
> +return xen_igd_gfx_pt_enabled();
>  }
> 
>  static void xen_set_igd_gfx_passthru(Object *obj, bool value, Error **errp)
>  {
> -has_igd_gfx_passthru = value;
> +xen_igd_gfx_pt_set(value, errp);
>  }
> 
>  static void xen_setup_post(MachineState *ms, AccelState *accel)
> diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
> index 81d5ad8da7f0..ab84443d5ec8 100644
> --- a/hw/xen/xen_pt.c
> +++ b/hw/xen/xen_pt.c
> @@ -65,7 +65,17 @@
>  #include "qemu/range.h"
>  #include "exec/address-spaces.h"
> 
> -bool has_igd_gfx_passthru;
> +static bool has_igd_gfx_passthru;
> +
> +bool xen_igd_gfx_pt_enabled(void)
> +{
> +return has_igd_gfx_passthru;
> +}
> +
> +void xen_igd_gfx_pt_set(bool value, Error **errp)
> +{
> +has_igd_gfx_passthru = value;
> +}
> 
>  #define XEN_PT_NR_IRQS (256)
>  static uint8_t xen_pt_mapped_machine_irq[XEN_PT_NR_IRQS] = {0};
> diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
> index 179775db7b22..6e9cec95f3b7 100644
> --- a/hw/xen/xen_pt.h
> +++ b/hw/xen/xen_pt.h
> @@ -5,6 +5,9 @@
>  #include "hw/pci/pci.h"
>  #include "xen-host-pci-device.h"
> 
> +bool xen_igd_gfx_pt_enabled(void);
> +void xen_igd_gfx_pt_set(bool value, Error **errp);
> +
>  void xen_pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
> 
>  #define XEN_PT_ERR(d, _f, _a...) xen_pt_log(d, "%s: Error: "_f, __func__, 
> ##_a)
> @@ -322,10 +325,9 @@ extern void *pci_assign_dev_load_option_rom(PCIDevice 
> *dev,
>  unsigned int domain,
>  unsigned int bus, unsigned int 
> slot,
>  unsigned int function);
> -extern bool has_igd_gfx_passthru;
>  static inline bool is_igd_vga_passthrough(XenHostPCIDevice *dev)
>  {
> -return (has_igd_gfx_passthru
> +return (xen_igd_gfx_pt_enabled()
>  && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
>  }
>  int xen_pt_register_vga_regions(XenHostPCIDevice *dev);
> diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
> index 6a9e3135e8f9..564527e00997 100644
> --- a/stubs/Makefile.objs
> +++ b/stubs/Makefile.objs
> @@ -40,6 +40,7 @@ stub-obj-y += target-get-monitor-def.o
>  stub-obj-y += 

Re: [PATCH v3 for-4.14] x86/monitor: revert default behavior when monitoring register write events

[Tamas K Lengyel]

On Wed, Jun 3, 2020 at 2:28 AM Roger Pau Monné  wrote:
>
> On Tue, Jun 02, 2020 at 07:49:09AM -0600, Tamas K Lengyel wrote:
> > For the last couple years we have received numerous reports from users of
> > monitor vm_events of spurious guest crashes when using events. In 
> > particular,
> > it has observed that the problem occurs when vm_events are being disabled. 
> > The
> > nature of the guest crash varied widely and has only occured occasionally. 
> > This
> > made debugging the issue particularly hard. We had discussions about this 
> > issue
> > even here on the xen-devel mailinglist with no luck figuring it out.
> >
> > The bug has now been identified as a race-condition between register event
> > handling and disabling the monitor vm_event interface.
> >
> > Patch 96760e2fba100d694300a81baddb5740e0f8c0ee, "vm_event: deny register 
> > writes
> > if refused by  vm_event reply" is the patch that introduced the error. In 
> > this
>
> FWIW, we use the 'Fixes:' tag in order to make it easier for
> maintainers of stable trees to know which bugfixes to pick. This
> should have:
>
> Fixes: 96760e2fba10 ('vm_event: deny register writes if refused by vm_event 
> reply')
>
> Before the SoB.
>
> > patch the default behavior regarding emulation of register write events is
> > changed so that they get postponed until the corresponding vm_event handler
> > decides whether to allow such write to take place. Unfortunately this can 
> > only
> > be implemented by performing the deny/allow step when the vCPU gets 
> > scheduled.
> > Due to that postponed emulation of the event if the user decides to pause 
> > the
> > VM in the vm_event handler and then disable events, the entire emulation 
> > step
> > is skipped the next time the vCPU is resumed. Even if the user doesn't pause
> > during the vm_event handling but exits immediately and disables vm_event, 
> > the
> > situation becomes racey as disabling vm_event may succeed before the guest's
> > vCPUs get scheduled with the pending emulation task. This has been 
> > particularly
> > the case with VMS that have several vCPUs as after the VM is unpaused it may
> > actually take a long time before all vCPUs get scheduled.
> >
> > In this patch we are reverting the default behavior to always perform 
> > emulation
> > of register write events when the event occurs. To postpone them can be 
> > turned
> > on as an option. In that case the user of the interface still has to take 
> > care
> > of only disabling the interface when its safe as it remains buggy.
> >
> > Signed-off-by: Tamas K Lengyel 
>
> Thanks for taking care of this!
>
> > ---
> >  xen/arch/x86/hvm/hvm.c| 14 --
> >  xen/arch/x86/hvm/monitor.c| 13 -
> >  xen/arch/x86/monitor.c| 10 +-
> >  xen/include/asm-x86/domain.h  |  1 +
> >  xen/include/asm-x86/hvm/monitor.h |  7 +++
> >  xen/include/public/domctl.h   |  1 +
> >  6 files changed, 30 insertions(+), 16 deletions(-)
> >
> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> > index 74c9f84462..5bb47583b3 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -3601,13 +3601,15 @@ int hvm_msr_write_intercept(unsigned int msr, 
> > uint64_t msr_content,
> >
> >  ASSERT(v->arch.vm_event);
> >
> > -/* The actual write will occur in hvm_do_resume() (if permitted). 
> > */
> > -v->arch.vm_event->write_data.do_write.msr = 1;
> > -v->arch.vm_event->write_data.msr = msr;
> > -v->arch.vm_event->write_data.value = msr_content;
> > +if ( hvm_monitor_msr(msr, msr_content, msr_old_content) )
> > +{
> > +/* The actual write will occur in hvm_do_resume(), if 
> > permitted. */
> > +v->arch.vm_event->write_data.do_write.msr = 1;
> > +v->arch.vm_event->write_data.msr = msr;
> > +v->arch.vm_event->write_data.value = msr_content;
> >
> > -hvm_monitor_msr(msr, msr_content, msr_old_content);
> > -return X86EMUL_OKAY;
> > +return X86EMUL_OKAY;
> > +}
> >  }
> >
> >  if ( (ret = guest_wrmsr(v, msr, msr_content)) != X86EMUL_UNHANDLEABLE )
> > diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
> > index 8aa14137e2..36894b33a4 100644
> > --- a/xen/arch/x86/hvm/monitor.c
> > +++ b/xen/arch/x86/hvm/monitor.c
> > @@ -53,11 +53,11 @@ bool hvm_monitor_cr(unsigned int index, unsigned long 
> > value, unsigned long old)
> >  .u.write_ctrlreg.old_value = old
> >  };
> >
> > -if ( monitor_traps(curr, sync, ) >= 0 )
> > -return 1;
> > +return monitor_traps(curr, sync, ) >= 0 &&
> > +curr->domain->arch.monitor.control_register_values;
>
> Nit (it can be fixed while committing IMO): curr should be aligned to
> monitor.

This is the established style already in-place, see

Re: [PATCH] xen-netback: use kstrdup() in connect_data_rings()

[Wei Liu]

On Wed, Jun 03, 2020 at 06:26:43PM +0300, Denis Efremov wrote:
> Use kstrdup() instead of opencoded alloc and copy. kzalloc() is
> excessive here.
> 
> Signed-off-by: Denis Efremov 

Acked-by: Wei Liu 

> ---
>  drivers/net/xen-netback/xenbus.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/xenbus.c 
> b/drivers/net/xen-netback/xenbus.c
> index 286054b60d47..69352154a51b 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -839,13 +839,12 @@ static int connect_data_rings(struct backend_info *be,
>* queue-N.
>*/
>   if (num_queues == 1) {
> - xspath = kzalloc(strlen(dev->otherend) + 1, GFP_KERNEL);
> + xspath = kstrdup(dev->otherend, GFP_KERNEL);
>   if (!xspath) {
>   xenbus_dev_fatal(dev, -ENOMEM,
>"reading ring references");
>   return -ENOMEM;
>   }
> - strcpy(xspath, dev->otherend);
>   } else {
>   xspathsize = strlen(dev->otherend) + xenstore_path_ext_size;
>   xspath = kzalloc(xspathsize, GFP_KERNEL);
> -- 
> 2.26.2
> 

[PATCH v3] xen: fix build without pci passthrough

[Anthony PERARD]

From: Roger Pau Monne 

Xen PCI passthrough support may not be available and thus the global
variable "has_igd_gfx_passthru" might be compiled out. Common code
should not access it in that case.

Unfortunately, we can't use CONFIG_XEN_PCI_PASSTHROUGH directly in
xen-common.c so this patch instead move access to the
has_igd_gfx_passthru variable via function and those functions are
also implemented as stubs. The stubs will be used when QEMU is built
without passthrough support.

Now, when one will want to enable igd-passthru via the -machine
property, they will get an error message if QEMU is built without
passthrough support.

Fixes: 46472d82322d0 ('xen: convert "-machine igd-passthru" to an accelerator 
property')
Reported-by: Roger Pau Monné 
Signed-off-by: Anthony PERARD 
---

Notes:
Changes in v3:
- reworked to use stubs instead of #ifdef CONFIG_XEN_PCI_PASSTHROUGH
  CONFIG_XEN_PCI_PASSTHROUGH isn't available in xen-common.c

  moving CONFIG_XEN_PCI_PASSTHROUGH to be in config_host_mak isn't
  really possible, or at least I didn't managed to make that work.

 hw/i386/pc_piix.c   |  2 +-
 hw/xen/xen-common.c |  4 ++--
 hw/xen/xen_pt.c | 12 +++-
 hw/xen/xen_pt.h |  6 --
 stubs/Makefile.objs |  1 +
 stubs/xen-pt.c  | 22 ++
 6 files changed, 41 insertions(+), 6 deletions(-)
 create mode 100644 stubs/xen-pt.c

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index f66e1d73ce0b..347fb8c6c807 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -375,7 +375,7 @@ static void pc_init_isa(MachineState *machine)
 #ifdef CONFIG_XEN
 static void pc_xen_hvm_init_pci(MachineState *machine)
 {
-const char *pci_type = has_igd_gfx_passthru ?
+const char *pci_type = xen_igd_gfx_pt_enabled() ?
 TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE : 
TYPE_I440FX_PCI_DEVICE;
 
 pc_init1(machine,
diff --git a/hw/xen/xen-common.c b/hw/xen/xen-common.c
index 70564cc952d5..dd2c22cc4c0b 100644
--- a/hw/xen/xen-common.c
+++ b/hw/xen/xen-common.c
@@ -129,12 +129,12 @@ static void xen_change_state_handler(void *opaque, int 
running,
 
 static bool xen_get_igd_gfx_passthru(Object *obj, Error **errp)
 {
-return has_igd_gfx_passthru;
+return xen_igd_gfx_pt_enabled();
 }
 
 static void xen_set_igd_gfx_passthru(Object *obj, bool value, Error **errp)
 {
-has_igd_gfx_passthru = value;
+xen_igd_gfx_pt_set(value, errp);
 }
 
 static void xen_setup_post(MachineState *ms, AccelState *accel)
diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index 81d5ad8da7f0..ab84443d5ec8 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -65,7 +65,17 @@
 #include "qemu/range.h"
 #include "exec/address-spaces.h"
 
-bool has_igd_gfx_passthru;
+static bool has_igd_gfx_passthru;
+
+bool xen_igd_gfx_pt_enabled(void)
+{
+return has_igd_gfx_passthru;
+}
+
+void xen_igd_gfx_pt_set(bool value, Error **errp)
+{
+has_igd_gfx_passthru = value;
+}
 
 #define XEN_PT_NR_IRQS (256)
 static uint8_t xen_pt_mapped_machine_irq[XEN_PT_NR_IRQS] = {0};
diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index 179775db7b22..6e9cec95f3b7 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -5,6 +5,9 @@
 #include "hw/pci/pci.h"
 #include "xen-host-pci-device.h"
 
+bool xen_igd_gfx_pt_enabled(void);
+void xen_igd_gfx_pt_set(bool value, Error **errp);
+
 void xen_pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
 
 #define XEN_PT_ERR(d, _f, _a...) xen_pt_log(d, "%s: Error: "_f, __func__, ##_a)
@@ -322,10 +325,9 @@ extern void *pci_assign_dev_load_option_rom(PCIDevice *dev,
 unsigned int domain,
 unsigned int bus, unsigned int 
slot,
 unsigned int function);
-extern bool has_igd_gfx_passthru;
 static inline bool is_igd_vga_passthrough(XenHostPCIDevice *dev)
 {
-return (has_igd_gfx_passthru
+return (xen_igd_gfx_pt_enabled()
 && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
 }
 int xen_pt_register_vga_regions(XenHostPCIDevice *dev);
diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
index 6a9e3135e8f9..564527e00997 100644
--- a/stubs/Makefile.objs
+++ b/stubs/Makefile.objs
@@ -40,6 +40,7 @@ stub-obj-y += target-get-monitor-def.o
 stub-obj-y += vmgenid.o
 stub-obj-y += xen-common.o
 stub-obj-y += xen-hvm.o
+stub-obj-y += xen-pt.o
 stub-obj-y += pci-host-piix.o
 stub-obj-y += ram-block.o
 stub-obj-y += ramfb.o
diff --git a/stubs/xen-pt.c b/stubs/xen-pt.c
new file mode 100644
index ..2d8cac8d54b9
--- /dev/null
+++ b/stubs/xen-pt.c
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2020   Citrix Systems UK Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/xen/xen_pt.h"
+#include "qapi/error.h"
+
+bool xen_igd_gfx_pt_enabled(void)
+{
+return false;
+}
+
+void 

Re: [Xen-users] xen domU stall on 4.12.1

[Tomas Mozes]

On Wed, Jun 3, 2020 at 5:30 PM Glen  wrote:

> Tomas -
>
> On Tue, Jun 2, 2020 at 7:43 PM Tomas Mozes  wrote:
> >> On Mon, Feb 24, 2020 at 4:55 PM Glen  wrote:
> >>> I'm now going to bring one of the previously-live guests on its own
> >>> host back to credit2 so I can crash it and try to capture debugging
> >>> output for xen-devel as requested.  But sched=credit is definitely
> >>> what we needed to solve this problem!  Thank you all for helping us
> >>> get there!
> > Just tested Xen 4.12.3, but a domU hanged again with credit2. It works
> rock solid with credit1.
>
> I have several hosts back on credit2, no problems so far.  But the
> bulk of my production hosts are still on credit1, and they do seem to
> run "better" (subjectively, looking at responsiveness and load
> averages) but of course by subjectively I mean that I have no real
> data to back this feeling.
>
> I was hoping one of my domU's on credit2 would crash so I could grab
> debugging info for the development team - I hope you are/were able to
> grab and submit data on that crash???
>
> Glen
>

Unfortunately no, it was one of my production hosts so I wanted to get it
back working as quickly as possible.

Tomas

Re: [PATCH v3] xen: fix build without pci passthrough

[Paolo Bonzini]

On 03/06/20 18:04, Anthony PERARD wrote:
> From: Roger Pau Monne 
> 
> Xen PCI passthrough support may not be available and thus the global
> variable "has_igd_gfx_passthru" might be compiled out. Common code
> should not access it in that case.
> 
> Unfortunately, we can't use CONFIG_XEN_PCI_PASSTHROUGH directly in
> xen-common.c so this patch instead move access to the
> has_igd_gfx_passthru variable via function and those functions are
> also implemented as stubs. The stubs will be used when QEMU is built
> without passthrough support.
> 
> Now, when one will want to enable igd-passthru via the -machine
> property, they will get an error message if QEMU is built without
> passthrough support.
> 
> Fixes: 46472d82322d0 ('xen: convert "-machine igd-passthru" to an accelerator 
> property')
> Reported-by: Roger Pau Monné 
> Signed-off-by: Anthony PERARD 
> ---
> 
> Notes:
> Changes in v3:
> - reworked to use stubs instead of #ifdef CONFIG_XEN_PCI_PASSTHROUGH
>   CONFIG_XEN_PCI_PASSTHROUGH isn't available in xen-common.c
> 
>   moving CONFIG_XEN_PCI_PASSTHROUGH to be in config_host_mak isn't
>   really possible, or at least I didn't managed to make that work.
> 
>  hw/i386/pc_piix.c   |  2 +-
>  hw/xen/xen-common.c |  4 ++--
>  hw/xen/xen_pt.c | 12 +++-
>  hw/xen/xen_pt.h |  6 --
>  stubs/Makefile.objs |  1 +
>  stubs/xen-pt.c  | 22 ++
>  6 files changed, 41 insertions(+), 6 deletions(-)
>  create mode 100644 stubs/xen-pt.c
> 
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index f66e1d73ce0b..347fb8c6c807 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -375,7 +375,7 @@ static void pc_init_isa(MachineState *machine)
>  #ifdef CONFIG_XEN
>  static void pc_xen_hvm_init_pci(MachineState *machine)
>  {
> -const char *pci_type = has_igd_gfx_passthru ?
> +const char *pci_type = xen_igd_gfx_pt_enabled() ?
>  TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE : 
> TYPE_I440FX_PCI_DEVICE;
>  
>  pc_init1(machine,
> diff --git a/hw/xen/xen-common.c b/hw/xen/xen-common.c
> index 70564cc952d5..dd2c22cc4c0b 100644
> --- a/hw/xen/xen-common.c
> +++ b/hw/xen/xen-common.c
> @@ -129,12 +129,12 @@ static void xen_change_state_handler(void *opaque, int 
> running,
>  
>  static bool xen_get_igd_gfx_passthru(Object *obj, Error **errp)
>  {
> -return has_igd_gfx_passthru;
> +return xen_igd_gfx_pt_enabled();
>  }
>  
>  static void xen_set_igd_gfx_passthru(Object *obj, bool value, Error **errp)
>  {
> -has_igd_gfx_passthru = value;
> +xen_igd_gfx_pt_set(value, errp);
>  }
>  
>  static void xen_setup_post(MachineState *ms, AccelState *accel)
> diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
> index 81d5ad8da7f0..ab84443d5ec8 100644
> --- a/hw/xen/xen_pt.c
> +++ b/hw/xen/xen_pt.c
> @@ -65,7 +65,17 @@
>  #include "qemu/range.h"
>  #include "exec/address-spaces.h"
>  
> -bool has_igd_gfx_passthru;
> +static bool has_igd_gfx_passthru;
> +
> +bool xen_igd_gfx_pt_enabled(void)
> +{
> +return has_igd_gfx_passthru;
> +}
> +
> +void xen_igd_gfx_pt_set(bool value, Error **errp)
> +{
> +has_igd_gfx_passthru = value;
> +}
>  
>  #define XEN_PT_NR_IRQS (256)
>  static uint8_t xen_pt_mapped_machine_irq[XEN_PT_NR_IRQS] = {0};
> diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
> index 179775db7b22..6e9cec95f3b7 100644
> --- a/hw/xen/xen_pt.h
> +++ b/hw/xen/xen_pt.h
> @@ -5,6 +5,9 @@
>  #include "hw/pci/pci.h"
>  #include "xen-host-pci-device.h"
>  
> +bool xen_igd_gfx_pt_enabled(void);
> +void xen_igd_gfx_pt_set(bool value, Error **errp);
> +
>  void xen_pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3);
>  
>  #define XEN_PT_ERR(d, _f, _a...) xen_pt_log(d, "%s: Error: "_f, __func__, 
> ##_a)
> @@ -322,10 +325,9 @@ extern void *pci_assign_dev_load_option_rom(PCIDevice 
> *dev,
>  unsigned int domain,
>  unsigned int bus, unsigned int 
> slot,
>  unsigned int function);
> -extern bool has_igd_gfx_passthru;
>  static inline bool is_igd_vga_passthrough(XenHostPCIDevice *dev)
>  {
> -return (has_igd_gfx_passthru
> +return (xen_igd_gfx_pt_enabled()
>  && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
>  }
>  int xen_pt_register_vga_regions(XenHostPCIDevice *dev);
> diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
> index 6a9e3135e8f9..564527e00997 100644
> --- a/stubs/Makefile.objs
> +++ b/stubs/Makefile.objs
> @@ -40,6 +40,7 @@ stub-obj-y += target-get-monitor-def.o
>  stub-obj-y += vmgenid.o
>  stub-obj-y += xen-common.o
>  stub-obj-y += xen-hvm.o
> +stub-obj-y += xen-pt.o
>  stub-obj-y += pci-host-piix.o
>  stub-obj-y += ram-block.o
>  stub-obj-y += ramfb.o
> diff --git a/stubs/xen-pt.c b/stubs/xen-pt.c
> new file mode 100644
> index ..2d8cac8d54b9
> --- /dev/null
> +++ b/stubs/xen-pt.c
> @@ -0,0 +1,22 @@
> +/*
> + * Copyright (C) 

Re: Keystone Issue

[Julien Grall]

On 03/06/2020 18:13, CodeWiz2280 wrote:

Hi Julien,


Hello,

In general, we avoid top post on xen-devel, instead we reply inline. I 
believe gmail should allow you to do it :).




The offset is already applied to the memory nodes in the device tree, 
meaning a direct Linux boot from uboot would have only the 36-bit 
addresses in the device tree (0x8__ and 0x8_8000_).  Linux 
would start executing from a 32-bit address space however and then 
switch over to the aliased 36-bit addresses in the device tree as 
discussed below by early_paging_init().


I had to add the 32-bit memory node 0x8000_ in uboot in place of the 
0x8__ node otherwise Xen would detect the 32-bit processor and 
panic on "Unable to detect the first memory bank" in domain_build.c. 


So for 32-bit Xen requires to have the first bank below 4GB. This is 
because you can't boot from a physical address above 32-bit.


Obviously, this check wouldn't work on your platform because all your 
memory will be above 4GB.


If 
I leave only the 36-bit addresses in the device tree and skip past the 
panic check in domain_build.c, then I could not get the dom0 kernel to 
boot at all.  I believe I would only see "Serial input to DOM0" and 
nothing else at that point.


Which would make sense per above.



Yes, leaving LPAE support on for the kernel is preferred.


Ok, so the solution I suggested below should work. Unfortunately, I 
don't have time to work on it. Although, I would be more than happy to 
answers questions and reviewing the patches.


Would you be willing to have a try to implement it?

Cheers,

--
Julien Grall

[PATCH for-4.14] x86/shim: Fix defconfig selection and trim the build further

[Andrew Cooper]

Several options (TBOOT, XENOPROF, Scheduler) depend on EXPERT to be able to
deselect/configure.

Enabling EXPERT now causes the request of the Credit1 scheduler to be honoured
(rather than giving us Credit2), but take this opportunity to switch to Null,
as the previously problematic issues are now believed to be fixed.

Enabling EXPERT also allows XEN_SHSTK to be selected, and we don't want this
being built for shim.  We also don't want TRACEBUFFER or GDBSX either.

Take this oppotunity to swap the disable of HVM_FEP for a general disable of
HVM (likely to have wider impliciations in the future), and disable ARGO (will
necesserily need plumbing work to function in shim).

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Juergen Gross 
CC: Paul Durrant 
CC: Dario Faggioli 
---
 xen/arch/x86/configs/pvshim_defconfig | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/configs/pvshim_defconfig 
b/xen/arch/x86/configs/pvshim_defconfig
index 830660e022..3af48d6c06 100644
--- a/xen/arch/x86/configs/pvshim_defconfig
+++ b/xen/arch/x86/configs/pvshim_defconfig
@@ -5,19 +5,25 @@ CONFIG_PVH_GUEST=y
 CONFIG_PV_SHIM=y
 CONFIG_PV_SHIM_EXCLUSIVE=y
 CONFIG_NR_CPUS=32
+CONFIG_EXPERT=y
+CONFIG_SCHED_NULL=y
 # Disable features not used by the PV shim
+# CONFIG_HVM is not set
+# CONFIG_XEN_SHSTK is not set
 # CONFIG_HYPFS is not set
 # CONFIG_SHADOW_PAGING is not set
 # CONFIG_BIGMEM is not set
-# CONFIG_HVM_FEP is not set
 # CONFIG_TBOOT is not set
 # CONFIG_KEXEC is not set
 # CONFIG_XENOPROF is not set
 # CONFIG_XSM is not set
+# CONFIG_ARGO is not set
+# CONFIG_SCHED_CREDIT is not set
 # CONFIG_SCHED_CREDIT2 is not set
 # CONFIG_SCHED_RTDS is not set
 # CONFIG_SCHED_ARINC653 is not set
-# CONFIG_SCHED_NULL is not set
 # CONFIG_LIVEPATCH is not set
 # CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS is not set
+# CONFIG_TRACEBUFFER is not set
 # CONFIG_DEBUG is not set
+# CONFIG_GDBSX is not set
-- 
2.11.0

Re: [PATCH v3] xen: fix build without pci passthrough

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200603160442.3151170-1-anthony.per...@citrix.com/



Hi,

This series failed the docker-mingw@fedora build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#! /bin/bash
export ARCH=x86_64
make docker-image-fedora V=1 NETWORK=1
time make docker-test-mingw@fedora J=14 NETWORK=1
=== TEST SCRIPT END ===

  CC  io/channel-socket.o
In file included from /tmp/qemu-test/src/hw/xen/xen_pt.h:4,
 from /tmp/qemu-test/src/stubs/xen-pt.c:9:
/tmp/qemu-test/src/include/hw/xen/xen_common.h:13:10: fatal error: xenctrl.h: 
No such file or directory
 #include 
  ^~~
compilation terminated.
make: *** [/tmp/qemu-test/src/rules.mak:69: stubs/xen-pt.o] Error 1
make: *** Waiting for unfinished jobs
  CC  io/channel-tls.o
  CC  io/channel-watch.o
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', 
'--label', 'com.qemu.instance.uuid=cd03ecea4c4345298864529c8bd56cc2', '-u', 
'1001', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', 
'-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-fmy3mf1z/src/docker-src.2020-06-03-13.42.19.22059:/var/tmp/qemu:z,ro',
 'qemu:fedora', '/var/tmp/qemu/run', 'test-mingw']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=cd03ecea4c4345298864529c8bd56cc2
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-fmy3mf1z/src'
make: *** [docker-run-test-mingw@fedora] Error 2

real2m17.803s
user0m9.104s


The full log is available at
http://patchew.org/logs/20200603160442.3151170-1-anthony.per...@citrix.com/testing.docker-mingw@fedora/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

[xen-unstable-smoke test] 150658: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 12 guest-start  fail REGR. vs. 150438

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

version targeted for testing:
 xen  d9f58cd54fe2f05e1f05e2fe254684bd1840de8e
baseline version:
 xen  1497e78068421d83956f8e82fb6e1bf1fc3b1199

Last test of basis   150438  2020-05-28 14:01:19 Z6 days
Failing since150465  2020-05-29 09:02:14 Z5 days   40 attempts
Testing same since   150649  2020-06-03 13:01:44 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andrew Cooper 
  Anthony PERARD 
  Dario Faggioli 
  Ian Jackson 
  Jan Beulich 
  Jason Andryuk 
  Juergen Gross 
  Julien Grall 
  Olaf Hering 
  Paul Durrant 
  Paul Durrant 
  Roger Pau Monné 
  Tamas K Lengyel 
  Wei Liu 

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 fail



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.

(No revision log; it would be 1522 lines long.)

[ovmf test] 150653: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 7191dd3c5990416cf473ce36b3fb84ecb2f7b950
baseline version:
 ovmf ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9

Last test of basis   150614  2020-06-02 08:10:08 Z1 days
Testing same since   150653  2020-06-03 14:09:17 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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
   ca407c7246..7191dd3c59  7191dd3c5990416cf473ce36b3fb84ecb2f7b950 -> 
xen-tested-master

Re: [PATCH v3] xen: fix build without pci passthrough

[Roger Pau Monné]

On Wed, Jun 03, 2020 at 05:04:42PM +0100, Anthony PERARD wrote:
> From: Roger Pau Monne 
> 
> Xen PCI passthrough support may not be available and thus the global
> variable "has_igd_gfx_passthru" might be compiled out. Common code
> should not access it in that case.
> 
> Unfortunately, we can't use CONFIG_XEN_PCI_PASSTHROUGH directly in
> xen-common.c so this patch instead move access to the
> has_igd_gfx_passthru variable via function and those functions are
> also implemented as stubs. The stubs will be used when QEMU is built
> without passthrough support.
> 
> Now, when one will want to enable igd-passthru via the -machine
> property, they will get an error message if QEMU is built without
> passthrough support.
> 
> Fixes: 46472d82322d0 ('xen: convert "-machine igd-passthru" to an accelerator 
> property')
> Reported-by: Roger Pau Monné 
> Signed-off-by: Anthony PERARD 

Tested-by: Roger Pau Monné 

Fixes the build for me on FreeBSD without pci-passthrough.

Thanks!

Re: Keystone Issue

[CodeWiz2280]

Hi Julien,

The offset is already applied to the memory nodes in the device tree,
meaning a direct Linux boot from uboot would have only the 36-bit addresses
in the device tree (0x8__ and 0x8_8000_).  Linux would start
executing from a 32-bit address space however and then switch over to the
aliased 36-bit addresses in the device tree as discussed below by
early_paging_init().

I had to add the 32-bit memory node 0x8000_ in uboot in place of the
0x8__ node otherwise Xen would detect the 32-bit processor and
panic on "Unable to detect the first memory bank" in domain_build.c.  If I
leave only the 36-bit addresses in the device tree and skip past the panic
check in domain_build.c, then I could not get the dom0 kernel to boot at
all.  I believe I would only see "Serial input to DOM0" and nothing else at
that point.

Yes, leaving LPAE support on for the kernel is preferred.

Thank you for your help in this matter.

Respectfully,
Dave

On Wed, Jun 3, 2020 at 7:32 AM Julien Grall  wrote:

> (+Bertrand and Stefano)
>
> On 01/06/2020 18:38, CodeWiz2280 wrote:
> > Hi Julien,
>
> Hi Dave,
>
> >
> > As requested please see log below from the eval board booting dom0, some
> > notes are as follows:
>
> Thanks for the logs and the notes. They are useful to understand your
> issue.
>
> > 1. The offset that gets applied to the 32-bit address to translate it
> > to 36-bits is 0x7_8000_
>
> Is this offset present in the Device-Tree?
>
> > 2. Uboot has been setup to not change the address of the memory in the
> > device tree prior to launching xen, otherwise it would
> > automatically offset it and replace it with a 36-bit address and xen
> > would immediately panic at the 36-bit address for a 32-bit processor.
>
> What is the list of the memory banks Xen will see?
>
> Xen is able to support 36-bit address, can you point to the panic() you
> are hitting?
>
> > 3. The RAM starting address placed in the device tree is 0x8000_,
> > which gets carved up by xen and replaced with 0xA000_ prior to
> > booting dom0..  I had to put in test code to have the kernel offset the
> > 0xA000_ 32-bit starting address to the 36-bit address needed before
> > the kernel will attempt to switch.  If it stays 32-bit then it will not
> > switch over the address space.  Note that without xen in play uboot
> > would normally replace the address in the device tree with the 36-bit
> one.
>
> IIUC, in the case of Linux boot directly, the Device-Tree will not
> describe the low memory range. Is that correct?
>
> > 4. The dom0 kernel will boot from xen if the early_paging_init switch
> > step is skipped, and the low mem stays in 32-bitbut there is a
> > problem with the peripherals so this is not an acceptable solution.
>
> Can you details a bit more the problem with the peripherals?
>
> >
> > It seems that either the kernel would need some API to tell xen that
> > there is going to be a change in the memory its using prior to call
> > early_paging_init(),
>
>  From my understanding, the problem is very specific to the KeyStone. So
> I would rather avoid to introduce an hypercall specific to your
> platform. But...
>
> > or Xen would need to add the additional 36-bit
> > addresses during the memory bank allocation stepbut recognize that
> > they are not actually different physical memory but just aliased to a
> > different address.
>
> ... I think it is possible to fix it entirely in Xen without any
> modification in the device-tree.
>
> It is seems better that Xen treats the low memory region as "not usable"
> and only use the high memory region internally. When allocating a Dom0
> memory banks, it would need to ensure that there is a corresponding
> alias in low memory.
>
> Xen will also need to do two mappings in the Dom0 stage-2 page-tables.
> The extra one is for the alias.
>
> This approach will prevent to use hypercall buffer from low memory and
> therefore require your guest to support LPAE. Is it going to be an issue
> for you?
>
> Cheers,
>
> --
> Julien Grall
>

Re: Keystone Issue

[CodeWiz2280]

On Wed, Jun 3, 2020 at 2:09 PM Julien Grall  wrote:
>
>
>
> On 03/06/2020 18:13, CodeWiz2280 wrote:
> > Hi Julien,
>
> Hello,
>
> In general, we avoid top post on xen-devel, instead we reply inline. I
> believe gmail should allow you to do it :).
>
I'm sorry about that.  Hopefully this looks right now.
> >
> > The offset is already applied to the memory nodes in the device tree,
> > meaning a direct Linux boot from uboot would have only the 36-bit
> > addresses in the device tree (0x8__ and 0x8_8000_).  Linux
> > would start executing from a 32-bit address space however and then
> > switch over to the aliased 36-bit addresses in the device tree as
> > discussed below by early_paging_init().
> >
> > I had to add the 32-bit memory node 0x8000_ in uboot in place of the
> > 0x8__ node otherwise Xen would detect the 32-bit processor and
> > panic on "Unable to detect the first memory bank" in domain_build.c.
>
> So for 32-bit Xen requires to have the first bank below 4GB. This is
> because you can't boot from a physical address above 32-bit.
>
> Obviously, this check wouldn't work on your platform because all your
> memory will be above 4GB.
>
> > If
> > I leave only the 36-bit addresses in the device tree and skip past the
> > panic check in domain_build.c, then I could not get the dom0 kernel to
> > boot at all.  I believe I would only see "Serial input to DOM0" and
> > nothing else at that point.
>
> Which would make sense per above.
>
> >
> > Yes, leaving LPAE support on for the kernel is preferred.
>
> Ok, so the solution I suggested below should work. Unfortunately, I
> don't have time to work on it. Although, I would be more than happy to
> answers questions and reviewing the patches.
>
> Would you be willing to have a try to implement it?
>
Unfortunately, I am not familiar enough with the Xen codebase to
attempt to make the changes.  Thank you for your support and insight.

> Cheers,
>
> --
> Julien Grall

Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU

[Stefano Stabellini]

On Wed, 3 Jun 2020, Corey Minyard wrote:
> On Tue, Jun 02, 2020 at 12:24:05PM -0700, Stefano Stabellini wrote:
> > On Tue, 2 Jun 2020, Corey Minyard wrote:
> > > Snip
> > > 
> > > > > > > > whether
> > > > > > > > this was already done:
> > > > > > > >  1) Does the kernel boot on baremetal (i.e without Xen)? 
> > > > > > > > This should
> > > > > > > > help
> > > > > > > > to confirm whether the bug is Xen is related.
> > > > > > > 
> > > > > > > Yes it boots
> > > > > > > 
> > > > > > > >  2) Swiotlb should not be necessary for basic dom0 boot on 
> > > > > > > > Arm. Did
> > > > > > > > you try
> > > > > > > > to disable it? This should help to confirm whether swiotlb is 
> > > > > > > > the
> > > > > > > > problem or
> > > > > > > > not.
> > > > > > > 
> > > > > > > It boots disabling swiotlb-xen
> > > > > > 
> > > > > > Thank you for the answer! swiotlb-xen should basically be a NOP for 
> > > > > > dom0. So
> > > > > > this suggests swiotlb is doing some transformation on the DMA 
> > > > > > address.
> > > > > > 
> > > > > > I have an idea what may have gone wrong. AFAICT, xen-swiotlb seems 
> > > > > > to assume
> > > > > > the DMA address space and CPU address space is the same. Is RPI 
> > > > > > using the
> > > > > > same address space?
> > > > > 
> > > > > Another question, is the DMA request bounced? If so, are we sure the 
> > > > > bounce
> > > > > buffer is in the first GB?
> > > > 
> > > > Yes, it is. This is actually where we spent the last few days, and I
> > > > found another little related bug in the initialization of the
> > > > swiotlb-xen but now I am sure the memory is under 1GB 
> > > > (0x3400-0x3800)
> > > 
> > > Was anything ever resolved on this issue?  It just kind of ended for me,
> > > and I looked in the main kernel and didn't find anything that looked
> > > related.
> > 
> > Yes, we have a patch series on the list for the Linux kernel to fix this
> > issue but it hasn't been merged yet:
> > 
> > https://marc.info/?l=linux-kernel=159001831406263=2
> 
> Just FYI, I pulled the changes on top of
>   https://github.com/raspberrypi/linux.git rpi-5.4.y
> Along with change
>   56e35f9c5b87ec dma-mapping: drop the dev argument to arch_sync_dma_for_*
> before the series so it applies on 5.4, and I was able to boot and
> create a domU.  So:
> 
> Tested-by: Corey Minyard 
> 
> At least on 5.4.  If you think it would be valuable, I can test on
> rpi-5.7.y.

I'd feel better adding your Tested-by to my next upstream submission of
the series if you could also test on 5.7. Thank you in advance!


> I'll be integrating this in with our Pi Xen yocto layer at
> https://github.com/MontaVista-OpenSourceTechnology/meta-raspberrypi-xen

That's great!

Re: Re [PATCH] x86/CET: Fix build following c/s 43b98e7190

[Jan Beulich]

On 03.06.2020 13:44, Andrew Cooper wrote:
> On 03/06/2020 10:50, Jan Beulich wrote:
>> On 02.06.2020 19:15, Andrew Cooper wrote:
>>> On 02/06/2020 15:21, Jan Beulich wrote:
> OSSTest reports:
>
>   x86_64.S: Assembler messages:
>   x86_64.S:57: Error: no such instruction: `setssbsy'
>   /home/osstest/build.150510.build-amd64/xen/xen/Rules.mk:183: recipe for 
> target 'head.o' failed
>   make[4]: Leaving directory 
> '/home/osstest/build.150510.build-amd64/xen/xen/arch/x86/boot'
>   make[4]: *** [head.o] Error 1
>
> All use of CET instructions, even those inside alternative blocks, needs 
> to be
> behind CONFIG_XEN_SHSTK, as it indicates suitable toolchain support.
>
> Signed-off-by: Andrew Cooper 
 That's quite a bit of #ifdef-ary here. Simple (operand-less) insns
 like SETSSBSY could easily be made available via .byte directives.
 Would you be amenable to to ack-ing a patch to replace some of the
 #ifdef-s (at least the ones at the lstar, cstar, and sysenter
 entry points), after 4.14?
>>> Yeah - that was a bit of a mess in the end.  (But given the
>>> circumstances, and that I've got past form typo'ing the SETSSBSY opcode,
>>> it probably was the right move even in hindsight).
>>>
>>> Reducing it to .byte should be fine so long as some form of /* setssbsy
>>> */ comment appears.
>> Sure.
>>
>>> One other option would be to introduce a SETSSBSY macro, but that hides
>>> the alternative so is something I'd prefer to avoid.
>> With this you mean you'd rather not see us go the CLAC/STAC route?
>> I was instead thinking of a pure assembly macro named "setssbsy".
>> In fact we could switch the CLAC/STAC ugliness to some such, if we
>> end up being happy with the model.
> 
> The thing about the current STAC / CLAC is that, as written, they give
> the impression of being unconditional.  This is poor in terms of code
> clarity.
> 
> Furthermore, making them indistinguishable from the plain instructions
> is definitely a no-go, because then we've got assembly source (again,
> which appears unconditional) which doesn't match its disassembly (the
> backing nops) - at least with the macros in upper case, it is obvious
> that something is up, even if you have to searching for why.
> 
> If we went for pure assembly macros with an alt_ or maybe_ prefix, then
> that would be reasonable.  It looks as close to regular instruction as
> possible, but also makes it explicitly clear that it is conditional.

That wasn't the plan - I didn't mean to hide the alternatives aspect.
I wanted to have simple "setssbsy", "clac", and "stac" macros expanding
to just the insns, getting instantiated when !HAVE_AS_. This
would make assembly code look descriptive no matter what assembler
capabilities there are (for these operand-less insns, that is, not in
general).

Jan

Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU

[Corey Minyard]

On Tue, Jun 02, 2020 at 12:24:05PM -0700, Stefano Stabellini wrote:
> On Tue, 2 Jun 2020, Corey Minyard wrote:
> > Snip
> > 
> > > > > > > whether
> > > > > > > this was already done:
> > > > > > >  1) Does the kernel boot on baremetal (i.e without Xen)? This 
> > > > > > > should
> > > > > > > help
> > > > > > > to confirm whether the bug is Xen is related.
> > > > > > 
> > > > > > Yes it boots
> > > > > > 
> > > > > > >  2) Swiotlb should not be necessary for basic dom0 boot on 
> > > > > > > Arm. Did
> > > > > > > you try
> > > > > > > to disable it? This should help to confirm whether swiotlb is the
> > > > > > > problem or
> > > > > > > not.
> > > > > > 
> > > > > > It boots disabling swiotlb-xen
> > > > > 
> > > > > Thank you for the answer! swiotlb-xen should basically be a NOP for 
> > > > > dom0. So
> > > > > this suggests swiotlb is doing some transformation on the DMA address.
> > > > > 
> > > > > I have an idea what may have gone wrong. AFAICT, xen-swiotlb seems to 
> > > > > assume
> > > > > the DMA address space and CPU address space is the same. Is RPI using 
> > > > > the
> > > > > same address space?
> > > > 
> > > > Another question, is the DMA request bounced? If so, are we sure the 
> > > > bounce
> > > > buffer is in the first GB?
> > > 
> > > Yes, it is. This is actually where we spent the last few days, and I
> > > found another little related bug in the initialization of the
> > > swiotlb-xen but now I am sure the memory is under 1GB 
> > > (0x3400-0x3800)
> > 
> > Was anything ever resolved on this issue?  It just kind of ended for me,
> > and I looked in the main kernel and didn't find anything that looked
> > related.
> 
> Yes, we have a patch series on the list for the Linux kernel to fix this
> issue but it hasn't been merged yet:
> 
> https://marc.info/?l=linux-kernel=159001831406263=2

Just FYI, I pulled the changes on top of
  https://github.com/raspberrypi/linux.git rpi-5.4.y
Along with change
  56e35f9c5b87ec dma-mapping: drop the dev argument to arch_sync_dma_for_*
before the series so it applies on 5.4, and I was able to boot and
create a domU.  So:

Tested-by: Corey Minyard 

At least on 5.4.  If you think it would be valuable, I can test on
rpi-5.7.y.  I'll be integrating this in with our Pi Xen yocto layer at
https://github.com/MontaVista-OpenSourceTechnology/meta-raspberrypi-xen

Thanks again,

-corey

Re: [Xen-users] xen domU stall on 4.12.1

[Glen]

Tomas -

On Tue, Jun 2, 2020 at 7:43 PM Tomas Mozes  wrote:
>> On Mon, Feb 24, 2020 at 4:55 PM Glen  wrote:
>>> I'm now going to bring one of the previously-live guests on its own
>>> host back to credit2 so I can crash it and try to capture debugging
>>> output for xen-devel as requested.  But sched=credit is definitely
>>> what we needed to solve this problem!  Thank you all for helping us
>>> get there!
> Just tested Xen 4.12.3, but a domU hanged again with credit2. It works rock 
> solid with credit1.

I have several hosts back on credit2, no problems so far.  But the
bulk of my production hosts are still on credit1, and they do seem to
run "better" (subjectively, looking at responsiveness and load
averages) but of course by subjectively I mean that I have no real
data to back this feeling.

I was hoping one of my domU's on credit2 would crash so I could grab
debugging info for the development team - I hope you are/were able to
grab and submit data on that crash???

Glen

Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update)

[Pavel Hrdina]

On Tue, Jun 02, 2020 at 04:47:45PM +0100, Ian Jackson wrote:
> Prior to 2621d48f005a "gnulib: delete all gnulib integration",
> one could pass ./autogen.sh --no-git to prevent the libvirt build
> system from running git submodule update.
> 
> This feature is needed by systems like the Xen Project CI which want
> to explicitly control the revisions of every tree.  These will
> typically arrange to initialise the submodules check out the right
> version of everything, and then expect the build system not to mess
> with it any more.
> 
> Despite to the old documentation comments referring only to gnulib,
> the --no-git feature is required not only because of gnulib but also
> because of the other submodule, src/keycodemapdb.
> 
> (And in any case, even if it were no longer required because all the
> submodules were removed, it ought ideally to have been retained as a
> no-op for compaibility reasons.)
> 
> So restore the --no-git feature.
> 
> Because of the way the argument parsing of autogen.sh works, it is
> easiest to recognise this option only if it comes first.  This works
> for the Xen Project CI, which has always passed this option first.
> 
> If something else is using this option (and hasn't introduced a
> different workaround in the meantime), not in the first position,
> then perhaps a more sophisticated approach will be needed.  But I
> think this will do for now.
> 
> Signed-off-by: Ian Jackson 
> ---
>  autogen.sh | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/autogen.sh b/autogen.sh
> index 4e1bbceb0a..1c98273452 100755
> --- a/autogen.sh
> +++ b/autogen.sh
> @@ -1,5 +1,10 @@
>  #!/bin/sh
>  # Run this to generate all the initial makefiles, etc.
> +#
> +# THe following options must come first.  All other or subsequent
> +# arguments are passed to configure:
> +#   --no-git   skip `git submodule update --init`
> +
>  test -n "$srcdir" || srcdir=$(dirname "$0")
>  test -n "$srcdir" || srcdir=.
>  
> @@ -13,7 +18,11 @@ cd "$srcdir"
>  exit 1
>  }
>  
> -git submodule update --init || exit 1
> +if [ "x$1" = x--no-git ]; then
> + shift
> +else
> + git submodule update --init || exit 1

I changed the TAB into spaces.

> +fi
>  
>  autoreconf --verbose --force --install || exit 1

Reviewed-by: Pavel Hrdina 

and pushed.


signature.asc
Description: PGP signature

[xen-unstable test] 150635: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  1497e78068421d83956f8e82fb6e1bf1fc3b1199
baseline version:
 xen  1497e78068421d83956f8e82fb6e1bf1fc3b1199

Last test of basis   150635  2020-06-03 01:52:00 Z0 days
Testing same since  (not found) 0 attempts

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  

[xen-unstable-smoke test] 150646: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 12 guest-start  fail REGR. vs. 150438

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

version targeted for testing:
 xen  99a76a88d5e7f4693bb6b286e366006e1da1c954
baseline version:
 xen  1497e78068421d83956f8e82fb6e1bf1fc3b1199

Last test of basis   150438  2020-05-28 14:01:19 Z5 days
Failing since150465  2020-05-29 09:02:14 Z5 days   38 attempts
Testing same since   150629  2020-06-02 21:00:40 Z0 days5 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andrew Cooper 
  Anthony PERARD 
  Dario Faggioli 
  Ian Jackson 
  Jan Beulich 
  Jason Andryuk 
  Juergen Gross 
  Julien Grall 
  Olaf Hering 
  Paul Durrant 
  Paul Durrant 
  Roger Pau Monné 
  Tamas K Lengyel 
  Wei Liu 

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 fail



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.

(No revision log; it would be 1494 lines long.)

Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update)

[Ian Jackson]

Pavel Hrdina writes ("Re: [PATCH] autogen.sh: Restore --no-git (avoid git 
submodule update)"):
> There should not be any need to disable this explicitly unless you want
> to build libvirt with different revisions of submodules.

The Xen Project CI has a cross-tree bisector.  It is capable of
automatically selecting revisions, including revisions of submodules,
for testing.

It therefore needs to be able to build with different revisions of
submodules, indeed.

Thanks,
Ian.

Re: [PATCH v3 for-4.14] x86/monitor: revert default behavior when monitoring register write events

[Roger Pau Monné]

On Wed, Jun 03, 2020 at 06:25:31AM -0600, Tamas K Lengyel wrote:
> On Wed, Jun 3, 2020 at 2:28 AM Roger Pau Monné  wrote:
> >
> > On Tue, Jun 02, 2020 at 07:49:09AM -0600, Tamas K Lengyel wrote:
> > > diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
> > > index 8aa14137e2..36894b33a4 100644
> > > --- a/xen/arch/x86/hvm/monitor.c
> > > +++ b/xen/arch/x86/hvm/monitor.c
> > > @@ -53,11 +53,11 @@ bool hvm_monitor_cr(unsigned int index, unsigned long 
> > > value, unsigned long old)
> > >  .u.write_ctrlreg.old_value = old
> > >  };
> > >
> > > -if ( monitor_traps(curr, sync, ) >= 0 )
> > > -return 1;
> > > +return monitor_traps(curr, sync, ) >= 0 &&
> > > +curr->domain->arch.monitor.control_register_values;
> >
> > Nit (it can be fixed while committing IMO): curr should be aligned to
> > monitor.
> 
> This is the established style already in-place, see
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/monitor.c;h=8aa14137e25a47d3826843441e244decf81dc855;hb=refs/heads/staging#l76:
> 
>   76 return curr->domain->arch.monitor.emul_unimplemented_enabled &&
>   77 monitor_traps(curr, true, ) == 1;
> 
> I don't really care either way but at least we should be consistent.

Oh, OK. This is slightly different from the indentation that I tend to
use, sorry for the request then.

Roger.

Re: [PATCH v3 for-4.14] x86/monitor: revert default behavior when monitoring register write events

[Tamas K Lengyel]

On Wed, Jun 3, 2020 at 7:57 AM Roger Pau Monné  wrote:
>
> On Wed, Jun 03, 2020 at 06:25:31AM -0600, Tamas K Lengyel wrote:
> > On Wed, Jun 3, 2020 at 2:28 AM Roger Pau Monné  wrote:
> > >
> > > On Tue, Jun 02, 2020 at 07:49:09AM -0600, Tamas K Lengyel wrote:
> > > > diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
> > > > index 8aa14137e2..36894b33a4 100644
> > > > --- a/xen/arch/x86/hvm/monitor.c
> > > > +++ b/xen/arch/x86/hvm/monitor.c
> > > > @@ -53,11 +53,11 @@ bool hvm_monitor_cr(unsigned int index, unsigned 
> > > > long value, unsigned long old)
> > > >  .u.write_ctrlreg.old_value = old
> > > >  };
> > > >
> > > > -if ( monitor_traps(curr, sync, ) >= 0 )
> > > > -return 1;
> > > > +return monitor_traps(curr, sync, ) >= 0 &&
> > > > +curr->domain->arch.monitor.control_register_values;
> > >
> > > Nit (it can be fixed while committing IMO): curr should be aligned to
> > > monitor.
> >
> > This is the established style already in-place, see
> > http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/monitor.c;h=8aa14137e25a47d3826843441e244decf81dc855;hb=refs/heads/staging#l76:
> >
> >   76 return curr->domain->arch.monitor.emul_unimplemented_enabled &&
> >   77 monitor_traps(curr, true, ) == 1;
> >
> > I don't really care either way but at least we should be consistent.
>
> Oh, OK. This is slightly different from the indentation that I tend to
> use, sorry for the request then.

I made the change regardless. Feel free to re-adjust the style or
change the alignment of the above return on commit.

Thanks,
Tamas

[xen-unstable-smoke test] 150649: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 12 guest-start  fail REGR. vs. 150438

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

version targeted for testing:
 xen  d9f58cd54fe2f05e1f05e2fe254684bd1840de8e
baseline version:
 xen  1497e78068421d83956f8e82fb6e1bf1fc3b1199

Last test of basis   150438  2020-05-28 14:01:19 Z6 days
Failing since150465  2020-05-29 09:02:14 Z5 days   39 attempts
Testing same since   150649  2020-06-03 13:01:44 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andrew Cooper 
  Anthony PERARD 
  Dario Faggioli 
  Ian Jackson 
  Jan Beulich 
  Jason Andryuk 
  Juergen Gross 
  Julien Grall 
  Olaf Hering 
  Paul Durrant 
  Paul Durrant 
  Roger Pau Monné 
  Tamas K Lengyel 
  Wei Liu 

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 fail



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.

(No revision log; it would be 1522 lines long.)

[PATCH v4 for-4.14] x86/monitor: revert default behavior when monitoring register write events

[Tamas K Lengyel]

For the last couple years we have received numerous reports from users of
monitor vm_events of spurious guest crashes when using events. In particular,
it has observed that the problem occurs when vm_events are being disabled. The
nature of the guest crash varied widely and has only occured occasionally. This
made debugging the issue particularly hard. We had discussions about this issue
even here on the xen-devel mailinglist with no luck figuring it out.

The bug has now been identified as a race-condition between register event
handling and disabling the monitor vm_event interface. The default behavior
regarding emulation of register write events is changed so that they get
postponed until the corresponding vm_event handler decides whether to allow such
write to take place. Unfortunately this can only be implemented by performing 
the
deny/allow step when the vCPU gets scheduled.

Due to that postponed emulation of the event if the user decides to pause the
VM in the vm_event handler and then disable events, the entire emulation step
is skipped the next time the vCPU is resumed. Even if the user doesn't pause
during the vm_event handling but exits immediately and disables vm_event, the
situation becomes racey as disabling vm_event may succeed before the guest's
vCPUs get scheduled with the pending emulation task. This has been particularly
the case with VMS that have several vCPUs as after the VM is unpaused it may
actually take a long time before all vCPUs get scheduled.

In this patch we are reverting the default behavior to always perform emulation
of register write events when the event occurs. To postpone them can be turned
on as an option. In that case the user of the interface still has to take care
of only disabling the interface when its safe as it remains buggy.

Fixes: 96760e2fba10 ('vm_event: deny register writes if refused by vm_event
reply').

Signed-off-by: Tamas K Lengyel 
---
 xen/arch/x86/hvm/hvm.c| 14 --
 xen/arch/x86/hvm/monitor.c| 13 -
 xen/include/asm-x86/domain.h  |  1 +
 xen/include/asm-x86/hvm/monitor.h |  7 +++
 xen/include/asm-x86/monitor.h |  4 
 xen/include/public/domctl.h   |  6 ++
 6 files changed, 30 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 74c9f84462..5bb47583b3 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3601,13 +3601,15 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 
 ASSERT(v->arch.vm_event);
 
-/* The actual write will occur in hvm_do_resume() (if permitted). */
-v->arch.vm_event->write_data.do_write.msr = 1;
-v->arch.vm_event->write_data.msr = msr;
-v->arch.vm_event->write_data.value = msr_content;
+if ( hvm_monitor_msr(msr, msr_content, msr_old_content) )
+{
+/* The actual write will occur in hvm_do_resume(), if permitted. */
+v->arch.vm_event->write_data.do_write.msr = 1;
+v->arch.vm_event->write_data.msr = msr;
+v->arch.vm_event->write_data.value = msr_content;
 
-hvm_monitor_msr(msr, msr_content, msr_old_content);
-return X86EMUL_OKAY;
+return X86EMUL_OKAY;
+}
 }
 
 if ( (ret = guest_wrmsr(v, msr, msr_content)) != X86EMUL_UNHANDLEABLE )
diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index 8aa14137e2..e4a09964a0 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -53,11 +53,11 @@ bool hvm_monitor_cr(unsigned int index, unsigned long 
value, unsigned long old)
 .u.write_ctrlreg.old_value = old
 };
 
-if ( monitor_traps(curr, sync, ) >= 0 )
-return 1;
+return monitor_traps(curr, sync, ) >= 0 &&
+   curr->domain->arch.monitor.control_register_values;
 }
 
-return 0;
+return false;
 }
 
 bool hvm_monitor_emul_unimplemented(void)
@@ -77,7 +77,7 @@ bool hvm_monitor_emul_unimplemented(void)
 monitor_traps(curr, true, ) == 1;
 }
 
-void hvm_monitor_msr(unsigned int msr, uint64_t new_value, uint64_t old_value)
+bool hvm_monitor_msr(unsigned int msr, uint64_t new_value, uint64_t old_value)
 {
 struct vcpu *curr = current;
 
@@ -92,8 +92,11 @@ void hvm_monitor_msr(unsigned int msr, uint64_t new_value, 
uint64_t old_value)
 .u.mov_to_msr.old_value = old_value
 };
 
-monitor_traps(curr, 1, );
+return monitor_traps(curr, 1, ) >= 0 &&
+   curr->domain->arch.monitor.control_register_values;
 }
+
+return false;
 }
 
 void hvm_monitor_descriptor_access(uint64_t exit_info,
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index e8cee3d5e5..6fd94c2e14 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -418,6 +418,7 @@ struct arch_domain
  * This is used to filter out pagefaults.
  */
 unsigned int 

Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update)

[Ian Jackson]

Pavel Hrdina writes ("Re: [PATCH] autogen.sh: Restore --no-git (avoid git 
submodule update)"):
> To be honest I don't understand why would anyone want to keep track of
> all submodules of all projects for any CI and update it manually every
> time the upstream project changes these submodules. Sounds like a lot
> of unnecessary work but maybe I'm missing something.

Maybe I should answer this.  The short answer is that this can be done
entirely automatically.

> Well, we will break a lot more by switching to Meson build system where
> everyone building libvirt will have to change their scripts as it will
> not be compatible at all.

When that occurs we'll have to change our build rune, of course.

Our CI system (which does bisection and stable tracking and so on)
will wants to build old versions, so it'll have to have both build
runes and look for something in-tree to tell the two methods apart.

Thanks,
Ian.

Re: [PATCH v4 for-4.14] x86/monitor: revert default behavior when monitoring register write events

[Roger Pau Monné]

On Wed, Jun 03, 2020 at 06:52:37AM -0600, Tamas K Lengyel wrote:
> For the last couple years we have received numerous reports from users of
> monitor vm_events of spurious guest crashes when using events. In particular,
> it has observed that the problem occurs when vm_events are being disabled. The
> nature of the guest crash varied widely and has only occured occasionally. 
> This
> made debugging the issue particularly hard. We had discussions about this 
> issue
> even here on the xen-devel mailinglist with no luck figuring it out.
> 
> The bug has now been identified as a race-condition between register event
> handling and disabling the monitor vm_event interface. The default behavior
> regarding emulation of register write events is changed so that they get
> postponed until the corresponding vm_event handler decides whether to allow 
> such
> write to take place. Unfortunately this can only be implemented by performing 
> the
> deny/allow step when the vCPU gets scheduled.
> 
> Due to that postponed emulation of the event if the user decides to pause the
> VM in the vm_event handler and then disable events, the entire emulation step
> is skipped the next time the vCPU is resumed. Even if the user doesn't pause
> during the vm_event handling but exits immediately and disables vm_event, the
> situation becomes racey as disabling vm_event may succeed before the guest's
> vCPUs get scheduled with the pending emulation task. This has been 
> particularly
> the case with VMS that have several vCPUs as after the VM is unpaused it may
> actually take a long time before all vCPUs get scheduled.
> 
> In this patch we are reverting the default behavior to always perform 
> emulation
> of register write events when the event occurs. To postpone them can be turned
> on as an option. In that case the user of the interface still has to take care
> of only disabling the interface when its safe as it remains buggy.
> 
> Fixes: 96760e2fba10 ('vm_event: deny register writes if refused by vm_event
> reply').
> 
> Signed-off-by: Tamas K Lengyel 

Thanks!

Reviewed-by: Roger Pau Monné 

I would like to get some input from Bitdefender really, and whether
they are fine with this approach.

[PATCH] xen-netback: use kstrdup() in connect_data_rings()

[Denis Efremov]

Use kstrdup() instead of opencoded alloc and copy. kzalloc() is
excessive here.

Signed-off-by: Denis Efremov 
---
 drivers/net/xen-netback/xenbus.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 286054b60d47..69352154a51b 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -839,13 +839,12 @@ static int connect_data_rings(struct backend_info *be,
 * queue-N.
 */
if (num_queues == 1) {
-   xspath = kzalloc(strlen(dev->otherend) + 1, GFP_KERNEL);
+   xspath = kstrdup(dev->otherend, GFP_KERNEL);
if (!xspath) {
xenbus_dev_fatal(dev, -ENOMEM,
 "reading ring references");
return -ENOMEM;
}
-   strcpy(xspath, dev->otherend);
} else {
xspathsize = strlen(dev->otherend) + xenstore_path_ext_size;
xspath = kzalloc(xspathsize, GFP_KERNEL);
-- 
2.26.2

Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update)

[Ian Jackson]

Pavel Hrdina writes ("Re: [PATCH] autogen.sh: Restore --no-git (avoid git 
submodule update)"):
> On Tue, Jun 02, 2020 at 04:47:45PM +0100, Ian Jackson wrote:
> > -git submodule update --init || exit 1
> > +if [ "x$1" = x--no-git ]; then
> > +   shift
> > +else
> > +   git submodule update --init || exit 1
> 
> I changed the TAB into spaces.

Ah, sorry for not following the right style.

> Reviewed-by: Pavel Hrdina 
> 
> and pushed.

Thanks :-).

Ian.

Re: [Xen-devel] [RFC 1/9] schedule: Introduce per-pcpu time accounting

[Dario Faggioli]

On Tue, 2020-06-02 at 01:12 +, Volodymyr Babchuk wrote:
> On Fri, 2020-05-29 at 10:48 +0200, Dario Faggioli wrote:
> > 
> Actually, I tried to not only rebase this patch series to the current
> mainline, but also to add x86 support. This gave me deeper
> unsterstanding of the inner workings. At least I hope so :)
> 
Right.

> Anyways, I want to discuss the matter before continuing reworking the
> patches. The goal of those patches is to account guest time more
> precisely. 
> 
Yes, I agree. IIRC, the patches are doing more than that, e.g.,
discriminating between the runtime of the idle vCPUs and the time
during which the CPUs were actually idle, and even trying to classify
somehow what the hypervisor was actually doing (guest sync, etc).

But, indeed, I would very much start with the one yous stated above, as
a goal.

> Right now I can see only two main reasons, when guest can be charged
> for a time it dindn't used: interrupts and soft irqs. 
> 
> - do_softirq() is called every time we leave hypervisor mode. It is
> used to do housekeeping for the hypervisor itself. But, some random
> guest will charged for time spent in do_softirq() unless this
> function
> is not called on a idle vcpu.
> 
> - also, pCPU can be interrupted by IRQ assigned to some other guest
> or
> to hypervisor itself. But time spent in interrupt handler will be
> charged for a guest being interrupted.
> 
I think those are the ones, yes.

> So, basically, to account guest time correctly, we need to substract
> time spent in do_softirq() and in do_IRQ(). 
> 
That's how I'd try to do this, if it were me doing it.

> Actually, we can charge the correct guest for time spent in do_IRQ(),
> because handler code will eventually know target vCPU for the
> interrupt. There is technical problem with interrupt nesting. We will
> need some stack to track nesting correctly. But this is doable.
> 
Yes, there's this, and maybe a few other "dependencies" that we may
discuss about, and try to track and account for, for even greather
fairness. But maybe this can come as a second step?

> Just for statistical purposes we can track hypervisor time somwhere,
> but it is not needed for scheduling decisions.
> 
What we need is, I think, a way to tell the used/admin that that time
is being spent in the hypervisor. E.g., if we were spending (let's
exaggerate) 20% of the time processing interrupts and softirqs, the
user would see some of this 20% load coming from each guest. It
certainly wasn't ideal, but we do not want for such 20% to suddenly
vanish either.

> Am I missing something?
>
To me, it seems you're not. :-)

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)



signature.asc
Description: This is a digitally signed message part

[PATCH v2 05/11] swiotlb-xen: add struct device* parameter to xen_dma_sync_for_cpu

[Stefano Stabellini]

From: Stefano Stabellini 

The parameter is unused in this patch.
No functional changes.

Signed-off-by: Stefano Stabellini 
Tested-by: Corey Minyard 
Tested-by: Roman Shaposhnik 
---
 arch/arm/xen/mm.c | 5 +++--
 drivers/xen/swiotlb-xen.c | 4 ++--
 include/xen/swiotlb-xen.h | 5 +++--
 3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index d40e9e5fc52b..1a00e8003c64 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -71,8 +71,9 @@ static void dma_cache_maint(dma_addr_t handle, size_t size, 
u32 op)
  * pfn_valid returns true the pages is local and we can use the native
  * dma-direct functions, otherwise we call the Xen specific version.
  */
-void xen_dma_sync_for_cpu(dma_addr_t handle, phys_addr_t paddr, size_t size,
-   enum dma_data_direction dir)
+void xen_dma_sync_for_cpu(struct device *dev, dma_addr_t handle,
+ phys_addr_t paddr, size_t size,
+ enum dma_data_direction dir)
 {
if (pfn_valid(PFN_DOWN(handle)))
arch_sync_dma_for_cpu(paddr, size, dir);
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index e38a1cce4100..d9b3d9f2a7d1 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -425,7 +425,7 @@ static void xen_swiotlb_unmap_page(struct device *hwdev, 
dma_addr_t dev_addr,
BUG_ON(dir == DMA_NONE);
 
if (!dev_is_dma_coherent(hwdev) && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
-   xen_dma_sync_for_cpu(dev_addr, paddr, size, dir);
+   xen_dma_sync_for_cpu(hwdev, dev_addr, paddr, size, dir);
 
/* NOTE: We use dev_addr here, not paddr! */
if (is_xen_swiotlb_buffer(dev_addr))
@@ -439,7 +439,7 @@ xen_swiotlb_sync_single_for_cpu(struct device *dev, 
dma_addr_t dma_addr,
phys_addr_t paddr = xen_bus_to_phys(dev, dma_addr);
 
if (!dev_is_dma_coherent(dev))
-   xen_dma_sync_for_cpu(dma_addr, paddr, size, dir);
+   xen_dma_sync_for_cpu(dev, dma_addr, paddr, size, dir);
 
if (is_xen_swiotlb_buffer(dma_addr))
swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_CPU);
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index ffc0d3902b71..f62d1854780b 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -4,8 +4,9 @@
 
 #include 
 
-void xen_dma_sync_for_cpu(dma_addr_t handle, phys_addr_t paddr, size_t size,
-   enum dma_data_direction dir);
+void xen_dma_sync_for_cpu(struct device *dev, dma_addr_t handle,
+ phys_addr_t paddr, size_t size,
+ enum dma_data_direction dir);
 void xen_dma_sync_for_device(dma_addr_t handle, phys_addr_t paddr, size_t size,
enum dma_data_direction dir);
 
-- 
2.17.1

[PATCH v2 02/11] swiotlb-xen: remove start_dma_addr

[Stefano Stabellini]

From: Stefano Stabellini 

It is not strictly needed. Call virt_to_phys on xen_io_tlb_start
instead. It will be useful not to have a start_dma_addr around with the
next patches.

Note that virt_to_phys is not the same as xen_virt_to_bus but actually
it is used to compared again __pa(xen_io_tlb_start) as passed to
swiotlb_init_with_tbl, so virt_to_phys is actually what we want.

Signed-off-by: Stefano Stabellini 
Tested-by: Corey Minyard 
Tested-by: Roman Shaposhnik 
---
Changes in v2:
- update commit message

---
---
 drivers/xen/swiotlb-xen.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index a42129cba36e..ed09f8ac34c5 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -52,8 +52,6 @@ static unsigned long xen_io_tlb_nslabs;
  * Quick lookup value of the bus address of the IOTLB.
  */
 
-static u64 start_dma_addr;
-
 /*
  * Both of these functions should avoid XEN_PFN_PHYS because phys_addr_t
  * can be 32bit when dma_addr_t is 64bit leading to a loss in
@@ -241,7 +239,6 @@ int __ref xen_swiotlb_init(int verbose, bool early)
m_ret = XEN_SWIOTLB_EFIXUP;
goto error;
}
-   start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
if (early) {
if (swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs,
 verbose))
@@ -389,8 +386,8 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, 
struct page *page,
 */
trace_swiotlb_bounced(dev, dev_addr, size, swiotlb_force);
 
-   map = swiotlb_tbl_map_single(dev, start_dma_addr, phys,
-size, size, dir, attrs);
+   map = swiotlb_tbl_map_single(dev, virt_to_phys(xen_io_tlb_start),
+phys, size, size, dir, attrs);
if (map == (phys_addr_t)DMA_MAPPING_ERROR)
return DMA_MAPPING_ERROR;
 
-- 
2.17.1

[PATCH v2 08/11] swiotlb-xen: introduce phys_to_dma/dma_to_phys translations

[Stefano Stabellini]

From: Stefano Stabellini 

With some devices physical addresses are different than dma addresses.
To be able to deal with these cases, we need to call phys_to_dma on
physical addresses (including machine addresses in Xen terminology)
before returning them from xen_swiotlb_alloc_coherent and
xen_swiotlb_map_page.

We also need to convert dma addresses back to physical addresses using
dma_to_phys in xen_swiotlb_free_coherent and xen_swiotlb_unmap_page if
we want to do any operations on them.

Call dma_to_phys in is_xen_swiotlb_buffer.
Call phys_to_dma in xen_phys_to_bus.
Call dma_to_phys in xen_bus_to_phys.

Everything is taken care of by these changes except for
xen_swiotlb_alloc_coherent and xen_swiotlb_free_coherent, which need a
few explicit phys_to_dma/dma_to_phys calls.

Signed-off-by: Stefano Stabellini 
Tested-by: Corey Minyard 
Tested-by: Roman Shaposhnik 
---
Changes in v2:
- improve commit message
---
 drivers/xen/swiotlb-xen.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 0a6cb67f0fc4..60ef07440905 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -64,16 +64,16 @@ static inline dma_addr_t xen_phys_to_bus(struct device 
*dev, phys_addr_t paddr)
 
dma |= paddr & ~XEN_PAGE_MASK;
 
-   return dma;
+   return phys_to_dma(dev, dma);
 }
 
-static inline phys_addr_t xen_bus_to_phys(struct device *dev, dma_addr_t baddr)
+static inline phys_addr_t xen_bus_to_phys(struct device *dev,
+ dma_addr_t dma_addr)
 {
+   phys_addr_t baddr = dma_to_phys(dev, dma_addr);
unsigned long xen_pfn = bfn_to_pfn(XEN_PFN_DOWN(baddr));
-   dma_addr_t dma = (dma_addr_t)xen_pfn << XEN_PAGE_SHIFT;
-   phys_addr_t paddr = dma;
-
-   paddr |= baddr & ~XEN_PAGE_MASK;
+   phys_addr_t paddr = (xen_pfn << XEN_PAGE_SHIFT) |
+   (baddr & ~XEN_PAGE_MASK);
 
return paddr;
 }
@@ -99,7 +99,7 @@ static inline int range_straddles_page_boundary(phys_addr_t 
p, size_t size)
 
 static int is_xen_swiotlb_buffer(struct device *dev, dma_addr_t dma_addr)
 {
-   unsigned long bfn = XEN_PFN_DOWN(dma_addr);
+   unsigned long bfn = XEN_PFN_DOWN(dma_to_phys(dev, dma_addr));
unsigned long xen_pfn = bfn_to_local_pfn(bfn);
phys_addr_t paddr = XEN_PFN_PHYS(xen_pfn);
 
@@ -304,11 +304,11 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t 
size,
if (hwdev && hwdev->coherent_dma_mask)
dma_mask = hwdev->coherent_dma_mask;
 
-   /* At this point dma_handle is the physical address, next we are
+   /* At this point dma_handle is the dma address, next we are
 * going to set it to the machine address.
 * Do not use virt_to_phys(ret) because on ARM it doesn't correspond
 * to *dma_handle. */
-   phys = *dma_handle;
+   phys = dma_to_phys(hwdev, *dma_handle);
dev_addr = xen_phys_to_bus(hwdev, phys);
if (((dev_addr + size - 1 <= dma_mask)) &&
!range_straddles_page_boundary(phys, size))
@@ -319,6 +319,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t 
size,
xen_free_coherent_pages(hwdev, size, ret, 
(dma_addr_t)phys, attrs);
return NULL;
}
+   *dma_handle = phys_to_dma(hwdev, *dma_handle);
SetPageXenRemapped(virt_to_page(ret));
}
memset(ret, 0, size);
@@ -351,7 +352,8 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t 
size, void *vaddr,
TestClearPageXenRemapped(pg))
xen_destroy_contiguous_region(phys, order);
 
-   xen_free_coherent_pages(hwdev, size, vaddr, (dma_addr_t)phys, attrs);
+   xen_free_coherent_pages(hwdev, size, vaddr, phys_to_dma(hwdev, phys),
+   attrs);
 }
 
 /*
-- 
2.17.1

[PATCH v2 00/11] fix swiotlb-xen for RPi4

[Stefano Stabellini]

Hi all,

This series is a collection of fixes to get Linux running on the RPi4 as
dom0.

Conceptually there are only two significant changes:

- make sure not to call virt_to_page on vmalloc virt addresses (patch
  #1)
- use phys_to_dma and dma_to_phys to translate phys to/from dma
  addresses (all other patches)

In particular in regards to the second part, the RPi4 is the first
board where Xen can run that has the property that dma addresses are
different from physical addresses, and swiotlb-xen was written with the
assumption that phys addr == dma addr.

This series adds the phys_to_dma and dma_to_phys calls to make it work.

Cheers,

Stefano



The following changes since commit b85051e755b0e9d6dd8f17ef1da083851b83287d:

  Merge tag 'fixes-for-5.7-rc6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux (2020-05-20 13:23:55 
-0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git 
fix-rpi4-v2 

for you to fetch changes up to 49783ba67f75da3490d2c01ed9b445d8a89bbb0d:

  xen/arm: call dma_to_phys on the dma_addr_t parameter of dma_cache_maint 
(2020-06-03 15:05:53 -0700)


Boris Ostrovsky (1):
  swiotlb-xen: use vmalloc_to_page on vmalloc virt addresses

Stefano Stabellini (10):
  swiotlb-xen: remove start_dma_addr
  swiotlb-xen: add struct device* parameter to xen_phys_to_bus
  swiotlb-xen: add struct device* parameter to xen_bus_to_phys
  swiotlb-xen: add struct device* parameter to xen_dma_sync_for_cpu
  swiotlb-xen: add struct device* parameter to xen_dma_sync_for_device
  swiotlb-xen: add struct device* parameter to is_xen_swiotlb_buffer
  swiotlb-xen: introduce phys_to_dma/dma_to_phys translations
  swiotlb-xen: rename xen_phys_to_bus to xen_phys_to_dma and 
xen_bus_to_phys to xen_dma_to_phys
  xen/arm: introduce phys/dma translations in xen_dma_sync_for_*
  xen/arm: call dma_to_phys on the dma_addr_t parameter of dma_cache_maint

 arch/arm/xen/mm.c | 32 +++-
 drivers/xen/swiotlb-xen.c | 72 
+---
 include/xen/swiotlb-xen.h | 10 ++
 3 files changed, 62 insertions(+), 52 deletions(-)

[PATCH v2 11/11] xen/arm: call dma_to_phys on the dma_addr_t parameter of dma_cache_maint

[Stefano Stabellini]

From: Stefano Stabellini 

dma_cache_maint is getting called passing a dma address which could be
different from a physical address.

Add a struct device* parameter to dma_cache_maint.

Translate the dma_addr_t parameter of dma_cache_maint by calling
dma_to_phys. Do it for the first page and all the following pages, in
case of multipage handling.

Signed-off-by: Stefano Stabellini 
Tested-by: Corey Minyard 
Tested-by: Roman Shaposhnik 
---
Changes in v2:
- improve commit message
---
 arch/arm/xen/mm.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index bbad712a890d..1dc20f4bdc33 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -43,15 +43,18 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int order)
 static bool hypercall_cflush = false;
 
 /* buffers in highmem or foreign pages cannot cross page boundaries */
-static void dma_cache_maint(dma_addr_t handle, size_t size, u32 op)
+static void dma_cache_maint(struct device *dev, dma_addr_t handle,
+   size_t size, u32 op)
 {
struct gnttab_cache_flush cflush;
 
-   cflush.a.dev_bus_addr = handle & XEN_PAGE_MASK;
cflush.offset = xen_offset_in_page(handle);
cflush.op = op;
+   handle &= XEN_PAGE_MASK;
 
do {
+   cflush.a.dev_bus_addr = dma_to_phys(dev, handle);
+
if (size + cflush.offset > XEN_PAGE_SIZE)
cflush.length = XEN_PAGE_SIZE - cflush.offset;
else
@@ -60,7 +63,7 @@ static void dma_cache_maint(dma_addr_t handle, size_t size, 
u32 op)
HYPERVISOR_grant_table_op(GNTTABOP_cache_flush, , 1);
 
cflush.offset = 0;
-   cflush.a.dev_bus_addr += cflush.length;
+   handle += cflush.length;
size -= cflush.length;
} while (size);
 }
@@ -79,7 +82,7 @@ void xen_dma_sync_for_cpu(struct device *dev, dma_addr_t 
handle,
if (pfn_valid(PFN_DOWN(dma_to_phys(dev, handle
arch_sync_dma_for_cpu(paddr, size, dir);
else if (dir != DMA_TO_DEVICE)
-   dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL);
+   dma_cache_maint(dev, handle, size, GNTTAB_CACHE_INVAL);
 }
 
 void xen_dma_sync_for_device(struct device *dev, dma_addr_t handle,
@@ -89,9 +92,9 @@ void xen_dma_sync_for_device(struct device *dev, dma_addr_t 
handle,
if (pfn_valid(PFN_DOWN(dma_to_phys(dev, handle
arch_sync_dma_for_device(paddr, size, dir);
else if (dir == DMA_FROM_DEVICE)
-   dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL);
+   dma_cache_maint(dev, handle, size, GNTTAB_CACHE_INVAL);
else
-   dma_cache_maint(handle, size, GNTTAB_CACHE_CLEAN);
+   dma_cache_maint(dev, handle, size, GNTTAB_CACHE_CLEAN);
 }
 
 bool xen_arch_need_swiotlb(struct device *dev,
-- 
2.17.1

[PATCH v2 10/11] xen/arm: introduce phys/dma translations in xen_dma_sync_for_*

[Stefano Stabellini]

From: Stefano Stabellini 

xen_dma_sync_for_cpu, xen_dma_sync_for_device, xen_arch_need_swiotlb are
getting called passing dma addresses. On some platforms dma addresses
could be different from physical addresses. Before doing any operations
on these addresses we need to convert them back to physical addresses
using dma_to_phys.

Add dma_to_phys calls to xen_dma_sync_for_cpu, xen_dma_sync_for_device,
and xen_arch_need_swiotlb.

dma_cache_maint is fixed by the next patch.

Signed-off-by: Stefano Stabellini 
Tested-by: Corey Minyard 
Tested-by: Roman Shaposhnik 

---
Changes in v2:
- improve commit message
- don't use pfn_valid
---
 arch/arm/xen/mm.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index f2414ea40a79..bbad712a890d 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -75,7 +76,7 @@ void xen_dma_sync_for_cpu(struct device *dev, dma_addr_t 
handle,
  phys_addr_t paddr, size_t size,
  enum dma_data_direction dir)
 {
-   if (pfn_valid(PFN_DOWN(handle)))
+   if (pfn_valid(PFN_DOWN(dma_to_phys(dev, handle
arch_sync_dma_for_cpu(paddr, size, dir);
else if (dir != DMA_TO_DEVICE)
dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL);
@@ -85,7 +86,7 @@ void xen_dma_sync_for_device(struct device *dev, dma_addr_t 
handle,
 phys_addr_t paddr, size_t size,
 enum dma_data_direction dir)
 {
-   if (pfn_valid(PFN_DOWN(handle)))
+   if (pfn_valid(PFN_DOWN(dma_to_phys(dev, handle
arch_sync_dma_for_device(paddr, size, dir);
else if (dir == DMA_FROM_DEVICE)
dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL);
@@ -98,7 +99,7 @@ bool xen_arch_need_swiotlb(struct device *dev,
   dma_addr_t dev_addr)
 {
unsigned int xen_pfn = XEN_PFN_DOWN(phys);
-   unsigned int bfn = XEN_PFN_DOWN(dev_addr);
+   unsigned int bfn = XEN_PFN_DOWN(dma_to_phys(dev, dev_addr));
 
/*
 * The swiotlb buffer should be used if
-- 
2.17.1

[PATCH v2 03/11] swiotlb-xen: add struct device* parameter to xen_phys_to_bus

[Stefano Stabellini]

From: Stefano Stabellini 

The parameter is unused in this patch.
No functional changes.

Signed-off-by: Stefano Stabellini 
Tested-by: Corey Minyard 
Tested-by: Roman Shaposhnik 
---
 drivers/xen/swiotlb-xen.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index ed09f8ac34c5..1c44dbc69b70 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -57,7 +57,7 @@ static unsigned long xen_io_tlb_nslabs;
  * can be 32bit when dma_addr_t is 64bit leading to a loss in
  * information if the shift is done before casting to 64bit.
  */
-static inline dma_addr_t xen_phys_to_bus(phys_addr_t paddr)
+static inline dma_addr_t xen_phys_to_bus(struct device *dev, phys_addr_t paddr)
 {
unsigned long bfn = pfn_to_bfn(XEN_PFN_DOWN(paddr));
dma_addr_t dma = (dma_addr_t)bfn << XEN_PAGE_SHIFT;
@@ -78,9 +78,9 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t baddr)
return paddr;
 }
 
-static inline dma_addr_t xen_virt_to_bus(void *address)
+static inline dma_addr_t xen_virt_to_bus(struct device *dev, void *address)
 {
-   return xen_phys_to_bus(virt_to_phys(address));
+   return xen_phys_to_bus(dev, virt_to_phys(address));
 }
 
 static inline int range_straddles_page_boundary(phys_addr_t p, size_t size)
@@ -309,7 +309,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t 
size,
 * Do not use virt_to_phys(ret) because on ARM it doesn't correspond
 * to *dma_handle. */
phys = *dma_handle;
-   dev_addr = xen_phys_to_bus(phys);
+   dev_addr = xen_phys_to_bus(hwdev, phys);
if (((dev_addr + size - 1 <= dma_mask)) &&
!range_straddles_page_boundary(phys, size))
*dma_handle = dev_addr;
@@ -367,7 +367,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, 
struct page *page,
unsigned long attrs)
 {
phys_addr_t map, phys = page_to_phys(page) + offset;
-   dma_addr_t dev_addr = xen_phys_to_bus(phys);
+   dma_addr_t dev_addr = xen_phys_to_bus(dev, phys);
 
BUG_ON(dir == DMA_NONE);
/*
@@ -392,7 +392,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, 
struct page *page,
return DMA_MAPPING_ERROR;
 
phys = map;
-   dev_addr = xen_phys_to_bus(map);
+   dev_addr = xen_phys_to_bus(dev, map);
 
/*
 * Ensure that the address returned is DMA'ble
@@ -536,7 +536,7 @@ xen_swiotlb_sync_sg_for_device(struct device *dev, struct 
scatterlist *sgl,
 static int
 xen_swiotlb_dma_supported(struct device *hwdev, u64 mask)
 {
-   return xen_virt_to_bus(xen_io_tlb_end - 1) <= mask;
+   return xen_virt_to_bus(hwdev, xen_io_tlb_end - 1) <= mask;
 }
 
 const struct dma_map_ops xen_swiotlb_dma_ops = {
-- 
2.17.1

[PATCH v2 09/11] swiotlb-xen: rename xen_phys_to_bus to xen_phys_to_dma and xen_bus_to_phys to xen_dma_to_phys

[Stefano Stabellini]

so that their names can better describe their behavior.

No functional changes.

Signed-off-by: Stefano Stabellini 
---
 drivers/xen/swiotlb-xen.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 60ef07440905..41129c02d59a 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -57,7 +57,7 @@ static unsigned long xen_io_tlb_nslabs;
  * can be 32bit when dma_addr_t is 64bit leading to a loss in
  * information if the shift is done before casting to 64bit.
  */
-static inline dma_addr_t xen_phys_to_bus(struct device *dev, phys_addr_t paddr)
+static inline dma_addr_t xen_phys_to_dma(struct device *dev, phys_addr_t paddr)
 {
unsigned long bfn = pfn_to_bfn(XEN_PFN_DOWN(paddr));
dma_addr_t dma = (dma_addr_t)bfn << XEN_PAGE_SHIFT;
@@ -67,7 +67,7 @@ static inline dma_addr_t xen_phys_to_bus(struct device *dev, 
phys_addr_t paddr)
return phys_to_dma(dev, dma);
 }
 
-static inline phys_addr_t xen_bus_to_phys(struct device *dev,
+static inline phys_addr_t xen_dma_to_phys(struct device *dev,
  dma_addr_t dma_addr)
 {
phys_addr_t baddr = dma_to_phys(dev, dma_addr);
@@ -80,7 +80,7 @@ static inline phys_addr_t xen_bus_to_phys(struct device *dev,
 
 static inline dma_addr_t xen_virt_to_bus(struct device *dev, void *address)
 {
-   return xen_phys_to_bus(dev, virt_to_phys(address));
+   return xen_phys_to_dma(dev, virt_to_phys(address));
 }
 
 static inline int range_straddles_page_boundary(phys_addr_t p, size_t size)
@@ -309,7 +309,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t 
size,
 * Do not use virt_to_phys(ret) because on ARM it doesn't correspond
 * to *dma_handle. */
phys = dma_to_phys(hwdev, *dma_handle);
-   dev_addr = xen_phys_to_bus(hwdev, phys);
+   dev_addr = xen_phys_to_dma(hwdev, phys);
if (((dev_addr + size - 1 <= dma_mask)) &&
!range_straddles_page_boundary(phys, size))
*dma_handle = dev_addr;
@@ -340,7 +340,7 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t 
size, void *vaddr,
 
/* do not use virt_to_phys because on ARM it doesn't return you the
 * physical address */
-   phys = xen_bus_to_phys(hwdev, dev_addr);
+   phys = xen_dma_to_phys(hwdev, dev_addr);
 
/* Convert the size to actually allocated. */
size = 1UL << (order + XEN_PAGE_SHIFT);
@@ -369,7 +369,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, 
struct page *page,
unsigned long attrs)
 {
phys_addr_t map, phys = page_to_phys(page) + offset;
-   dma_addr_t dev_addr = xen_phys_to_bus(dev, phys);
+   dma_addr_t dev_addr = xen_phys_to_dma(dev, phys);
 
BUG_ON(dir == DMA_NONE);
/*
@@ -394,7 +394,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, 
struct page *page,
return DMA_MAPPING_ERROR;
 
phys = map;
-   dev_addr = xen_phys_to_bus(dev, map);
+   dev_addr = xen_phys_to_dma(dev, map);
 
/*
 * Ensure that the address returned is DMA'ble
@@ -422,7 +422,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, 
struct page *page,
 static void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
-   phys_addr_t paddr = xen_bus_to_phys(hwdev, dev_addr);
+   phys_addr_t paddr = xen_dma_to_phys(hwdev, dev_addr);
 
BUG_ON(dir == DMA_NONE);
 
@@ -438,7 +438,7 @@ static void
 xen_swiotlb_sync_single_for_cpu(struct device *dev, dma_addr_t dma_addr,
size_t size, enum dma_data_direction dir)
 {
-   phys_addr_t paddr = xen_bus_to_phys(dev, dma_addr);
+   phys_addr_t paddr = xen_dma_to_phys(dev, dma_addr);
 
if (!dev_is_dma_coherent(dev))
xen_dma_sync_for_cpu(dev, dma_addr, paddr, size, dir);
@@ -451,7 +451,7 @@ static void
 xen_swiotlb_sync_single_for_device(struct device *dev, dma_addr_t dma_addr,
size_t size, enum dma_data_direction dir)
 {
-   phys_addr_t paddr = xen_bus_to_phys(dev, dma_addr);
+   phys_addr_t paddr = xen_dma_to_phys(dev, dma_addr);
 
if (is_xen_swiotlb_buffer(dev, dma_addr))
swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_DEVICE);
-- 
2.17.1

[PATCH v2 04/11] swiotlb-xen: add struct device* parameter to xen_bus_to_phys

[Stefano Stabellini]

From: Stefano Stabellini 

The parameter is unused in this patch.
No functional changes.

Signed-off-by: Stefano Stabellini 
Tested-by: Corey Minyard 
Tested-by: Roman Shaposhnik 
---
 drivers/xen/swiotlb-xen.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 1c44dbc69b70..e38a1cce4100 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -67,7 +67,7 @@ static inline dma_addr_t xen_phys_to_bus(struct device *dev, 
phys_addr_t paddr)
return dma;
 }
 
-static inline phys_addr_t xen_bus_to_phys(dma_addr_t baddr)
+static inline phys_addr_t xen_bus_to_phys(struct device *dev, dma_addr_t baddr)
 {
unsigned long xen_pfn = bfn_to_pfn(XEN_PFN_DOWN(baddr));
dma_addr_t dma = (dma_addr_t)xen_pfn << XEN_PAGE_SHIFT;
@@ -339,7 +339,7 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t 
size, void *vaddr,
 
/* do not use virt_to_phys because on ARM it doesn't return you the
 * physical address */
-   phys = xen_bus_to_phys(dev_addr);
+   phys = xen_bus_to_phys(hwdev, dev_addr);
 
/* Convert the size to actually allocated. */
size = 1UL << (order + XEN_PAGE_SHIFT);
@@ -420,7 +420,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, 
struct page *page,
 static void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
-   phys_addr_t paddr = xen_bus_to_phys(dev_addr);
+   phys_addr_t paddr = xen_bus_to_phys(hwdev, dev_addr);
 
BUG_ON(dir == DMA_NONE);
 
@@ -436,7 +436,7 @@ static void
 xen_swiotlb_sync_single_for_cpu(struct device *dev, dma_addr_t dma_addr,
size_t size, enum dma_data_direction dir)
 {
-   phys_addr_t paddr = xen_bus_to_phys(dma_addr);
+   phys_addr_t paddr = xen_bus_to_phys(dev, dma_addr);
 
if (!dev_is_dma_coherent(dev))
xen_dma_sync_for_cpu(dma_addr, paddr, size, dir);
@@ -449,7 +449,7 @@ static void
 xen_swiotlb_sync_single_for_device(struct device *dev, dma_addr_t dma_addr,
size_t size, enum dma_data_direction dir)
 {
-   phys_addr_t paddr = xen_bus_to_phys(dma_addr);
+   phys_addr_t paddr = xen_bus_to_phys(dev, dma_addr);
 
if (is_xen_swiotlb_buffer(dma_addr))
swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_DEVICE);
-- 
2.17.1

[PATCH v2 06/11] swiotlb-xen: add struct device* parameter to xen_dma_sync_for_device

[Stefano Stabellini]

From: Stefano Stabellini 

The parameter is unused in this patch.
No functional changes.

Signed-off-by: Stefano Stabellini 
Tested-by: Corey Minyard 
Tested-by: Roman Shaposhnik 
---
 arch/arm/xen/mm.c | 5 +++--
 drivers/xen/swiotlb-xen.c | 4 ++--
 include/xen/swiotlb-xen.h | 5 +++--
 3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 1a00e8003c64..f2414ea40a79 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -81,8 +81,9 @@ void xen_dma_sync_for_cpu(struct device *dev, dma_addr_t 
handle,
dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL);
 }
 
-void xen_dma_sync_for_device(dma_addr_t handle, phys_addr_t paddr, size_t size,
-   enum dma_data_direction dir)
+void xen_dma_sync_for_device(struct device *dev, dma_addr_t handle,
+phys_addr_t paddr, size_t size,
+enum dma_data_direction dir)
 {
if (pfn_valid(PFN_DOWN(handle)))
arch_sync_dma_for_device(paddr, size, dir);
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index d9b3d9f2a7d1..9b846c143c90 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -405,7 +405,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, 
struct page *page,
 
 done:
if (!dev_is_dma_coherent(dev) && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
-   xen_dma_sync_for_device(dev_addr, phys, size, dir);
+   xen_dma_sync_for_device(dev, dev_addr, phys, size, dir);
return dev_addr;
 }
 
@@ -455,7 +455,7 @@ xen_swiotlb_sync_single_for_device(struct device *dev, 
dma_addr_t dma_addr,
swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_DEVICE);
 
if (!dev_is_dma_coherent(dev))
-   xen_dma_sync_for_device(dma_addr, paddr, size, dir);
+   xen_dma_sync_for_device(dev, dma_addr, paddr, size, dir);
 }
 
 /*
diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h
index f62d1854780b..6d235fe2b92d 100644
--- a/include/xen/swiotlb-xen.h
+++ b/include/xen/swiotlb-xen.h
@@ -7,8 +7,9 @@
 void xen_dma_sync_for_cpu(struct device *dev, dma_addr_t handle,
  phys_addr_t paddr, size_t size,
  enum dma_data_direction dir);
-void xen_dma_sync_for_device(dma_addr_t handle, phys_addr_t paddr, size_t size,
-   enum dma_data_direction dir);
+void xen_dma_sync_for_device(struct device *dev, dma_addr_t handle,
+phys_addr_t paddr, size_t size,
+enum dma_data_direction dir);
 
 extern int xen_swiotlb_init(int verbose, bool early);
 extern const struct dma_map_ops xen_swiotlb_dma_ops;
-- 
2.17.1

[PATCH v2 07/11] swiotlb-xen: add struct device* parameter to is_xen_swiotlb_buffer

[Stefano Stabellini]

From: Stefano Stabellini 

The parameter is unused in this patch.
No functional changes.

Signed-off-by: Stefano Stabellini 
Tested-by: Corey Minyard 
Tested-by: Roman Shaposhnik 
---
 drivers/xen/swiotlb-xen.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 9b846c143c90..0a6cb67f0fc4 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -97,7 +97,7 @@ static inline int range_straddles_page_boundary(phys_addr_t 
p, size_t size)
return 0;
 }
 
-static int is_xen_swiotlb_buffer(dma_addr_t dma_addr)
+static int is_xen_swiotlb_buffer(struct device *dev, dma_addr_t dma_addr)
 {
unsigned long bfn = XEN_PFN_DOWN(dma_addr);
unsigned long xen_pfn = bfn_to_local_pfn(bfn);
@@ -428,7 +428,7 @@ static void xen_swiotlb_unmap_page(struct device *hwdev, 
dma_addr_t dev_addr,
xen_dma_sync_for_cpu(hwdev, dev_addr, paddr, size, dir);
 
/* NOTE: We use dev_addr here, not paddr! */
-   if (is_xen_swiotlb_buffer(dev_addr))
+   if (is_xen_swiotlb_buffer(hwdev, dev_addr))
swiotlb_tbl_unmap_single(hwdev, paddr, size, size, dir, attrs);
 }
 
@@ -441,7 +441,7 @@ xen_swiotlb_sync_single_for_cpu(struct device *dev, 
dma_addr_t dma_addr,
if (!dev_is_dma_coherent(dev))
xen_dma_sync_for_cpu(dev, dma_addr, paddr, size, dir);
 
-   if (is_xen_swiotlb_buffer(dma_addr))
+   if (is_xen_swiotlb_buffer(dev, dma_addr))
swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_CPU);
 }
 
@@ -451,7 +451,7 @@ xen_swiotlb_sync_single_for_device(struct device *dev, 
dma_addr_t dma_addr,
 {
phys_addr_t paddr = xen_bus_to_phys(dev, dma_addr);
 
-   if (is_xen_swiotlb_buffer(dma_addr))
+   if (is_xen_swiotlb_buffer(dev, dma_addr))
swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_DEVICE);
 
if (!dev_is_dma_coherent(dev))
-- 
2.17.1

[PATCH v2 01/11] swiotlb-xen: use vmalloc_to_page on vmalloc virt addresses

[Stefano Stabellini]

From: Boris Ostrovsky 

xen_alloc_coherent_pages might return pages for which virt_to_phys and
virt_to_page don't work, e.g. ioremap'ed pages.

So in xen_swiotlb_free_coherent we can't assume that virt_to_page works.
Instead add a is_vmalloc_addr check and use vmalloc_to_page on vmalloc
virt addresses.

This patch fixes the following crash at boot on RPi4:
https://marc.info/?l=xen-devel=158862573216800

Signed-off-by: Boris Ostrovsky 
Signed-off-by: Stefano Stabellini 
Tested-by: Corey Minyard 
Tested-by: Roman Shaposhnik 
---
Changes in v2:
- update commit message
---
 drivers/xen/swiotlb-xen.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index b6d27762c6f8..a42129cba36e 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -335,6 +335,7 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t 
size, void *vaddr,
int order = get_order(size);
phys_addr_t phys;
u64 dma_mask = DMA_BIT_MASK(32);
+   struct page *pg;
 
if (hwdev && hwdev->coherent_dma_mask)
dma_mask = hwdev->coherent_dma_mask;
@@ -346,9 +347,11 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t 
size, void *vaddr,
/* Convert the size to actually allocated. */
size = 1UL << (order + XEN_PAGE_SHIFT);
 
+   pg = is_vmalloc_addr(vaddr) ? vmalloc_to_page(vaddr) :
+ virt_to_page(vaddr);
if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
 range_straddles_page_boundary(phys, size)) &&
-   TestClearPageXenRemapped(virt_to_page(vaddr)))
+   TestClearPageXenRemapped(pg))
xen_destroy_contiguous_region(phys, order);
 
xen_free_coherent_pages(hwdev, size, vaddr, (dma_addr_t)phys, attrs);
-- 
2.17.1

Re: [PATCH 04/12] x86/xen: add system core suspend and resume callbacks

[Agarwal, Anchal]

CAUTION: This email originated from outside of the organization. Do not 
click links or open attachments unless you can confirm the sender and know the 
content is safe.



On 5/19/20 7:26 PM, Anchal Agarwal wrote:
> From: Munehisa Kamata 
>
> Add Xen PVHVM specific system core callbacks for PM suspend and
> hibernation support. The callbacks suspend and resume Xen
> primitives,like shared_info, pvclock and grant table. Note that
> Xen suspend can handle them in a different manner, but system
> core callbacks are called from the context.


I don't think I understand that last sentence.

Looks like it may have cryptic meaning of stating that xen_suspend calls 
syscore_suspend from xen_suspend
So, if these syscore ops gets called  during xen_suspend do not do anything. 
Check if the mode is in xen suspend 
and return from there. These syscore_ops are specifically for domU hibernation.
I must admit, I may have overlooked lack of explanation of some implicit 
details in the original commit msg. 

>  So if the callbacks
> are called from Xen suspend context, return immediately.
>


> +
> +static int xen_syscore_suspend(void)
> +{
> + struct xen_remove_from_physmap xrfp;
> + int ret;
> +
> + /* Xen suspend does similar stuffs in its own logic */
> + if (xen_suspend_mode_is_xen_suspend())
> + return 0;
> +
> + xrfp.domid = DOMID_SELF;
> + xrfp.gpfn = __pa(HYPERVISOR_shared_info) >> PAGE_SHIFT;
> +
> + ret = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, );
> + if (!ret)
> + HYPERVISOR_shared_info = _dummy_shared_info;
> +
> + return ret;
> +}
> +
> +static void xen_syscore_resume(void)
> +{
> + /* Xen suspend does similar stuffs in its own logic */
> + if (xen_suspend_mode_is_xen_suspend())
> + return;
> +
> + /* No need to setup vcpu_info as it's already moved off */
> + xen_hvm_map_shared_info();
> +
> + pvclock_resume();
> +
> + gnttab_resume();


Do you call gnttab_suspend() in pm suspend path?
No, since it does nothing for HVM guests. The unmap_frames is only applicable 
for PV guests right?

> +}
> +
> +/*
> + * These callbacks will be called with interrupts disabled and when 
having only
> + * one CPU online.
> + */
> +static struct syscore_ops xen_hvm_syscore_ops = {
> + .suspend = xen_syscore_suspend,
> + .resume = xen_syscore_resume
> +};
> +
> +void __init xen_setup_syscore_ops(void)
> +{
> + if (xen_hvm_domain())


Have you tested this (the whole feature, not just this patch) with PVH
guest BTW? And PVH dom0 for that matter?

No I haven't. The whole series is just tested with hvm/pvhvm guests.

-boris
Thanks,
Anchal

> + register_syscore_ops(_hvm_syscore_ops);
> +}

Re: [PATCH] xen/rpi4: implement watchdog-based reset

[Roman Shaposhnik]

On Wed, Jun 3, 2020 at 3:31 PM Stefano Stabellini
 wrote:
>
> Touching the watchdog is required to be able to reboot the board.
>
> The implementation is based on
> drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux.
>
> Signed-off-by: Stefano Stabellini 

Tested-by: Roman Shaposhnik 

Thanks,
Roman.

Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU

[Roman Shaposhnik]

Well it goes without saying, but both Julian's branch and your
patchset can have:

Tested-by: Roman Shaposhnik 

Thanks,
Roman.

P.S. For anyone interested I'll be curating the patchset over here:
https://github.com/rvs/eve/tree/rpi4/pkg/xen/arch/aarch64
https://github.com/rvs/eve/tree/rpi4/pkg/new-kernel/patches-5.6.x


On Wed, Jun 3, 2020 at 8:37 AM Stefano Stabellini
 wrote:
>
> On Wed, 3 Jun 2020, Corey Minyard wrote:
> > On Tue, Jun 02, 2020 at 12:24:05PM -0700, Stefano Stabellini wrote:
> > > On Tue, 2 Jun 2020, Corey Minyard wrote:
> > > > Snip
> > > >
> > > > > > > > > whether
> > > > > > > > > this was already done:
> > > > > > > > >  1) Does the kernel boot on baremetal (i.e without Xen)? 
> > > > > > > > > This should
> > > > > > > > > help
> > > > > > > > > to confirm whether the bug is Xen is related.
> > > > > > > >
> > > > > > > > Yes it boots
> > > > > > > >
> > > > > > > > >  2) Swiotlb should not be necessary for basic dom0 boot 
> > > > > > > > > on Arm. Did
> > > > > > > > > you try
> > > > > > > > > to disable it? This should help to confirm whether swiotlb is 
> > > > > > > > > the
> > > > > > > > > problem or
> > > > > > > > > not.
> > > > > > > >
> > > > > > > > It boots disabling swiotlb-xen
> > > > > > >
> > > > > > > Thank you for the answer! swiotlb-xen should basically be a NOP 
> > > > > > > for dom0. So
> > > > > > > this suggests swiotlb is doing some transformation on the DMA 
> > > > > > > address.
> > > > > > >
> > > > > > > I have an idea what may have gone wrong. AFAICT, xen-swiotlb 
> > > > > > > seems to assume
> > > > > > > the DMA address space and CPU address space is the same. Is RPI 
> > > > > > > using the
> > > > > > > same address space?
> > > > > >
> > > > > > Another question, is the DMA request bounced? If so, are we sure 
> > > > > > the bounce
> > > > > > buffer is in the first GB?
> > > > >
> > > > > Yes, it is. This is actually where we spent the last few days, and I
> > > > > found another little related bug in the initialization of the
> > > > > swiotlb-xen but now I am sure the memory is under 1GB 
> > > > > (0x3400-0x3800)
> > > >
> > > > Was anything ever resolved on this issue?  It just kind of ended for me,
> > > > and I looked in the main kernel and didn't find anything that looked
> > > > related.
> > >
> > > Yes, we have a patch series on the list for the Linux kernel to fix this
> > > issue but it hasn't been merged yet:
> > >
> > > https://marc.info/?l=linux-kernel=159001831406263=2
> >
> > Just FYI, I pulled the changes on top of
> >   https://github.com/raspberrypi/linux.git rpi-5.4.y
> > Along with change
> >   56e35f9c5b87ec dma-mapping: drop the dev argument to arch_sync_dma_for_*
> > before the series so it applies on 5.4, and I was able to boot and
> > create a domU.  So:
> >
> > Tested-by: Corey Minyard 
> >
> > At least on 5.4.  If you think it would be valuable, I can test on
> > rpi-5.7.y.
>
> I'd feel better adding your Tested-by to my next upstream submission of
> the series if you could also test on 5.7. Thank you in advance!
>
>
> > I'll be integrating this in with our Pi Xen yocto layer at
> > https://github.com/MontaVista-OpenSourceTechnology/meta-raspberrypi-xen
>
> That's great!

Re: [XTF] xenbus: fix xenbus_write() ring overflow

[Andrew Cooper]

On 03/06/2020 09:21, Pawel Wieczorkiewicz wrote:
> Currently the xenbus_write() does not handle ring wrapping around
> correctly. When ring buffer is almost full and there is not enough
> space for next packet (e.g. there is 12 bytes of space left, but the
> packet header needs to transmit 16 bytes) the memcpy() goes out of the
> ring buffer boundry.
> Instead, the part variable should be limited to the space available in
> the ring buffer, so the memcpy() can fill up the buffer, update len
> variable (to indicate that there is still some data to be copied) and
> thereby the xenbus_write() loop can iterate again to finish copying
> the remainder of data to the beginning of the ring buffer.
>
> Signed-off-by: Pawel Wieczorkiewicz 

Oops.  Reviewed-by: Andrew Cooper  and pushed.

[PATCH for-4.14 v3] x86/svm: do not try to handle recalc NPT faults immediately

[Igor Druzhinin]

A recalculation NPT fault doesn't always require additional handling
in hvm_hap_nested_page_fault(), moreover in general case if there is no
explicit handling done there - the fault is wrongly considered fatal.

This covers a specific case of migration with vGPU assigned which
uses direct MMIO mappings made by XEN_DOMCTL_memory_mapping hypercall:
at a moment log-dirty is enabled globally, recalculation is requested
for the whole guest memory including those mapped MMIO regions
which causes a page fault being raised at the first access to them;
but due to MMIO P2M type not having any explicit handling in
hvm_hap_nested_page_fault() a domain is erroneously crashed with unhandled
SVM violation.

Instead of trying to be opportunistic - use safer approach and handle
P2M recalculation in a separate NPT fault by attempting to retry after
making the necessary adjustments. This is aligned with Intel behavior
where there are separate VMEXITs for recalculation and EPT violations
(faults) and only faults are handled in hvm_hap_nested_page_fault().
Do it by also unifying do_recalc return code with Intel implementation
where returning 1 means P2M was actually changed.

Since there was no case previously where p2m_pt_handle_deferred_changes()
could return a positive value - it's safe to replace ">= 0" with just "== 0"
in VMEXIT_NPF handler. finish_type_change() is also not affected by the
change as being able to deal with >0 return value of p2m->recalc from
EPT implementation.

Reviewed-by: Jan Beulich 
Reviewed-by: Roger Pau Monn?? 
Signed-off-by: Igor Druzhinin 
---
Changes in v2:
- replace rc with recalc_done bool
- updated comment in finish_type_change()
- significantly extended commit description
Changes in v3:
- covert bool to int implicitly
- a little bit more info of the usecase in the message
---
 xen/arch/x86/hvm/svm/svm.c | 5 +++--
 xen/arch/x86/mm/p2m-pt.c   | 7 ++-
 xen/arch/x86/mm/p2m.c  | 2 +-
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 46a1aac..7f6f578 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2923,9 +2923,10 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
 v->arch.hvm.svm.cached_insn_len = vmcb->guest_ins_len & 0xf;
 rc = vmcb->exitinfo1 & PFEC_page_present
  ? p2m_pt_handle_deferred_changes(vmcb->exitinfo2) : 0;
-if ( rc >= 0 )
+if ( rc == 0 )
+/* If no recal adjustments were being made - handle this fault */
 svm_do_nested_pgfault(v, regs, vmcb->exitinfo1, vmcb->exitinfo2);
-else
+else if ( rc < 0 )
 {
 printk(XENLOG_G_ERR
"%pv: Error %d handling NPF (gpa=%08lx ec=%04lx)\n",
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 5c05017..070389e 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -341,6 +341,7 @@ static int do_recalc(struct p2m_domain *p2m, unsigned long 
gfn)
 unsigned int level = 4;
 l1_pgentry_t *pent;
 int err = 0;
+bool recalc_done = false;
 
 table = map_domain_page(pagetable_get_mfn(p2m_get_pagetable(p2m)));
 while ( --level )
@@ -402,6 +403,8 @@ static int do_recalc(struct p2m_domain *p2m, unsigned long 
gfn)
 clear_recalc(l1, e);
 err = p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1);
 ASSERT(!err);
+
+recalc_done = true;
 }
 }
 unmap_domain_page((void *)((unsigned long)pent & PAGE_MASK));
@@ -448,12 +451,14 @@ static int do_recalc(struct p2m_domain *p2m, unsigned 
long gfn)
 clear_recalc(l1, e);
 err = p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1);
 ASSERT(!err);
+
+recalc_done = true;
 }
 
  out:
 unmap_domain_page(table);
 
-return err;
+return err ?: recalc_done;
 }
 
 int p2m_pt_handle_deferred_changes(uint64_t gpa)
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 17f320b..db7bde0 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1197,7 +1197,7 @@ static int finish_type_change(struct p2m_domain *p2m,
 rc = p2m->recalc(p2m, gfn);
 /*
  * ept->recalc could return 0/1/-ENOMEM. pt->recalc could return
- * 0/-ENOMEM/-ENOENT, -ENOENT isn't an error as we are looping
+ * 0/1/-ENOMEM/-ENOENT, -ENOENT isn't an error as we are looping
  * gfn here. If rc is 1 we need to have it 0 for success.
  */
 if ( rc == -ENOENT || rc > 0 )
-- 
2.7.4

[xen-unstable-smoke test] 150664: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 12 guest-start  fail REGR. vs. 150438

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail pass in 
150658

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

version targeted for testing:
 xen  d9f58cd54fe2f05e1f05e2fe254684bd1840de8e
baseline version:
 xen  1497e78068421d83956f8e82fb6e1bf1fc3b1199

Last test of basis   150438  2020-05-28 14:01:19 Z6 days
Failing since150465  2020-05-29 09:02:14 Z5 days   41 attempts
Testing same since   150649  2020-06-03 13:01:44 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andrew Cooper 
  Anthony PERARD 
  Dario Faggioli 
  Ian Jackson 
  Jan Beulich 
  Jason Andryuk 
  Juergen Gross 
  Julien Grall 
  Olaf Hering 
  Paul Durrant 
  Paul Durrant 
  Roger Pau Monné 
  Tamas K Lengyel 
  Wei Liu 

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-amd64fail
 test-amd64-amd64-libvirt fail



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.

(No revision log; it would be 1522 lines long.)

[linux-5.4 test] 150661: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux55852b3fd146ce90d4d4306b467261f2c4869293
baseline version:
 linuxe0d81ce760044efd3f26004aa32821c34968512a

Last test of basis   150508  2020-05-29 22:40:26 Z5 days
Testing same since   150642  2020-06-03 06:40:26 Z0 days2 attempts


People who touched revisions under test:
"Eric W. Biederman" 
  Al Viro 
  Alaa Hleihel 
  Alan Stern 
  Alex Deucher 
  Alex Sierra 
  Alexander Dahl 
  Alexander Potapenko 
  Alexei Starovoitov 
  Amy Shih 
  Andreas Gruenbacher 
  Andrew Morton 
  

Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU

[Corey Minyard]

On Wed, Jun 03, 2020 at 08:37:09AM -0700, Stefano Stabellini wrote:
> On Wed, 3 Jun 2020, Corey Minyard wrote:
> > On Tue, Jun 02, 2020 at 12:24:05PM -0700, Stefano Stabellini wrote:
> > > On Tue, 2 Jun 2020, Corey Minyard wrote:
> > > > Snip
> > > > 
> > > > > > > > > whether
> > > > > > > > > this was already done:
> > > > > > > > >  1) Does the kernel boot on baremetal (i.e without Xen)? 
> > > > > > > > > This should
> > > > > > > > > help
> > > > > > > > > to confirm whether the bug is Xen is related.
> > > > > > > > 
> > > > > > > > Yes it boots
> > > > > > > > 
> > > > > > > > >  2) Swiotlb should not be necessary for basic dom0 boot 
> > > > > > > > > on Arm. Did
> > > > > > > > > you try
> > > > > > > > > to disable it? This should help to confirm whether swiotlb is 
> > > > > > > > > the
> > > > > > > > > problem or
> > > > > > > > > not.
> > > > > > > > 
> > > > > > > > It boots disabling swiotlb-xen
> > > > > > > 
> > > > > > > Thank you for the answer! swiotlb-xen should basically be a NOP 
> > > > > > > for dom0. So
> > > > > > > this suggests swiotlb is doing some transformation on the DMA 
> > > > > > > address.
> > > > > > > 
> > > > > > > I have an idea what may have gone wrong. AFAICT, xen-swiotlb 
> > > > > > > seems to assume
> > > > > > > the DMA address space and CPU address space is the same. Is RPI 
> > > > > > > using the
> > > > > > > same address space?
> > > > > > 
> > > > > > Another question, is the DMA request bounced? If so, are we sure 
> > > > > > the bounce
> > > > > > buffer is in the first GB?
> > > > > 
> > > > > Yes, it is. This is actually where we spent the last few days, and I
> > > > > found another little related bug in the initialization of the
> > > > > swiotlb-xen but now I am sure the memory is under 1GB 
> > > > > (0x3400-0x3800)
> > > > 
> > > > Was anything ever resolved on this issue?  It just kind of ended for me,
> > > > and I looked in the main kernel and didn't find anything that looked
> > > > related.
> > > 
> > > Yes, we have a patch series on the list for the Linux kernel to fix this
> > > issue but it hasn't been merged yet:
> > > 
> > > https://marc.info/?l=linux-kernel=159001831406263=2
> > 
> > Just FYI, I pulled the changes on top of
> >   https://github.com/raspberrypi/linux.git rpi-5.4.y
> > Along with change
> >   56e35f9c5b87ec dma-mapping: drop the dev argument to arch_sync_dma_for_*
> > before the series so it applies on 5.4, and I was able to boot and
> > create a domU.  So:
> > 
> > Tested-by: Corey Minyard 
> > 
> > At least on 5.4.  If you think it would be valuable, I can test on
> > rpi-5.7.y.
> 
> I'd feel better adding your Tested-by to my next upstream submission of
> the series if you could also test on 5.7. Thank you in advance!

Well, rpi-5.7.y fails to bootup completely without Xen, and doesn't even
display any console output on top of Xen :-(.  So there are issues, but
probably not with Xen.

I did try rpi-5.6.y and it works.

-corey

> 
> 
> > I'll be integrating this in with our Pi Xen yocto layer at
> > https://github.com/MontaVista-OpenSourceTechnology/meta-raspberrypi-xen
> 
> That's great!

[PATCH] xen/rpi4: implement watchdog-based reset

[Stefano Stabellini]

Touching the watchdog is required to be able to reboot the board.

The implementation is based on
drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux.

Signed-off-by: Stefano Stabellini 
---
 xen/arch/arm/platforms/brcm-raspberry-pi.c | 60 ++
 1 file changed, 60 insertions(+)

diff --git a/xen/arch/arm/platforms/brcm-raspberry-pi.c 
b/xen/arch/arm/platforms/brcm-raspberry-pi.c
index f5ae58a7d5..0214ae2b3c 100644
--- a/xen/arch/arm/platforms/brcm-raspberry-pi.c
+++ b/xen/arch/arm/platforms/brcm-raspberry-pi.c
@@ -18,6 +18,10 @@
  */
 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 static const char *const rpi4_dt_compat[] __initconst =
 {
@@ -37,12 +41,68 @@ static const struct dt_device_match rpi4_blacklist_dev[] 
__initconst =
  * The aux peripheral also shares a page with the aux UART.
  */
 DT_MATCH_COMPATIBLE("brcm,bcm2835-aux"),
+/* Special device used for rebooting */
+DT_MATCH_COMPATIBLE("brcm,bcm2835-pm"),
 { /* sentinel */ },
 };
 
+
+#define PM_PASSWORD 0x5a00
+#define PM_RSTC 0x1c
+#define PM_WDOG 0x24
+#define PM_RSTC_WRCFG_FULL_RESET0x0020
+#define PM_RSTC_WRCFG_CLR   0xffcf
+
+static void __iomem *rpi4_map_watchdog(void)
+{
+void __iomem *base;
+struct dt_device_node *node;
+paddr_t start, len;
+int ret;
+
+node = dt_find_compatible_node(NULL, NULL, "brcm,bcm2835-pm");
+if ( !node )
+return NULL;
+
+ret = dt_device_get_address(node, 0, , );
+if ( ret )
+{
+dprintk(XENLOG_ERR, "Cannot read watchdog register address\n");
+return NULL;
+}
+
+base = ioremap_nocache(start & PAGE_MASK, PAGE_SIZE);
+if ( !base )
+{
+dprintk(XENLOG_ERR, "Unable to map watchdog register!\n");
+return NULL;
+}
+
+return base;
+}
+
+static void rpi4_reset(void)
+{
+u32 val;
+void __iomem *base = rpi4_map_watchdog();
+if ( !base )
+return;
+
+/* use a timeout of 10 ticks (~150us) */
+writel(10 | PM_PASSWORD, base + PM_WDOG);
+val = readl(base + PM_RSTC);
+val &= PM_RSTC_WRCFG_CLR;
+val |= PM_PASSWORD | PM_RSTC_WRCFG_FULL_RESET;
+writel(val, base + PM_RSTC);
+
+/* No sleeping, possibly atomic. */
+mdelay(1);
+}
+
 PLATFORM_START(rpi4, "Raspberry Pi 4")
 .compatible = rpi4_dt_compat,
 .blacklist_dev  = rpi4_blacklist_dev,
+.reset = rpi4_reset,
 .dma_bitsize= 30,
 PLATFORM_END
 
-- 
2.17.1

Xenstore quota and driver domains

[Jürgen Groß]

A recent report on xen-users surfaced a problem we have with driver
domains in medium sized or large configuration: the driver domain can
easily hit the default Xenstore quota (in the report it was a driver
domain for disks which hit the quota when 15 domUs were active at the
same time).

Setting the quota to a higher limit will work, of course, but this
enables "normal" domUs to use this quota, too, thus hogging lots of
Xenstore resources.

I believe the most sensible way to solve that would be to have a way
to set per-domain quota in Xenstore. As the original reporter already
raised concerns regarding rebooting the server for applying new global
quota, I believe new quota settings should be possible at runtime.

The question is how this interface should look like. Right now I could
think of two variants:

1. A new XS_SET_QUOTA and XS_GET_QUOTA wire command pair which can set
   and get the quota (both, default values for new domains and for any
   existing domain)

2. A new XS_CONTROL command for setting/getting quota (same scope as 1.)

Both variants have advantages and disadvantages:

1. Pros: - clear interface, easily usable
   Cons: - requires more code churn in tools (libxenstore, xl, libxl)
   for support in domain-config
 - any extension will again require similar churn

2. Pros: - easy extensible domain-config possible (via a single item,
   e.g. "xenstore-quota='watches=10 entries=2000'")
   Cons: - text parsing in Xenstore instead of xl/libxl
 - XS_CONTROL sub-options for quota will be ABI

Any thoughts?


Juergen

handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom

[Marek Marczykowski-Górecki]

Hi,

(continuation of a thread from #xendevel)

During system shutdown quite often I hit infinite stream of errors like
this:

(XEN) d3v0 Weird PIO status 1, port 0xb004 read 0x
(XEN) domain_crash called from io.c:178

This is all running on Xen 4.13.0 (I think I've got this with 4.13.1
too), nested within KVM. The KVM part means everything is very slow, so
various race conditions are much more likely to happen.

It started happening not long ago, and I'm pretty sure it's about
updating to qemu 4.2.0 (in linux stubdom), previous one was 3.0.0.

Thanks to Andrew and Roger, I've managed to collect more info.

Context:
dom0: pv
dom1: hvm
dom2: stubdom for dom1
dom3: hvm
dom4: stubdom for dom3
dom5: pvh
dom6: pvh

It starts I think ok:

(XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off.
(XEN) d3v0 handle_pio port 0xb004 read 0x
(XEN) d3v0 handle_pio port 0xb004 read 0x
(XEN) d3v0 handle_pio port 0xb004 write 0x0001
(XEN) d3v0 handle_pio port 0xb004 write 0x2001
(XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0
(XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off.
(XEN) d1v0 handle_pio port 0xb004 read 0x
(XEN) d1v0 handle_pio port 0xb004 read 0x
(XEN) d1v0 handle_pio port 0xb004 write 0x0001
(XEN) d1v0 handle_pio port 0xb004 write 0x2001
(XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0

But then (after a second or so) when the toolstack tries to clean it up,
things go sideways:

(XEN) d0v0 XEN_DOMCTL_destroydomain domain 6
(XEN) d0v0 XEN_DOMCTL_destroydomain domain 6 got domain_lock
(XEN) d0v0 XEN_DOMCTL_destroydomain domain 6 ret -85
(XEN) d0v0 XEN_DOMCTL_destroydomain domain 6
(XEN) d0v0 XEN_DOMCTL_destroydomain domain 6 got domain_lock
(XEN) d0v0 XEN_DOMCTL_destroydomain domain 6 ret -85
(... long stream of domain destroy that can't really finish ...)

And then, similar also for dom1:

(XEN) d0v1 XEN_DOMCTL_destroydomain domain 1
(XEN) d0v1 XEN_DOMCTL_destroydomain domain 1 got domain_lock
(XEN) d0v1 XEN_DOMCTL_destroydomain domain 1 ret -85
(... now a stream of this for dom1 and dom6 interleaved ...)

At some point, domain 2 (stubdom for domain 1) and domain 5 join too. 

Then, we get the main issue:

(XEN) d3v0 handle_pio port 0xb004 read 0x
(XEN) d3v0 Weird PIO status 1, port 0xb004 read 0x
(XEN) domain_crash called from io.c:178

Note, there was no XEN_DOMCTL_destroydomain for domain 3 nor its stubdom
yet. But XEN_DMOP_remote_shutdown for domain 3 was called already.

Full log of the shutdown:
https://gist.github.com/marmarek/fbfe1b5d8f4c7b47df5a5e28bd95ea66

And the patch adding those extra messages:
https://gist.github.com/marmarek/dc739a820928e641a1ed6b4759cdf6f3

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature

Re: [PATCH] xen/rpi4: implement watchdog-based reset

[Tamas K Lengyel]

On Wed, Jun 3, 2020 at 4:32 PM Stefano Stabellini
 wrote:
>
> Touching the watchdog is required to be able to reboot the board.
>
> The implementation is based on
> drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux.
>
> Signed-off-by: Stefano Stabellini 

Ah, fantastic, it's been very annoying not being able to reboot the
board via ssh.

Thanks,
Tamas

RE: UEFI support in ARM DomUs

[Peng Fan]

Grall ;
> Nataliya Korovkina 
> Subject: UEFI support in ARM DomUs

We have made U-Boot run inside XEN DomU, but just only PV console part,
not implement other frontend drivers currently. Would this help for your
case if enable EFI in U-Boot?

Regards,
Peng.

> 
> Hi!
> 
> with a lot of help from Stefano, we're getting RPi4 support in Project EVE
> pretty much on par between KVM and Xen.
> 
> One big area that still remains is supporting UEFI boot sequence for DomUs.
> With KVM, given the qemu virt device model this is as simple as using either
> stock UEFI build for arm or even U-Boot EFI emulation environment and
> passing it via -bios option.
> 
> Obviously with Xen on ARM we don't have the device model so my
> understanding is that the easiest way we can support it would be to port
> UEFI's OvmfPkg/OvmfXen target to ARM (it seems to be currently exclusively
> X64).
> 
> So here's my first question: if there's anybody on this list who had a hand in
> implementing OvmfPkg/OvmfXen can you please share your thoughts on how
> much work that port may be (or whether it is even feasible -- I may totally be
> missing something really obvious here).
> 
> And as long as I've got your attention: two more questions:
>1.. compared to the above, would porting pvgrub to ARM be any
>easier or more difficult?
> 
>2. same question for teaching u-boot about PV calls.
> 
> Thanks,
> Roman.
> 
> P.S. Oh and I guess between:
>0. OvmfPkg/OvmfXen on ARM64
>1. pvgrub on ARM64
>2. u-boot/EFI emulation with PV calls backend I didn't miss any other
> obvious way of making UEFI-aware VM images to boot on Xen ARM64 DomU,
> right?

Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation]

[Agarwal, Anchal]

 CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.



On Tue, May 19, 2020 at 11:27:50PM +, Anchal Agarwal wrote:
> From: Munehisa Kamata 
> 
> S4 power transition states are much different than xen
> suspend/resume. Former is visible to the guest and frontend drivers should
> be aware of the state transitions and should be able to take appropriate
> actions when needed. In transition to S4 we need to make sure that at 
least
> all the in-flight blkif requests get completed, since they probably 
contain
> bits of the guest's memory image and that's not going to get saved any
> other way. Hence, re-issuing of in-flight requests as in case of xen 
resume
> will not work here. This is in contrast to xen-suspend where we need to
> freeze with as little processing as possible to avoid dirtying RAM late in
> the migration cycle and we know that in-flight data can wait.
> 
> Add freeze, thaw and restore callbacks for PM suspend and hibernation
> support. All frontend drivers that needs to use PM_HIBERNATION/PM_SUSPEND
> events, need to implement these xenbus_driver callbacks. The freeze 
handler
> stops block-layer queue and disconnect the frontend from the backend while
> freeing ring_info and associated resources. Before disconnecting from the
> backend, we need to prevent any new IO from being queued and wait for 
existing
> IO to complete. Freeze/unfreeze of the queues will guarantee that there 
are no
> requests in use on the shared ring. However, for sanity we should check
> state of the ring before disconnecting to make sure that there are no
> outstanding requests to be processed on the ring. The restore handler
> re-allocates ring_info, unquiesces and unfreezes the queue and re-connect 
to
> the backend, so that rest of the kernel can continue to use the block 
device
> transparently.
> 
> Note:For older backends,if a backend doesn't have commit'12ea729645ace'
> xen/blkback: unmap all persistent grants when frontend gets disconnected,
> the frontend may see massive amount of grant table warning when freeing
> resources.
> [   36.852659] deferring g.e. 0xf9 (pfn 0x)
> [   36.855089] xen:grant_table: WARNING:e.g. 0x112 still in use!
> 
> In this case, persistent grants would need to be disabled.
> 
> [Anchal Changelog: Removed timeout/request during blkfront freeze.
> Reworked the whole patch to work with blk-mq and incorporate upstream's
> comments]

Please tag versions using vX and it would be helpful if you could list
the specific changes that you performed between versions. There where
3 RFC versions IIRC, and there's no log of the changes between them.

I will elaborate on "upstream's comments" in my changelog in my next round of 
patches.
> 
> Signed-off-by: Anchal Agarwal 
> Signed-off-by: Munehisa Kamata 
> ---
>  drivers/block/xen-blkfront.c | 122 +--
>  1 file changed, 115 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 3b889ea950c2..464863ed7093 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -48,6 +48,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> 
>  #include 
>  #include 
> @@ -80,6 +82,8 @@ enum blkif_state {
>   BLKIF_STATE_DISCONNECTED,
>   BLKIF_STATE_CONNECTED,
>   BLKIF_STATE_SUSPENDED,
> + BLKIF_STATE_FREEZING,
> + BLKIF_STATE_FROZEN

Nit: adding a terminating ',' would prevent further additions from
having to modify this line.
ACK.
>  };
> 
>  struct grant {
> @@ -219,6 +223,7 @@ struct blkfront_info
>   struct list_head requests;
>   struct bio_list bio_list;
>   struct list_head info_list;
> + struct completion wait_backend_disconnected;
>  };
> 
>  static unsigned int nr_minors;
> @@ -1005,6 +1010,7 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, 
u16 sector_size,
>   info->sector_size = sector_size;
>   info->physical_sector_size = physical_sector_size;
>   blkif_set_queue_limits(info);
> + init_completion(>wait_backend_disconnected);
> 
>   return 0;
>  }
> @@ -1057,7 +1063,7 @@ static int xen_translate_vdev(int vdevice, int 
*minor, unsigned int *offset)
>   case XEN_SCSI_DISK5_MAJOR:
>   case XEN_SCSI_DISK6_MAJOR:
>   case XEN_SCSI_DISK7_MAJOR:
> - *offset = (*minor / PARTS_PER_DISK) +
> + *offset = (*minor / PARTS_PER_DISK) +
>   

Re: [PATCH] xen/rpi4: implement watchdog-based reset

[Corey Minyard]

On Wed, Jun 03, 2020 at 03:31:56PM -0700, Stefano Stabellini wrote:
> Touching the watchdog is required to be able to reboot the board.
> 
> The implementation is based on
> drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux.

Ah, I was looking at this just today, as it had been annoying me
greatly.  This works for me, so:

Tested-by: Corey Minyard 

However, I was wondering if it might be better to handle this by failing
the operation in xen and passing it back to dom0 to do.  On the Pi you
send a firmware message to reboot, and that seems like too much to do in
Xen, but it would seem possible to send this back to dom0.  Just a
thought, as it might be a more general fix for other devices in the same
situation.

Thanks,

-corey

> 
> Signed-off-by: Stefano Stabellini 
> ---
>  xen/arch/arm/platforms/brcm-raspberry-pi.c | 60 ++
>  1 file changed, 60 insertions(+)
> 
> diff --git a/xen/arch/arm/platforms/brcm-raspberry-pi.c 
> b/xen/arch/arm/platforms/brcm-raspberry-pi.c
> index f5ae58a7d5..0214ae2b3c 100644
> --- a/xen/arch/arm/platforms/brcm-raspberry-pi.c
> +++ b/xen/arch/arm/platforms/brcm-raspberry-pi.c
> @@ -18,6 +18,10 @@
>   */
>  
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
>  
>  static const char *const rpi4_dt_compat[] __initconst =
>  {
> @@ -37,12 +41,68 @@ static const struct dt_device_match rpi4_blacklist_dev[] 
> __initconst =
>   * The aux peripheral also shares a page with the aux UART.
>   */
>  DT_MATCH_COMPATIBLE("brcm,bcm2835-aux"),
> +/* Special device used for rebooting */
> +DT_MATCH_COMPATIBLE("brcm,bcm2835-pm"),
>  { /* sentinel */ },
>  };
>  
> +
> +#define PM_PASSWORD 0x5a00
> +#define PM_RSTC 0x1c
> +#define PM_WDOG 0x24
> +#define PM_RSTC_WRCFG_FULL_RESET0x0020
> +#define PM_RSTC_WRCFG_CLR   0xffcf
> +
> +static void __iomem *rpi4_map_watchdog(void)
> +{
> +void __iomem *base;
> +struct dt_device_node *node;
> +paddr_t start, len;
> +int ret;
> +
> +node = dt_find_compatible_node(NULL, NULL, "brcm,bcm2835-pm");
> +if ( !node )
> +return NULL;
> +
> +ret = dt_device_get_address(node, 0, , );
> +if ( ret )
> +{
> +dprintk(XENLOG_ERR, "Cannot read watchdog register address\n");
> +return NULL;
> +}
> +
> +base = ioremap_nocache(start & PAGE_MASK, PAGE_SIZE);
> +if ( !base )
> +{
> +dprintk(XENLOG_ERR, "Unable to map watchdog register!\n");
> +return NULL;
> +}
> +
> +return base;
> +}
> +
> +static void rpi4_reset(void)
> +{
> +u32 val;
> +void __iomem *base = rpi4_map_watchdog();
> +if ( !base )
> +return;
> +
> +/* use a timeout of 10 ticks (~150us) */
> +writel(10 | PM_PASSWORD, base + PM_WDOG);
> +val = readl(base + PM_RSTC);
> +val &= PM_RSTC_WRCFG_CLR;
> +val |= PM_PASSWORD | PM_RSTC_WRCFG_FULL_RESET;
> +writel(val, base + PM_RSTC);
> +
> +/* No sleeping, possibly atomic. */
> +mdelay(1);
> +}
> +
>  PLATFORM_START(rpi4, "Raspberry Pi 4")
>  .compatible = rpi4_dt_compat,
>  .blacklist_dev  = rpi4_blacklist_dev,
> +.reset = rpi4_reset,
>  .dma_bitsize= 30,
>  PLATFORM_END
>  
> -- 
> 2.17.1
> 

[xen-unstable-smoke test] 150671: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 12 guest-start  fail REGR. vs. 150438

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

version targeted for testing:
 xen  d9f58cd54fe2f05e1f05e2fe254684bd1840de8e
baseline version:
 xen  1497e78068421d83956f8e82fb6e1bf1fc3b1199

Last test of basis   150438  2020-05-28 14:01:19 Z6 days
Failing since150465  2020-05-29 09:02:14 Z5 days   42 attempts
Testing same since   150649  2020-06-03 13:01:44 Z0 days4 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andrew Cooper 
  Anthony PERARD 
  Dario Faggioli 
  Ian Jackson 
  Jan Beulich 
  Jason Andryuk 
  Juergen Gross 
  Julien Grall 
  Olaf Hering 
  Paul Durrant 
  Paul Durrant 
  Roger Pau Monné 
  Tamas K Lengyel 
  Wei Liu 

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 fail



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.

(No revision log; it would be 1522 lines long.)

[xtf test] 150667: all pass - PUSHED

[osstest service owner]

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

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

Last test of basis   147207  2020-02-17 18:39:34 Z  107 days
Testing same since   150667  2020-06-03 21:09:33 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Igor Druzhinin 
  Pawel Wieczorkiewicz 

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
   9d93498..cce0ffa  cce0ffab7cc43c810580889a197662d77f2d8ebd -> 
xen-tested-master

[ovmf test] 150668: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 68d720fd92bbdbbfae5adee02d6d9fd24ca38f30
baseline version:
 ovmf 7191dd3c5990416cf473ce36b3fb84ecb2f7b950

Last test of basis   150653  2020-06-03 14:09:17 Z0 days
Testing same since   150668  2020-06-03 21:39:18 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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
   7191dd3c59..68d720fd92  68d720fd92bbdbbfae5adee02d6d9fd24ca38f30 -> 
xen-tested-master

[xen-unstable-smoke test] 150637: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 12 guest-start  fail REGR. vs. 150438

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

version targeted for testing:
 xen  99a76a88d5e7f4693bb6b286e366006e1da1c954
baseline version:
 xen  1497e78068421d83956f8e82fb6e1bf1fc3b1199

Last test of basis   150438  2020-05-28 14:01:19 Z5 days
Failing since150465  2020-05-29 09:02:14 Z4 days   36 attempts
Testing same since   150629  2020-06-02 21:00:40 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andrew Cooper 
  Anthony PERARD 
  Dario Faggioli 
  Ian Jackson 
  Jan Beulich 
  Jason Andryuk 
  Juergen Gross 
  Julien Grall 
  Olaf Hering 
  Paul Durrant 
  Paul Durrant 
  Roger Pau Monné 
  Tamas K Lengyel 
  Wei Liu 

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 fail



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.

(No revision log; it would be 1494 lines long.)

Re: [Xen-devel] [PATCH v3 5/9] libs: add libxenhypfs

[Olaf Hering]

On Mon, Feb 03, Jürgen Groß wrote:

> On 31.01.20 16:57, Wei Liu wrote:
> > On Tue, Jan 21, 2020 at 09:43:26AM +0100, Juergen Gross wrote:
> > > +Requires.private: xentoolcore,xentoollog,xencall
> > Need to list libz here?
> Probably, yes.

See "rpm -qf --provides /usr/include/zlib.h" for the proper value within the 
"pkgconfig" namespace.
It is 'zlib' instead of 'z'.

Olaf


signature.asc
Description: PGP signature

[linux-linus test] 150627: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 150606
 build-arm64-pvops 6 kernel-build   fail in 150613 REGR. vs. 150606

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-startfail pass in 150613
 test-armhf-armhf-xl-vhd  18 leak-check/check   fail pass in 150613

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked in 150613 n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked in 150613 n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked in 150613 n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked in 150613 n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked in 150613 n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked in 150613 n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked in 150613 n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked in 150613 n/a
 test-amd64-amd64-xl-rtds 16 guest-localmigrate  fail blocked in 150606
 test-amd64-amd64-xl-rtds 15 guest-saverestore   fail in 150613 like 150606
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 150613 like 
150606
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 150613 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 150613 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 150606
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 150606
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 150606
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150606
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 150606
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 150606
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150606
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 150606
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-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-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-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  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-arm64-arm64-xl-thunderx 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-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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  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-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 

[qemu-mainline test] 150631: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10  fail blocked in 150608
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150608
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 150608
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 150608
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 150608
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 150608
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 150608
 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 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-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-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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-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  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  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-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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu5cc7a54c2e91d82cb6a52e4921325c511fd90712
baseline version:
 qemuu6bb228190ef0b45669d285114cf8a280c55f4b39

Last test of basis   150608  2020-06-01 21:38:00 Z1 days
Testing same since   150631  2020-06-02 23:27:48 Z0 days1 attempts


People who touched revisions under test:
  David Gibson 
  Dr. David Alan Gilbert 
  Eduardo Habkost 
  Igor Mammedov 
  John Paul Adrian Glaubitz 
  Laurent Vivier 
  Lukas Straub 
  Miklos Szeredi 
  Nick Hudson 
  Pan Nengyuan 
  Peter Maydell 
  Philippe Mathieu-Daudé 
  Philippe Mathieu-Daudé 
  Richard Henderson 
  Vivek Goyal 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass