I have quite some patches on my queue for 2.12. (booting Fedora 26/27
guests, floating interrupts, machine checks, missing instructions ...)

So let's start slowly :) This series gets rid of program_interrupt() and
potential_page_fault(). We now always properly restore the cpu state when
injecting/delivering a program interrupt. So there is no need to update
the state via potential_page_fault() anymore.

In addition, handling for program interrupts comming via
s390_cpu_virt_mem_rw() was missing something for the TCG case. Also fixed.

David Hildenbrand (15):
  s390x/tcg: introduce and use program_interrupt_ra()
  s390x/tcg: get rid of runtime_exception()
  s390x/tcg: rip out dead tpi code
  s390x/ioinst: pass the retaddr to all IO instructions
  s390x/pci: pass the retaddr to all PCI instructions
  s390x/diag: pass the retaddr into handle_diag_308()
  s390x: handle exceptions during s390_cpu_virt_mem_rw() correctly (TCG)
  s390x/tcg: io instructions don't need potential_page_fault()
  s390x/tcg: use program_interrupt_ra() in SCLP Service Call
  s390x/tcg: use program_interrupt_ra() in DIAG
  s390x/tcg: use program_interrupt_ra() in per_check_exception()
  s390x/tcg: use program_interrupt_ra() in SACF
  s390x/tcg: use program_interrupt_ra() in STSI
  s390x/tcg: drop program_interrupt()
  s390x/tcg: drop potential_page_fault()

 hw/s390x/css.c               |   6 ---
 hw/s390x/s390-pci-inst.c     |  90 ++++++++++++++++++----------------
 hw/s390x/s390-pci-inst.h     |  16 ++++---
 include/hw/s390x/css.h       |   1 -
 target/s390x/cc_helper.c     |   2 +-
 target/s390x/cpu.h           |   4 +-
 target/s390x/crypto_helper.c |   7 +--
 target/s390x/diag.c          |  14 +++---
 target/s390x/excp_helper.c   |   5 +-
 target/s390x/fpu_helper.c    |   2 +-
 target/s390x/int_helper.c    |  14 +++---
 target/s390x/internal.h      |  35 +++++++-------
 target/s390x/interrupt.c     |   9 +++-
 target/s390x/ioinst.c        | 112 ++++++++++++++++++++-----------------------
 target/s390x/kvm.c           |  42 ++++++++--------
 target/s390x/mem_helper.c    |  35 +++++---------
 target/s390x/misc_helper.c   |  50 +++++++------------
 target/s390x/mmu_helper.c    |  19 +++++++-
 target/s390x/translate.c     |  27 +----------
 19 files changed, 226 insertions(+), 264 deletions(-)

-- 
2.14.3

On 28.11.2017 21:33, David Hildenbrand wrote:
> I have quite some patches on my queue for 2.12. (booting Fedora 26/27
> guests, floating interrupts, machine checks, missing instructions ...)
> 
> So let's start slowly :) This series gets rid of program_interrupt() and
> potential_page_fault(). We now always properly restore the cpu state when
> injecting/delivering a program interrupt. So there is no need to update
> the state via potential_page_fault() anymore.

I think this series is basically a very good idea! But...
OK, this is kind of bike-shed-painting now, but since we're currently in
hard freeze anyway and got plenty of time for discussion:
Something that bothers me a little bit is the name of the new function
"program_interrupt_ra()" ... that would IMHO be OK if the old function
"program_interrupt" would still stay, but since that is removed and the
_ra function is the only generic way that is left to inject a program
interrupt, could we maybe name the new function somewhat nicer right
from the start? Something like "s390_program_interrupt" maybe (which is
similar to tcg_s390_program_interrupt and kvm_s390_program_interrupt
that we have already)?

 Thomas

On 29.11.2017 14:51, Thomas Huth wrote:
> On 28.11.2017 21:33, David Hildenbrand wrote:
>> I have quite some patches on my queue for 2.12. (booting Fedora 26/27
>> guests, floating interrupts, machine checks, missing instructions ...)
>>
>> So let's start slowly :) This series gets rid of program_interrupt() and
>> potential_page_fault(). We now always properly restore the cpu state when
>> injecting/delivering a program interrupt. So there is no need to update
>> the state via potential_page_fault() anymore.
> 
> I think this series is basically a very good idea! But...
> OK, this is kind of bike-shed-painting now, but since we're currently in
> hard freeze anyway and got plenty of time for discussion:
> Something that bothers me a little bit is the name of the new function
> "program_interrupt_ra()" ... that would IMHO be OK if the old function
> "program_interrupt" would still stay, but since that is removed and the
> _ra function is the only generic way that is left to inject a program
> interrupt, could we maybe name the new function somewhat nicer right
> from the start? Something like "s390_program_interrupt" maybe (which is
> similar to tcg_s390_program_interrupt and kvm_s390_program_interrupt
> that we have already)?

Sure I can do that, other opinions?

> 
>  Thomas
> 


-- 

Thanks,

David / dhildenb

On Wed, 29 Nov 2017 15:06:33 +0100
David Hildenbrand <david@redhat.com> wrote:

> On 29.11.2017 14:51, Thomas Huth wrote:
> > On 28.11.2017 21:33, David Hildenbrand wrote:  
> >> I have quite some patches on my queue for 2.12. (booting Fedora 26/27
> >> guests, floating interrupts, machine checks, missing instructions ...)
> >>
> >> So let's start slowly :) This series gets rid of program_interrupt() and
> >> potential_page_fault(). We now always properly restore the cpu state when
> >> injecting/delivering a program interrupt. So there is no need to update
> >> the state via potential_page_fault() anymore.  
> > 
> > I think this series is basically a very good idea! But...
> > OK, this is kind of bike-shed-painting now, but since we're currently in
> > hard freeze anyway and got plenty of time for discussion:
> > Something that bothers me a little bit is the name of the new function
> > "program_interrupt_ra()" ... that would IMHO be OK if the old function
> > "program_interrupt" would still stay, but since that is removed and the
> > _ra function is the only generic way that is left to inject a program
> > interrupt, could we maybe name the new function somewhat nicer right
> > from the start? Something like "s390_program_interrupt" maybe (which is
> > similar to tcg_s390_program_interrupt and kvm_s390_program_interrupt
> > that we have already)?  
> 
> Sure I can do that, other opinions?

Fine with me as well.