[Xen-devel] [linux-next test] 142801: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-credit2  broken
 test-arm64-arm64-xl-credit2   4 host-install(4)broken REGR. vs. 142757
 test-amd64-amd64-xl   7 xen-boot fail REGR. vs. 142757
 test-arm64-arm64-xl-seattle   7 xen-boot fail REGR. vs. 142757
 test-arm64-arm64-xl   7 xen-boot fail REGR. vs. 142757
 test-arm64-arm64-libvirt-xsm  7 xen-boot fail REGR. vs. 142757
 test-arm64-arm64-examine  8 reboot   fail REGR. vs. 142757
 test-amd64-amd64-libvirt-pair 24 guest-migrate/dst_host/src_host/debian.repeat 
fail REGR. vs. 142757
 test-arm64-arm64-xl-thunderx  7 xen-boot fail REGR. vs. 142757
 test-arm64-arm64-xl-xsm   7 xen-boot fail REGR. vs. 142757
 test-arm64-arm64-xl-credit1   7 xen-boot fail REGR. vs. 142757

Tests which did not succeed, but are not blocking:
 test-amd64-i386-examine   8 reboot   fail  like 142757
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail  like 142757
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail  like 142757
 test-amd64-i386-libvirt   7 xen-boot fail  like 142757
 test-amd64-i386-xl-raw7 xen-boot fail  like 142757
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail like 
142757
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot  fail like 142757
 test-amd64-i386-xl-xsm7 xen-boot fail  like 142757
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot   fail like 142757
 test-amd64-i386-xl-shadow 7 xen-boot fail  like 142757
 test-amd64-i386-freebsd10-i386  7 xen-bootfail like 142757
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail like 
142757
 test-amd64-i386-xl7 xen-boot fail  like 142757
 test-amd64-i386-libvirt-xsm   7 xen-boot fail  like 142757
 test-amd64-i386-pair 10 xen-boot/src_hostfail  like 142757
 test-amd64-i386-pair 11 xen-boot/dst_hostfail  like 142757
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-bootfail like 142757
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot  fail like 142757
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot   fail like 142757
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  7 xen-boot   fail like 142757
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-bootfail like 142757
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot   fail like 142757
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  7 xen-boot   fail like 142757
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot  fail like 142757
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm  7 xen-boot fail like 142757
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot  fail like 142757
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot   fail like 142757
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot   fail like 142757
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  7 xen-boot   fail like 142757
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot   fail like 142757
 test-amd64-i386-xl-pvshim 7 xen-boot fail  like 142757
 test-amd64-i386-freebsd10-amd64  7 xen-boot   fail like 142757
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot   fail like 142757
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 142757
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 142757
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142757
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142757
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 142757
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 142757
 test-amd64-amd64-libvirt-xsm 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-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 23ab8df01a2c64fcb2eea5300c7b7a43baeba821
baseline version:
 ovmf cd70b1a71d30d0fff4c549a309682fdf127aaae6

Last test of basis   142765  2019-10-15 06:13:43 Z2 days
Testing same since   142831  2019-10-16 16:39:25 Z1 days1 attempts


People who touched revisions under test:
  Pete Batard 

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
   cd70b1a71d..23ab8df01a  23ab8df01a2c64fcb2eea5300c7b7a43baeba821 -> 
xen-tested-master

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

Re: [Xen-devel] [PATCH v2] xen/arm: add warning if memory modules overlap

[Brian Woods]

On Thu, Oct 17, 2019 at 10:49:15PM +0100, Julien Grall wrote:
> On Thu, 17 Oct 2019 at 22:20, Brian Woods  wrote:
> >
> > On Thu, Oct 17, 2019 at 09:34:51PM +0100, Julien Grall wrote:
> > > Hi,
> > >
> > > As a user such message would likely put me off. You tell me there are
> > > an overlap, but you don't provide more information even if you likely
> > > have the information in place. However...
> >
> > Well, I suppose the message could be changed to something like:
> > "WARNING: overlap detected in the above memory module addresses."
> > or something to more directly guide the users to the section.  Maybe
> > move the 'printk("\n");' after the warning so it's grouped tighter with
> > the module information.
> 
> My point stands even for this sort of message. You know the exact
> overlap, so why would you hide it from the users?

We're not hiding it.  You're not cluttering up the log with the same
data multiple times.  See below.

> > >
> > > ... What's wrong with just dumping the information here directly?
> >
> > IMO, it is better to have all the information printed in one spot.
> > There is less to go through and easier to find out what is happening.
> > There is also the fact that we do not have to print things twice (2 sets
> > of names, starting addresses and ending addresses per overlap) when it
> > is going to be printed in the near future anyway.  The cost of this is
> > just one initdata bool, which while I am not thrilled about, does not
> > seem that expensive (compared to a nested loop or printing out at least
> > (16*2 + 12) * 2 characters per overlap(at least on Arm64)).
> 
> Again, this is boot code and not a path that is going to be called
> hundreds of time. So performance is the last thing I care in this
> patch.
> 
> If we try to help the users by telling them there is an overlap
> between modules, then we should do it properly and tell them the exact
> overlap. Otherwise this is nearly as pointless as a crash later on in
> the boot process.
> 
> I also don't want a double for loop or any additional global variable
> when it can be done by simply adding a check in add_boot_module().

This isn't about performance (other than the nested for), this is about
providing a relatively clean and sane log to read.  It's not that
difficult to go through the addresses and see conflicts.  This also
keeps it all in one part of the log and shorter without losing
information.  Shorter and well structured logs (without losing info)
makes it easier to read.  Making logs easier to read helps everyone.

Showing the addresses and module name itself will take 2 lines assuming
you stay within 80 chars.  (16*2 + 12) * 2 = 88, that's without spaces,
'0x's or any sort of message explaining what's actually going wrong.
The module names and addresses will be printed out anyway in the near
future, so why not group them together?

The purpose of the warning is to tell the user something is wrong, both
messages do that and provide the information to determine what's wrong.

Brian

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 142736 REGR. 
vs. 139698

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw 10 debian-di-install fail in 142648 pass in 142800
 test-armhf-armhf-libvirt  7 xen-boot fail in 142736 pass in 142800
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail pass in 142648
 test-amd64-amd64-xl-pvshim   16 guest-localmigrate fail pass in 142736
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat  fail pass in 142736

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

Re: [Xen-devel] [PATCH v2] xen/arm: add warning if memory modules overlap

[Julien Grall]

On Thu, 17 Oct 2019 at 22:20, Brian Woods  wrote:
>
> On Thu, Oct 17, 2019 at 09:34:51PM +0100, Julien Grall wrote:
> > Hi,
> >
> > On Thu, 17 Oct 2019 at 21:08, Brian Woods  wrote:
> > >
> > > It's possible for a misconfigured device tree to cause Xen to crash when
> > > there are overlapping addresses in the memory modules.  Add a warning
> > > when printing the addresses to let the user know there's a possible
> > > issue.
> > >
> > > Signed-off-by: Brian Woods 
> > > ---
> > > v1 -> v2
> > > - removed nested loop and placed check in add_boot_module()
> > >
> > > Sample output:
> > > ...
> > > (XEN) MODULE[0]: 0140 - 01542121 Xen
> > > (XEN) MODULE[1]: 03846000 - 03850080 Device Tree
> > > (XEN) MODULE[2]: 03853000 - 07fff676 Ramdisk
> > > (XEN) MODULE[3]: 0008 - 0318 Kernel
> > > (XEN)  RESVD[0]: 03846000 - 0385
> > > (XEN)  RESVD[1]: 03853000 - 07fff676
> > > (XEN)
> > > (XEN) WARNING: overlap detected in the memory module addresses
> > > (XEN)
> > > (XEN) Command line: console=dtuart dtuart=serial0 dom0_mem=1G bootscrub=0 
> > > maxcpus=1 timer_slop=0
> > > ...
> > >
> > >  xen/arch/arm/bootfdt.c  | 4 
> > >  xen/arch/arm/setup.c| 6 ++
> > >  xen/include/asm-arm/setup.h | 1 +
> > >  3 files changed, 11 insertions(+)
> > >
> > > diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> > > index 08fb59f..f8b34d4 100644
> > > --- a/xen/arch/arm/bootfdt.c
> > > +++ b/xen/arch/arm/bootfdt.c
> > > @@ -387,6 +387,10 @@ static void __init early_print_info(void)
> > > mem_resv->bank[j].start + mem_resv->bank[j].size - 1);
> > >  }
> > >  printk("\n");
> > > +
> > > +if ( mem_module_overlap )
> > > +printk("WARNING: overlap detected in the memory module 
> > > addresses.\n");
> >
> > As a user such message would likely put me off. You tell me there are
> > an overlap, but you don't provide more information even if you likely
> > have the information in place. However...
>
> Well, I suppose the message could be changed to something like:
> "WARNING: overlap detected in the above memory module addresses."
> or something to more directly guide the users to the section.  Maybe
> move the 'printk("\n");' after the warning so it's grouped tighter with
> the module information.

My point stands even for this sort of message. You know the exact
overlap, so why would you hide it from the users?

>
> > > +
> > >  for ( i = 0 ; i < cmds->nr_mods; i++ )
> > >  printk("CMDLINE[%"PRIpaddr"]:%s %s\n", cmds->cmdline[i].start,
> > > cmds->cmdline[i].dt_name,
> > > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > > index 705a917..315a131 100644
> > > --- a/xen/arch/arm/setup.c
> > > +++ b/xen/arch/arm/setup.c
> > > @@ -69,6 +69,8 @@ integer_param("xenheap_megabytes", 
> > > opt_xenheap_megabytes);
> > >
> > >  domid_t __read_mostly max_init_domid;
> > >
> > > +bool __initdata mem_module_overlap;
> > > +
> > >  static __used void init_done(void)
> > >  {
> > >  /* Must be done past setting system_state. */
> > > @@ -254,6 +256,10 @@ struct bootmodule __init 
> > > *add_boot_module(bootmodule_kind kind,
> > >  mod->domU = false;
> > >  return mod;
> > >  }
> > > +
> > > +if ( ((mod->start >= start) && (mod->start < start + size)) ||
> > > + ((start >= mod->start) && (start < mod->start + mod->size)) 
> > > )
> > > +mem_module_overlap = true;
> >
> > ... What's wrong with just dumping the information here directly?
>
> IMO, it is better to have all the information printed in one spot.
> There is less to go through and easier to find out what is happening.
> There is also the fact that we do not have to print things twice (2 sets
> of names, starting addresses and ending addresses per overlap) when it
> is going to be printed in the near future anyway.  The cost of this is
> just one initdata bool, which while I am not thrilled about, does not
> seem that expensive (compared to a nested loop or printing out at least
> (16*2 + 12) * 2 characters per overlap(at least on Arm64)).

Again, this is boot code and not a path that is going to be called
hundreds of time. So performance is the last thing I care in this
patch.

If we try to help the users by telling them there is an overlap
between modules, then we should do it properly and tell them the exact
overlap. Otherwise this is nearly as pointless as a crash later on in
the boot process.

I also don't want a double for loop or any additional global variable
when it can be done by simply adding a check in add_boot_module().

Cheers,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v2] xen/arm: add warning if memory modules overlap

[Brian Woods]

On Thu, Oct 17, 2019 at 09:34:51PM +0100, Julien Grall wrote:
> Hi,
> 
> On Thu, 17 Oct 2019 at 21:08, Brian Woods  wrote:
> >
> > It's possible for a misconfigured device tree to cause Xen to crash when
> > there are overlapping addresses in the memory modules.  Add a warning
> > when printing the addresses to let the user know there's a possible
> > issue.
> >
> > Signed-off-by: Brian Woods 
> > ---
> > v1 -> v2
> > - removed nested loop and placed check in add_boot_module()
> >
> > Sample output:
> > ...
> > (XEN) MODULE[0]: 0140 - 01542121 Xen
> > (XEN) MODULE[1]: 03846000 - 03850080 Device Tree
> > (XEN) MODULE[2]: 03853000 - 07fff676 Ramdisk
> > (XEN) MODULE[3]: 0008 - 0318 Kernel
> > (XEN)  RESVD[0]: 03846000 - 0385
> > (XEN)  RESVD[1]: 03853000 - 07fff676
> > (XEN)
> > (XEN) WARNING: overlap detected in the memory module addresses
> > (XEN)
> > (XEN) Command line: console=dtuart dtuart=serial0 dom0_mem=1G bootscrub=0 
> > maxcpus=1 timer_slop=0
> > ...
> >
> >  xen/arch/arm/bootfdt.c  | 4 
> >  xen/arch/arm/setup.c| 6 ++
> >  xen/include/asm-arm/setup.h | 1 +
> >  3 files changed, 11 insertions(+)
> >
> > diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> > index 08fb59f..f8b34d4 100644
> > --- a/xen/arch/arm/bootfdt.c
> > +++ b/xen/arch/arm/bootfdt.c
> > @@ -387,6 +387,10 @@ static void __init early_print_info(void)
> > mem_resv->bank[j].start + mem_resv->bank[j].size - 1);
> >  }
> >  printk("\n");
> > +
> > +if ( mem_module_overlap )
> > +printk("WARNING: overlap detected in the memory module 
> > addresses.\n");
> 
> As a user such message would likely put me off. You tell me there are
> an overlap, but you don't provide more information even if you likely
> have the information in place. However...

Well, I suppose the message could be changed to something like:
"WARNING: overlap detected in the above memory module addresses."
or something to more directly guide the users to the section.  Maybe
move the 'printk("\n");' after the warning so it's grouped tighter with
the module information.

> > +
> >  for ( i = 0 ; i < cmds->nr_mods; i++ )
> >  printk("CMDLINE[%"PRIpaddr"]:%s %s\n", cmds->cmdline[i].start,
> > cmds->cmdline[i].dt_name,
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index 705a917..315a131 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -69,6 +69,8 @@ integer_param("xenheap_megabytes", opt_xenheap_megabytes);
> >
> >  domid_t __read_mostly max_init_domid;
> >
> > +bool __initdata mem_module_overlap;
> > +
> >  static __used void init_done(void)
> >  {
> >  /* Must be done past setting system_state. */
> > @@ -254,6 +256,10 @@ struct bootmodule __init 
> > *add_boot_module(bootmodule_kind kind,
> >  mod->domU = false;
> >  return mod;
> >  }
> > +
> > +if ( ((mod->start >= start) && (mod->start < start + size)) ||
> > + ((start >= mod->start) && (start < mod->start + mod->size)) )
> > +mem_module_overlap = true;
> 
> ... What's wrong with just dumping the information here directly?

IMO, it is better to have all the information printed in one spot.
There is less to go through and easier to find out what is happening.
There is also the fact that we do not have to print things twice (2 sets
of names, starting addresses and ending addresses per overlap) when it
is going to be printed in the near future anyway.  The cost of this is
just one initdata bool, which while I am not thrilled about, does not
seem that expensive (compared to a nested loop or printing out at least
(16*2 + 12) * 2 characters per overlap(at least on Arm64)).

I do think the message could use some polish, but this approach makes
the most sense to me.

Brian

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 133580
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 133580
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 133580
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 133580
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 133580
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 133580
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 
133580

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  7 xen-boot fail baseline untested
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  7 xen-boot fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133580
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 133580
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 133580
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-libvirt 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-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-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-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 

Re: [Xen-devel] [PATCH v2] xen/arm: add warning if memory modules overlap

[Julien Grall]

Hi,

On Thu, 17 Oct 2019 at 21:08, Brian Woods  wrote:
>
> It's possible for a misconfigured device tree to cause Xen to crash when
> there are overlapping addresses in the memory modules.  Add a warning
> when printing the addresses to let the user know there's a possible
> issue.
>
> Signed-off-by: Brian Woods 
> ---
> v1 -> v2
> - removed nested loop and placed check in add_boot_module()
>
> Sample output:
> ...
> (XEN) MODULE[0]: 0140 - 01542121 Xen
> (XEN) MODULE[1]: 03846000 - 03850080 Device Tree
> (XEN) MODULE[2]: 03853000 - 07fff676 Ramdisk
> (XEN) MODULE[3]: 0008 - 0318 Kernel
> (XEN)  RESVD[0]: 03846000 - 0385
> (XEN)  RESVD[1]: 03853000 - 07fff676
> (XEN)
> (XEN) WARNING: overlap detected in the memory module addresses
> (XEN)
> (XEN) Command line: console=dtuart dtuart=serial0 dom0_mem=1G bootscrub=0 
> maxcpus=1 timer_slop=0
> ...
>
>  xen/arch/arm/bootfdt.c  | 4 
>  xen/arch/arm/setup.c| 6 ++
>  xen/include/asm-arm/setup.h | 1 +
>  3 files changed, 11 insertions(+)
>
> diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> index 08fb59f..f8b34d4 100644
> --- a/xen/arch/arm/bootfdt.c
> +++ b/xen/arch/arm/bootfdt.c
> @@ -387,6 +387,10 @@ static void __init early_print_info(void)
> mem_resv->bank[j].start + mem_resv->bank[j].size - 1);
>  }
>  printk("\n");
> +
> +if ( mem_module_overlap )
> +printk("WARNING: overlap detected in the memory module 
> addresses.\n");

As a user such message would likely put me off. You tell me there are
an overlap, but you don't provide more information even if you likely
have the information in place. However...

> +
>  for ( i = 0 ; i < cmds->nr_mods; i++ )
>  printk("CMDLINE[%"PRIpaddr"]:%s %s\n", cmds->cmdline[i].start,
> cmds->cmdline[i].dt_name,
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 705a917..315a131 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -69,6 +69,8 @@ integer_param("xenheap_megabytes", opt_xenheap_megabytes);
>
>  domid_t __read_mostly max_init_domid;
>
> +bool __initdata mem_module_overlap;
> +
>  static __used void init_done(void)
>  {
>  /* Must be done past setting system_state. */
> @@ -254,6 +256,10 @@ struct bootmodule __init 
> *add_boot_module(bootmodule_kind kind,
>  mod->domU = false;
>  return mod;
>  }
> +
> +if ( ((mod->start >= start) && (mod->start < start + size)) ||
> + ((start >= mod->start) && (start < mod->start + mod->size)) )
> +mem_module_overlap = true;

... What's wrong with just dumping the information here directly?

Cheers,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/arm: add warning if memory modules overlap

[Julien Grall]

Hi,

On 17/10/2019 20:48, Brian Woods wrote:
> On Thu, Oct 17, 2019 at 10:20:11AM +0100, Julien Grall wrote:
>> Hi,
>>
>> Sorry for the late answer.
>>
>> On 11/10/2019 20:07, Brian Woods wrote:
>>> Which is why I wanted to put it where it was in the patch.  Where the
>>> user would see the warning after the information about the memory
>>> modules were printed (and fair early).
>>
>> I had a think about it, dumping the modules informations before is useful if
>> you know that you have one module max per kind. So you avoid to print the
>> modules address/size in the warning.
>>
>> However, it is possible to have multiple kernel module (as long as they
>> don't have the same start address), you could end up with the following
>> message:
>>
>> "WARNING: modules Kernel and Kernel overlap"
>>
>> To make the message more meaningful, we would need to print the modules
>> address/size. Therefore, I don't view that it is important to check
>> overlapping in early_print_info(). In this case I would favor any code that
>> don't add a double for loop.
> 
> Well, adding that information would be easy enough and cheap.  It would
> make it multiline prinktk though:
> WARNING: memory modules over lap:
>   start_addr-end_addr: modulename
>   start_addr-end_addr: modulename

Why do you need a multiline? A single 80-charaters should really be 
sufficient.

> 
> If we're not doing that though, would it make sense to have a initdata
> bool that checks it in add_boot_module() and then prints a simple
> warning that there's a memory module overlap in early_print_info()?
> That way there's no nested for loop and it gets printed where all the
> addresses get printed (so you can actually figure out where the overlap
> is).
Please no. There are no need to add a bool just for the sake of getting 
all the print together.

The more that if you print all the information as I suggested above, you 
don't need to have it printed by early_print_info().

To be honest, I really don't think this is Xen job to check that you 
specify your modules correctly. There are other way to screw up your 
device-tree anyway (like overlap in memory banks or reserved region...).

The modules overlap can really only happen if you try to have your DT 
pre-generated and don't bother to use the bootloader (U-boot/Grub) 
script to generate your DT/modules.

> 
>> While thinking about this case, it made me realize that we only check the
>> start address to consider a match. This means if the size is different, then
>> it will be ignored. I think we ought to throw at least warning for this case
>> as well.
>>
>> Would you mind to have a look?
> 
> When you say starting address, do you mean like in the orginal patch?
> If so, there's no functional change in checking the starts of n on m and
> m on n then checking the start and end of n on m.

No. I meant that you could have a device-tree describing two modules 
starting at the same address, but with a different size.

See the check in add_boot_module() to see if a module already exist of 
the same kind.

Cheers,

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

[Xen-devel] [PATCH v2] xen/arm: add warning if memory modules overlap

[Brian Woods]

It's possible for a misconfigured device tree to cause Xen to crash when
there are overlapping addresses in the memory modules.  Add a warning
when printing the addresses to let the user know there's a possible
issue.

Signed-off-by: Brian Woods 
---
v1 -> v2
- removed nested loop and placed check in add_boot_module()

Sample output:
...
(XEN) MODULE[0]: 0140 - 01542121 Xen 
(XEN) MODULE[1]: 03846000 - 03850080 Device Tree 
(XEN) MODULE[2]: 03853000 - 07fff676 Ramdisk 
(XEN) MODULE[3]: 0008 - 0318 Kernel  
(XEN)  RESVD[0]: 03846000 - 0385
(XEN)  RESVD[1]: 03853000 - 07fff676
(XEN) 
(XEN) WARNING: overlap detected in the memory module addresses
(XEN) 
(XEN) Command line: console=dtuart dtuart=serial0 dom0_mem=1G bootscrub=0 
maxcpus=1 timer_slop=0
...

 xen/arch/arm/bootfdt.c  | 4 
 xen/arch/arm/setup.c| 6 ++
 xen/include/asm-arm/setup.h | 1 +
 3 files changed, 11 insertions(+)

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 08fb59f..f8b34d4 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -387,6 +387,10 @@ static void __init early_print_info(void)
mem_resv->bank[j].start + mem_resv->bank[j].size - 1);
 }
 printk("\n");
+
+if ( mem_module_overlap )
+printk("WARNING: overlap detected in the memory module addresses.\n");
+
 for ( i = 0 ; i < cmds->nr_mods; i++ )
 printk("CMDLINE[%"PRIpaddr"]:%s %s\n", cmds->cmdline[i].start,
cmds->cmdline[i].dt_name,
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 705a917..315a131 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -69,6 +69,8 @@ integer_param("xenheap_megabytes", opt_xenheap_megabytes);
 
 domid_t __read_mostly max_init_domid;
 
+bool __initdata mem_module_overlap;
+
 static __used void init_done(void)
 {
 /* Must be done past setting system_state. */
@@ -254,6 +256,10 @@ struct bootmodule __init *add_boot_module(bootmodule_kind 
kind,
 mod->domU = false;
 return mod;
 }
+
+if ( ((mod->start >= start) && (mod->start < start + size)) ||
+ ((start >= mod->start) && (start < mod->start + mod->size)) )
+mem_module_overlap = true;
 }
 
 mod = >module[mods->nr_mods++];
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 2f8f24e..4bb1ba1 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -122,6 +122,7 @@ void device_tree_get_reg(const __be32 **cell, u32 
address_cells,
 u32 device_tree_get_u32(const void *fdt, int node,
 const char *prop_name, u32 dflt);
 
+extern bool mem_module_overlap;
 #endif
 /*
  * Local variables:
-- 
2.7.4


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

Re: [Xen-devel] [PATCH] xen/arm: add warning if memory modules overlap

[Brian Woods]

On Thu, Oct 17, 2019 at 10:20:11AM +0100, Julien Grall wrote:
> Hi,
> 
> Sorry for the late answer.
> 
> On 11/10/2019 20:07, Brian Woods wrote:
> >Which is why I wanted to put it where it was in the patch.  Where the
> >user would see the warning after the information about the memory
> >modules were printed (and fair early).
> 
> I had a think about it, dumping the modules informations before is useful if
> you know that you have one module max per kind. So you avoid to print the
> modules address/size in the warning.
> 
> However, it is possible to have multiple kernel module (as long as they
> don't have the same start address), you could end up with the following
> message:
> 
> "WARNING: modules Kernel and Kernel overlap"
> 
> To make the message more meaningful, we would need to print the modules
> address/size. Therefore, I don't view that it is important to check
> overlapping in early_print_info(). In this case I would favor any code that
> don't add a double for loop.

Well, adding that information would be easy enough and cheap.  It would
make it multiline prinktk though:
WARNING: memory modules over lap:
start_addr-end_addr: modulename
start_addr-end_addr: modulename

If we're not doing that though, would it make sense to have a initdata
bool that checks it in add_boot_module() and then prints a simple
warning that there's a memory module overlap in early_print_info()?
That way there's no nested for loop and it gets printed where all the
addresses get printed (so you can actually figure out where the overlap
is).

> While thinking about this case, it made me realize that we only check the
> start address to consider a match. This means if the size is different, then
> it will be ignored. I think we ought to throw at least warning for this case
> as well.
> 
> Would you mind to have a look?

When you say starting address, do you mean like in the orginal patch?
If so, there's no functional change in checking the starts of n on m and
m on n then checking the start and end of n on m.

> >
> >Either way, take your pick of location and if it's only debug or not and
> >I can write it up and test it.
> 
> I would still prefer in add_boot_module(). See why above.

I wrote I suggested above and tested it so that'll be sent out soon.

Brian

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

[Xen-devel] [qemu-mainline bisection] complete test-amd64-i386-qemuu-rhel6hvm-intel

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-qemuu-rhel6hvm-intel
testid redhat-install

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  6105683da35babad9ae168a72d1e89e63e9d6974
  Bug not present: e1b3d47751a420835cb0560fd029c39fea961a79
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/142843/


  commit 6105683da35babad9ae168a72d1e89e63e9d6974
  Author: Laurent Vivier 
  Date:   Fri Sep 6 10:38:12 2019 +0200
  
  ui: add an embedded Barrier client
  
  This allows to receive mouse and keyboard events from
  a Barrier server.
  
  This is enabled by adding the following parameter on the
  command line
  
  ... -object input-barrier,id=$id,name=$name ...
  
  Where $name is the name declared in the screens section of barrier.conf
  
  The barrier server (barriers) must be configured and must run on the
  local host.
  
  For instance:
  
section: screens
localhost:
...
VM-1:
...
end
  
section: links
localhost:
right = VM-1
VM-1:
left = localhost
end
  
  Then on the QEMU command line:
  
  ... -object input-barrier,id=barrie0,name=VM-1 ...
  
  When the mouse will move out of the screen of the local host on
  the right, the mouse and the keyboard will be grabbed and all
  related events will be send to the guest OS.
  
  This is usefull when qemu is configured without emulated graphic card
  but with a VFIO attached graphic card.
  
  More information about Barrier can be found at:
  
https://github.com/debauchee/barrier
  
  This avoids to install the Barrier server in the guest OS,
  for instance when it is not supported or during the installation.
  
  Signed-off-by: Laurent Vivier 
  Message-id: 20190906083812.29487-1-laur...@vivier.eu
  Signed-off-by: Gerd Hoffmann 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/test-amd64-i386-qemuu-rhel6hvm-intel.redhat-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/qemu-mainline/test-amd64-i386-qemuu-rhel6hvm-intel.redhat-install
 --summary-out=tmp/142843.bisection-summary --basis-template=140282 
--blessings=real,real-bisect qemu-mainline test-amd64-i386-qemuu-rhel6hvm-intel 
redhat-install
Searching for failure / basis pass:
 142783 fail [host=debina0] / 141466 [host=huxelrebe1] 141434 [host=albana0] 
141377 [host=baroque1] 141348 [host=elbling1] 141320 [host=chardonnay1] 141285 
[host=elbling0] 141259 [host=huxelrebe0] 141243 [host=fiano1] 141204 
[host=albana1] 141179 [host=italia1] 141087 ok.
Failure / basis pass flights: 142783 / 141087
(tree with no url: minios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest e132c8d7b58d8dc2c1888f5768454550d1f3ea7b 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
410c4d00d9f7e369d1ce183e9e8de98cb59c4d20 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
9020e9526cd08c4dc99d54dba48730de2908c970 
43f5df79dad6738d52ea79d072de2b56eb96a91f 
518c935fac4d30b3ec35d4b6add82b17b7d7aca3
Basis pass 3ffe1e79c174b2093f7ee3df589a7705572c9620 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8a1305a11f3bda2d6c1ab758e4aea79ee021dd1c 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
90b1e3afd33226b6078fec6d77a18373712a975c 
43f5df79dad6738d52ea79d072de2b56eb96a91f 
6c9639a72f0ca3a9430ef75f375877182281fdef
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#3ffe1e79c174b2093f7ee3df589a7705572c9620-e132c8d7b58d8dc2c1888f5768454550d1f3ea7b
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/osstest/ovmf.git#8a1305a11f3bda2d6c1ab758e4aea79ee021dd1c-410c4d00d9f7e369d1ce183e9e8de98cb59c4d20
 git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484\
 fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798 

Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure

[Lars Kurth]

On 17/10/2019, 18:05, "Rich Persaud"  wrote:

On Oct 17, 2019, at 12:55, Stefano Stabellini  
wrote:
> 
> On Thu, 17 Oct 2019, Rich Persaud wrote:
>>> On Oct 17, 2019, at 12:32, Stefano Stabellini  
wrote:
>>> 
>>> On Thu, 17 Oct 2019, Lars Kurth wrote:
 On 16/10/2019, 17:35, "Rich Persaud"  wrote:
 
>> On Oct 15, 2019, at 08:27, Lars Kurth  
wrote:
> ...
> 
> My point really was is that due to storing the files in git, we 
essentially do NOT today do this.
> So we would need to take extra action: e.g. manually or through 
tooling
> 
>>> 4.2: We could require individual authors to be credited: in that
>>> case we probably ought to lead by example and list the 
authors
>>> in a credit/license section and extract the information from
>>> git logs when we generate it (at some point in the future)
>>> 5: You give an indication whether you made changes ... in practice
>>> this means you have to state significant changes made to the works
>> 
>> This is also helpful for provenance of changes, which is relevant in 
safety-oriented documentation.  It can be used to clearly delineate CC-licensed 
content (which may be reused by many companies) from "All Rights Reserved" 
commercial content that may be added for a specific commercial audience or 
purpose.
> 
> I agree
> 
> I think the outcome of this analysis is really that the only 
significant difference between BSD and CC-BY in this context is the  "All 
Rights Reserved" portion
 
   Also - BSD is a "software" license while CC-BY is a "content" 
license, so they are not strictly comparable, even if they use similar 
terminology.
 
 True, but as we have noticed the boundary between content and in-code 
docs content is fuzzy.
 
>> There is a difference between "software" which "runs on machines" 
and "documentation" which "runs on humans".  Combined software (e.g. BSD code 
from two origins) is executed identically, despite origin.  Humans make value 
judgements based on the author/origin of content, hence the focus on 
attribution.  Yes, there is a provenance graph in git (software/data), but 
that's not typically visible to human readers, except as a generated report, 
i.e. documentation.
> 
> Yes true. But also true for CC-BY-4 sources stored in git unless 
extra action is taken 
> 
> But my point is: 
> * If we take extra action as e.g. proposed in 4.2 we can apply this 
uniformly to BSD as well as CC-BY pages
> * We can add a section on re-use as proposed in 4.2 which recommends 
best practices around 5.  
> * We can highlight sections that are BSD vs CC-BY in such a section, 
such that someone who has issue can remove these easily
> 
> In addition to these points: maybe it is too impractical to create 
ABI documentation based on CC-BY-4 (given that a lot of what we need is already 
in BSD sources). 
> We could just copy some of the content in the BSD sources to new 
CC-BY-4 sources, but in practice it would just be hiding the potential legal 
issues behind it. 
> Someone could contest the creation and argue that portions of the now 
CC-BY-4 sources are in fact BSD: in practice this is extremely unlikely, but it 
is possible.
> 
>>> As such, BSD-2/3-Clause in our context works similarly to CC-BY-4
>>> from a downstream's perspective. In fact CC-BY-4 is somewhat 
stricter
>> 
>> If we don't want the incentives and provenance properties of CC-BY, 
there is the option of CC0, which is the equivalent of public domain.  This 
would delegate the task of separating commercial vs CC content to each reader, 
without any license-required attribution or separation.
>> 
>> Some background on licenses designed for documentation, which has 
different legal requirements than software:
>> 
>> https://www.dreamsongs.com/IHE/IHE-50.html
>> https://creativecommons.org/faq/#what-are-creative-commons-licenses 
(not for s/w)
> 
> I will have a look. But the core issue - which is why I have proposed 
what I have - is the question on how practically ABI documentation published 
under CC-BY-4, when much of this information has already been published in the 
past as code under BSD.
 
   Is there a reference sample of:
 
   - previously published, BSD-licensed, ABI 
specification-as-source-code
 
 All of http://xenbits.xen.org/docs/unstable/hypercall
 And some can be content rich as seen in 
http://xenbits.xen.org/docs/unstable/hypercall/arm/include,public,xen.h.html#Func_HYPERVISOR_mmu_update
 
   - the corresponding FuSA ABI documentation for that source file
 
 

Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure

[Rich Persaud]

On Oct 17, 2019, at 12:55, Stefano Stabellini  wrote:
> 
> On Thu, 17 Oct 2019, Rich Persaud wrote:
>>> On Oct 17, 2019, at 12:32, Stefano Stabellini  
>>> wrote:
>>> 
>>> On Thu, 17 Oct 2019, Lars Kurth wrote:
 On 16/10/2019, 17:35, "Rich Persaud"  wrote:
 
>> On Oct 15, 2019, at 08:27, Lars Kurth  wrote:
> ...
> 
> My point really was is that due to storing the files in git, we 
> essentially do NOT today do this.
> So we would need to take extra action: e.g. manually or through tooling
> 
>>> 4.2: We could require individual authors to be credited: in that
>>> case we probably ought to lead by example and list the authors
>>> in a credit/license section and extract the information from
>>> git logs when we generate it (at some point in the future)
>>> 5: You give an indication whether you made changes ... in practice
>>> this means you have to state significant changes made to the works
>> 
>> This is also helpful for provenance of changes, which is relevant in 
>> safety-oriented documentation.  It can be used to clearly delineate 
>> CC-licensed content (which may be reused by many companies) from "All 
>> Rights Reserved" commercial content that may be added for a specific 
>> commercial audience or purpose.
> 
> I agree
> 
> I think the outcome of this analysis is really that the only significant 
> difference between BSD and CC-BY in this context is the  "All Rights 
> Reserved" portion
 
   Also - BSD is a "software" license while CC-BY is a "content" license, 
 so they are not strictly comparable, even if they use similar terminology.
 
 True, but as we have noticed the boundary between content and in-code docs 
 content is fuzzy.
 
>> There is a difference between "software" which "runs on machines" and 
>> "documentation" which "runs on humans".  Combined software (e.g. BSD 
>> code from two origins) is executed identically, despite origin.  Humans 
>> make value judgements based on the author/origin of content, hence the 
>> focus on attribution.  Yes, there is a provenance graph in git 
>> (software/data), but that's not typically visible to human readers, 
>> except as a generated report, i.e. documentation.
> 
> Yes true. But also true for CC-BY-4 sources stored in git unless extra 
> action is taken 
> 
> But my point is: 
> * If we take extra action as e.g. proposed in 4.2 we can apply this 
> uniformly to BSD as well as CC-BY pages
> * We can add a section on re-use as proposed in 4.2 which recommends best 
> practices around 5.  
> * We can highlight sections that are BSD vs CC-BY in such a section, such 
> that someone who has issue can remove these easily
> 
> In addition to these points: maybe it is too impractical to create ABI 
> documentation based on CC-BY-4 (given that a lot of what we need is 
> already in BSD sources). 
> We could just copy some of the content in the BSD sources to new CC-BY-4 
> sources, but in practice it would just be hiding the potential legal 
> issues behind it. 
> Someone could contest the creation and argue that portions of the now 
> CC-BY-4 sources are in fact BSD: in practice this is extremely unlikely, 
> but it is possible.
> 
>>> As such, BSD-2/3-Clause in our context works similarly to CC-BY-4
>>> from a downstream's perspective. In fact CC-BY-4 is somewhat stricter
>> 
>> If we don't want the incentives and provenance properties of CC-BY, 
>> there is the option of CC0, which is the equivalent of public domain.  
>> This would delegate the task of separating commercial vs CC content to 
>> each reader, without any license-required attribution or separation.
>> 
>> Some background on licenses designed for documentation, which has 
>> different legal requirements than software:
>> 
>> https://www.dreamsongs.com/IHE/IHE-50.html
>> https://creativecommons.org/faq/#what-are-creative-commons-licenses (not 
>> for s/w)
> 
> I will have a look. But the core issue - which is why I have proposed 
> what I have - is the question on how practically ABI documentation 
> published under CC-BY-4, when much of this information has already been 
> published in the past as code under BSD.
 
   Is there a reference sample of:
 
   - previously published, BSD-licensed, ABI specification-as-source-code
 
 All of http://xenbits.xen.org/docs/unstable/hypercall
 And some can be content rich as seen in 
 http://xenbits.xen.org/docs/unstable/hypercall/arm/include,public,xen.h.html#Func_HYPERVISOR_mmu_update
 
   - the corresponding FuSA ABI documentation for that source file
 
 We do NOT have ANY FuSA documentation at this stage. And there are NO 
 examples of such docs 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  00fc9004be169a065c10a5fb699e353e430190c2
baseline version:
 xen  55ab292c42db41b05cfdba012680bf1e0ea02f7a

Last test of basis   142748  2019-10-14 14:14:24 Z3 days
Testing same since   142813  2019-10-16 13:00:54 Z1 days1 attempts


People who touched revisions under test:
  Julien Grall 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   55ab292c42..00fc9004be  00fc9004be169a065c10a5fb699e353e430190c2 -> smoke

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

Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure

[Stefano Stabellini]

On Thu, 17 Oct 2019, Rich Persaud wrote:
> On Oct 17, 2019, at 12:32, Stefano Stabellini  wrote:
> > 
> > On Thu, 17 Oct 2019, Lars Kurth wrote:
> >> On 16/10/2019, 17:35, "Rich Persaud"  wrote:
> >> 
>  On Oct 15, 2019, at 08:27, Lars Kurth  wrote:
> >>> ...
> >>> 
> >>> My point really was is that due to storing the files in git, we 
> >>> essentially do NOT today do this.
> >>> So we would need to take extra action: e.g. manually or through tooling
> >>> 
> >  4.2: We could require individual authors to be credited: in that
> >  case we probably ought to lead by example and list the authors
> >  in a credit/license section and extract the information from
> >  git logs when we generate it (at some point in the future)
> > 5: You give an indication whether you made changes ... in practice
> > this means you have to state significant changes made to the works
>  
>  This is also helpful for provenance of changes, which is relevant in 
>  safety-oriented documentation.  It can be used to clearly delineate 
>  CC-licensed content (which may be reused by many companies) from "All 
>  Rights Reserved" commercial content that may be added for a specific 
>  commercial audience or purpose.
> >>> 
> >>> I agree
> >>> 
> >>> I think the outcome of this analysis is really that the only significant 
> >>> difference between BSD and CC-BY in this context is the  "All Rights 
> >>> Reserved" portion
> >> 
> >>Also - BSD is a "software" license while CC-BY is a "content" license, 
> >> so they are not strictly comparable, even if they use similar terminology.
> >> 
> >> True, but as we have noticed the boundary between content and in-code docs 
> >> content is fuzzy.
> >> 
>  There is a difference between "software" which "runs on machines" and 
>  "documentation" which "runs on humans".  Combined software (e.g. BSD 
>  code from two origins) is executed identically, despite origin.  Humans 
>  make value judgements based on the author/origin of content, hence the 
>  focus on attribution.  Yes, there is a provenance graph in git 
>  (software/data), but that's not typically visible to human readers, 
>  except as a generated report, i.e. documentation.
> >>> 
> >>> Yes true. But also true for CC-BY-4 sources stored in git unless extra 
> >>> action is taken 
> >>> 
> >>> But my point is: 
> >>> * If we take extra action as e.g. proposed in 4.2 we can apply this 
> >>> uniformly to BSD as well as CC-BY pages
> >>> * We can add a section on re-use as proposed in 4.2 which recommends best 
> >>> practices around 5.  
> >>> * We can highlight sections that are BSD vs CC-BY in such a section, such 
> >>> that someone who has issue can remove these easily
> >>> 
> >>> In addition to these points: maybe it is too impractical to create ABI 
> >>> documentation based on CC-BY-4 (given that a lot of what we need is 
> >>> already in BSD sources). 
> >>> We could just copy some of the content in the BSD sources to new CC-BY-4 
> >>> sources, but in practice it would just be hiding the potential legal 
> >>> issues behind it. 
> >>> Someone could contest the creation and argue that portions of the now 
> >>> CC-BY-4 sources are in fact BSD: in practice this is extremely unlikely, 
> >>> but it is possible.
> >>> 
> > As such, BSD-2/3-Clause in our context works similarly to CC-BY-4
> > from a downstream's perspective. In fact CC-BY-4 is somewhat stricter
>  
>  If we don't want the incentives and provenance properties of CC-BY, 
>  there is the option of CC0, which is the equivalent of public domain.  
>  This would delegate the task of separating commercial vs CC content to 
>  each reader, without any license-required attribution or separation.
>  
>  Some background on licenses designed for documentation, which has 
>  different legal requirements than software:
>  
>  https://www.dreamsongs.com/IHE/IHE-50.html
>  https://creativecommons.org/faq/#what-are-creative-commons-licenses (not 
>  for s/w)
> >>> 
> >>> I will have a look. But the core issue - which is why I have proposed 
> >>> what I have - is the question on how practically ABI documentation 
> >>> published under CC-BY-4, when much of this information has already been 
> >>> published in the past as code under BSD.
> >> 
> >>Is there a reference sample of:
> >> 
> >>- previously published, BSD-licensed, ABI specification-as-source-code
> >> 
> >> All of http://xenbits.xen.org/docs/unstable/hypercall
> >> And some can be content rich as seen in 
> >> http://xenbits.xen.org/docs/unstable/hypercall/arm/include,public,xen.h.html#Func_HYPERVISOR_mmu_update
> >> 
> >>- the corresponding FuSA ABI documentation for that source file
> >> 
> >> We do NOT have ANY FuSA documentation at this stage. And there are NO 
> >> examples of such docs in the public domain
> >> I am waiting for a sanitised 

Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure

[Rich Persaud]

On Oct 17, 2019, at 12:32, Stefano Stabellini  wrote:
> 
> On Thu, 17 Oct 2019, Lars Kurth wrote:
>> On 16/10/2019, 17:35, "Rich Persaud"  wrote:
>> 
 On Oct 15, 2019, at 08:27, Lars Kurth  wrote:
>>> ...
>>> 
>>> My point really was is that due to storing the files in git, we essentially 
>>> do NOT today do this.
>>> So we would need to take extra action: e.g. manually or through tooling
>>> 
>  4.2: We could require individual authors to be credited: in that
>  case we probably ought to lead by example and list the authors
>  in a credit/license section and extract the information from
>  git logs when we generate it (at some point in the future)
> 5: You give an indication whether you made changes ... in practice
> this means you have to state significant changes made to the works
 
 This is also helpful for provenance of changes, which is relevant in 
 safety-oriented documentation.  It can be used to clearly delineate 
 CC-licensed content (which may be reused by many companies) from "All 
 Rights Reserved" commercial content that may be added for a specific 
 commercial audience or purpose.
>>> 
>>> I agree
>>> 
>>> I think the outcome of this analysis is really that the only significant 
>>> difference between BSD and CC-BY in this context is the  "All Rights 
>>> Reserved" portion
>> 
>>Also - BSD is a "software" license while CC-BY is a "content" license, so 
>> they are not strictly comparable, even if they use similar terminology.
>> 
>> True, but as we have noticed the boundary between content and in-code docs 
>> content is fuzzy.
>> 
 There is a difference between "software" which "runs on machines" and 
 "documentation" which "runs on humans".  Combined software (e.g. BSD code 
 from two origins) is executed identically, despite origin.  Humans make 
 value judgements based on the author/origin of content, hence the focus on 
 attribution.  Yes, there is a provenance graph in git (software/data), but 
 that's not typically visible to human readers, except as a generated 
 report, i.e. documentation.
>>> 
>>> Yes true. But also true for CC-BY-4 sources stored in git unless extra 
>>> action is taken 
>>> 
>>> But my point is: 
>>> * If we take extra action as e.g. proposed in 4.2 we can apply this 
>>> uniformly to BSD as well as CC-BY pages
>>> * We can add a section on re-use as proposed in 4.2 which recommends best 
>>> practices around 5.  
>>> * We can highlight sections that are BSD vs CC-BY in such a section, such 
>>> that someone who has issue can remove these easily
>>> 
>>> In addition to these points: maybe it is too impractical to create ABI 
>>> documentation based on CC-BY-4 (given that a lot of what we need is already 
>>> in BSD sources). 
>>> We could just copy some of the content in the BSD sources to new CC-BY-4 
>>> sources, but in practice it would just be hiding the potential legal issues 
>>> behind it. 
>>> Someone could contest the creation and argue that portions of the now 
>>> CC-BY-4 sources are in fact BSD: in practice this is extremely unlikely, 
>>> but it is possible.
>>> 
> As such, BSD-2/3-Clause in our context works similarly to CC-BY-4
> from a downstream's perspective. In fact CC-BY-4 is somewhat stricter
 
 If we don't want the incentives and provenance properties of CC-BY, there 
 is the option of CC0, which is the equivalent of public domain.  This 
 would delegate the task of separating commercial vs CC content to each 
 reader, without any license-required attribution or separation.
 
 Some background on licenses designed for documentation, which has 
 different legal requirements than software:
 
 https://www.dreamsongs.com/IHE/IHE-50.html
 https://creativecommons.org/faq/#what-are-creative-commons-licenses (not 
 for s/w)
>>> 
>>> I will have a look. But the core issue - which is why I have proposed what 
>>> I have - is the question on how practically ABI documentation published 
>>> under CC-BY-4, when much of this information has already been published in 
>>> the past as code under BSD.
>> 
>>Is there a reference sample of:
>> 
>>- previously published, BSD-licensed, ABI specification-as-source-code
>> 
>> All of http://xenbits.xen.org/docs/unstable/hypercall
>> And some can be content rich as seen in 
>> http://xenbits.xen.org/docs/unstable/hypercall/arm/include,public,xen.h.html#Func_HYPERVISOR_mmu_update
>> 
>>- the corresponding FuSA ABI documentation for that source file
>> 
>> We do NOT have ANY FuSA documentation at this stage. And there are NO 
>> examples of such docs in the public domain
>> I am waiting for a sanitised smallish system software example to be made 
>> available, which should help us identify the practical implications 
>> However, ABI documentation would be part of it
>> 
>>If there is almost a 1:1 correspondence between ABI "docs" and 

Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure

[Stefano Stabellini]

On Thu, 17 Oct 2019, Lars Kurth wrote:
> On 16/10/2019, 17:35, "Rich Persaud"  wrote:
> 
> > On Oct 15, 2019, at 08:27, Lars Kurth  wrote:
> ...
> > 
> > My point really was is that due to storing the files in git, we 
> essentially do NOT today do this.
> > So we would need to take extra action: e.g. manually or through tooling
> > 
> >>>   4.2: We could require individual authors to be credited: in that
> >>>   case we probably ought to lead by example and list the 
> authors
> >>>   in a credit/license section and extract the information from
> >>>   git logs when we generate it (at some point in the future)
> >>> 5: You give an indication whether you made changes ... in practice
> >>> this means you have to state significant changes made to the works
> >> 
> >> This is also helpful for provenance of changes, which is relevant in 
> safety-oriented documentation.  It can be used to clearly delineate 
> CC-licensed content (which may be reused by many companies) from "All Rights 
> Reserved" commercial content that may be added for a specific commercial 
> audience or purpose.
> > 
> > I agree
> > 
> > I think the outcome of this analysis is really that the only 
> significant difference between BSD and CC-BY in this context is the  "All 
> Rights Reserved" portion
> 
> Also - BSD is a "software" license while CC-BY is a "content" license, so 
> they are not strictly comparable, even if they use similar terminology.
> 
> True, but as we have noticed the boundary between content and in-code docs 
> content is fuzzy.
> 
> >> There is a difference between "software" which "runs on machines" and 
> "documentation" which "runs on humans".  Combined software (e.g. BSD code 
> from two origins) is executed identically, despite origin.  Humans make value 
> judgements based on the author/origin of content, hence the focus on 
> attribution.  Yes, there is a provenance graph in git (software/data), but 
> that's not typically visible to human readers, except as a generated report, 
> i.e. documentation.
> > 
> > Yes true. But also true for CC-BY-4 sources stored in git unless extra 
> action is taken 
> > 
> > But my point is: 
> > * If we take extra action as e.g. proposed in 4.2 we can apply this 
> uniformly to BSD as well as CC-BY pages
> > * We can add a section on re-use as proposed in 4.2 which recommends 
> best practices around 5.  
> > * We can highlight sections that are BSD vs CC-BY in such a section, 
> such that someone who has issue can remove these easily
> > 
> > In addition to these points: maybe it is too impractical to create ABI 
> documentation based on CC-BY-4 (given that a lot of what we need is already 
> in BSD sources). 
> > We could just copy some of the content in the BSD sources to new 
> CC-BY-4 sources, but in practice it would just be hiding the potential legal 
> issues behind it. 
> > Someone could contest the creation and argue that portions of the now 
> CC-BY-4 sources are in fact BSD: in practice this is extremely unlikely, but 
> it is possible.
> > 
> >>> As such, BSD-2/3-Clause in our context works similarly to CC-BY-4
> >>> from a downstream's perspective. In fact CC-BY-4 is somewhat stricter
> >> 
> >> If we don't want the incentives and provenance properties of CC-BY, 
> there is the option of CC0, which is the equivalent of public domain.  This 
> would delegate the task of separating commercial vs CC content to each 
> reader, without any license-required attribution or separation.
> >> 
> >> Some background on licenses designed for documentation, which has 
> different legal requirements than software:
> >> 
> >> https://www.dreamsongs.com/IHE/IHE-50.html
> >> https://creativecommons.org/faq/#what-are-creative-commons-licenses 
> (not for s/w)
> > 
> > I will have a look. But the core issue - which is why I have proposed 
> what I have - is the question on how practically ABI documentation published 
> under CC-BY-4, when much of this information has already been published in 
> the past as code under BSD.
> 
> Is there a reference sample of:
> 
> - previously published, BSD-licensed, ABI specification-as-source-code
> 
> All of http://xenbits.xen.org/docs/unstable/hypercall
> And some can be content rich as seen in 
> http://xenbits.xen.org/docs/unstable/hypercall/arm/include,public,xen.h.html#Func_HYPERVISOR_mmu_update
>  
> - the corresponding FuSA ABI documentation for that source file
> 
> We do NOT have ANY FuSA documentation at this stage. And there are NO 
> examples of such docs in the public domain
> I am waiting for a sanitised smallish system software example to be made 
> available, which should help us identify the practical implications 
> However, ABI documentation would be part of it
> 
> If there is almost a 1:1 

Re: [Xen-devel] [PATCH 21/32] hw/i386/pc: Reduce gsi_handler scope

[Aleksandar Markovic]

On Thursday, October 17, 2019, Philippe Mathieu-Daudé 
wrote:

> On 10/17/19 5:16 PM, Aleksandar Markovic wrote:
>
>> On Tuesday, October 15, 2019, Philippe Mathieu-Daudé > > wrote:
>>
>> pc_gsi_create() is the single function that uses gsi_handler.
>> Make it a static variable.
>>
>> Signed-off-by: Philippe Mathieu-Daudé > >
>> ---
>>   hw/i386/pc.c | 2 +-
>>   include/hw/i386/pc.h | 2 --
>>   2 files changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>> index a7597c6c44..59de0c8a1f 100644
>> --- a/hw/i386/pc.c
>> +++ b/hw/i386/pc.c
>> @@ -346,7 +346,7 @@ GlobalProperty pc_compat_1_4[] = {
>>   };
>>   const size_t pc_compat_1_4_len = G_N_ELEMENTS(pc_compat_1_4);
>>
>> -void gsi_handler(void *opaque, int n, int level)
>> +static void gsi_handler(void *opaque, int n, int level)
>>   {
>>   GSIState *s = opaque;
>>
>> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
>> index d0c6b9d469..75b44e156c 100644
>> --- a/include/hw/i386/pc.h
>> +++ b/include/hw/i386/pc.h
>> @@ -172,8 +172,6 @@ typedef struct GSIState {
>>   qemu_irq ioapic_irq[IOAPIC_NUM_PINS];
>>   } GSIState;
>>
>> -void gsi_handler(void *opaque, int n, int level);
>> -
>>   GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled);
>>
>>
>> Philippe, this 2-line deletion seems not to belong to this patch. If
>> true, please place it in another or a separate patch.
>>
>
> It does, this is the point of the change, make it static and remove its
> declaration :)
>


OK, I see.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 142644
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 142644
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  67e72053c1de2457bd23af52ee6d448598dbae26
baseline version:
 libvirt  36138eaecf8920d843ca3b1cec38cc765369144c

Last test of basis   142644  2019-10-12 04:18:51 Z5 days
Failing since142761  2019-10-15 04:18:46 Z2 days2 attempts
Testing same since   142798  2019-10-16 04:18:46 Z1 days1 attempts


People who touched revisions under test:
  Daniel P. Berrangé 
  Ján Tomko 
  Michal Privoznik 
  Pavel Mores 

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  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/libvirt.git
   36138eaecf..67e72053c1  67e72053c1de2457bd23af52ee6d448598dbae26 -> 
xen-tested-master

___
Xen-devel mailing list

Re: [Xen-devel] [PATCH 21/32] hw/i386/pc: Reduce gsi_handler scope

[Thomas Huth]

On 15/10/2019 18.26, Philippe Mathieu-Daudé wrote:
> pc_gsi_create() is the single function that uses gsi_handler.
> Make it a static variable.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/i386/pc.c | 2 +-
>  include/hw/i386/pc.h | 2 --
>  2 files changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index a7597c6c44..59de0c8a1f 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -346,7 +346,7 @@ GlobalProperty pc_compat_1_4[] = {
>  };
>  const size_t pc_compat_1_4_len = G_N_ELEMENTS(pc_compat_1_4);
>  
> -void gsi_handler(void *opaque, int n, int level)
> +static void gsi_handler(void *opaque, int n, int level)
>  {
>  GSIState *s = opaque;
>  
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index d0c6b9d469..75b44e156c 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -172,8 +172,6 @@ typedef struct GSIState {
>  qemu_irq ioapic_irq[IOAPIC_NUM_PINS];
>  } GSIState;
>  
> -void gsi_handler(void *opaque, int n, int level);
> -
>  GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled);
>  
>  /* vmport.c */
> 

Reviewed-by: Thomas Huth 

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

Re: [Xen-devel] [PATCH 02/32] hw/i386/pc: Move kvm_i8259_init() declaration to sysemu/kvm.h

[Thomas Huth]

On 17/10/2019 17.31, Philippe Mathieu-Daudé wrote:
> On 10/17/19 5:04 PM, Thomas Huth wrote:
>> On 15/10/2019 18.26, Philippe Mathieu-Daudé wrote:
>>> Move the KVM-related call to "sysemu/kvm.h".
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé 
>>> ---
>>>   include/hw/i386/pc.h | 1 -
>>>   include/sysemu/kvm.h | 1 +
>>>   2 files changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
>>> index 6df4f4b6fb..09e74e7764 100644
>>> --- a/include/hw/i386/pc.h
>>> +++ b/include/hw/i386/pc.h
>>> @@ -158,7 +158,6 @@ typedef struct PCMachineClass {
>>>     extern DeviceState *isa_pic;
>>>   qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq);
>>> -qemu_irq *kvm_i8259_init(ISABus *bus);
>>>   int pic_read_irq(DeviceState *d);
>>>   int pic_get_output(DeviceState *d);
>>>   diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
>>> index 9d143282bc..da8aa9f5a8 100644
>>> --- a/include/sysemu/kvm.h
>>> +++ b/include/sysemu/kvm.h
>>> @@ -513,6 +513,7 @@ void kvm_irqchip_set_qemuirq_gsi(KVMState *s,
>>> qemu_irq irq, int gsi);
>>>   void kvm_pc_gsi_handler(void *opaque, int n, int level);
>>>   void kvm_pc_setup_irq_routing(bool pci_enabled);
>>>   void kvm_init_irq_routing(KVMState *s);
>>> +qemu_irq *kvm_i8259_init(ISABus *bus);
>>
>> Why? The function is defined in hw/i386/kvm/ - so moving its prototype
>> to a generic header sounds wrong to me.
> 
> This function is declared when compiling without KVM, and is available
> on the Alpha/HPPA/MIPS which don't have it.

Sorry, I failed to parse your last sentence. It's only used by hw/i386
code as far as I can see.

> You'd rather move the kvm_pc_* declarations to hw/i386/kvm/?

Maybe, but that's certainly something for a different patch series.

This series here should focus on what you've mentioned in the cover
letter, I think. It's already big enough.

 Thomas

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

Re: [Xen-devel] [PATCH 21/32] hw/i386/pc: Reduce gsi_handler scope

[Philippe Mathieu-Daudé]

On 10/17/19 5:16 PM, Aleksandar Markovic wrote:
On Tuesday, October 15, 2019, Philippe Mathieu-Daudé > wrote:


pc_gsi_create() is the single function that uses gsi_handler.
Make it a static variable.

Signed-off-by: Philippe Mathieu-Daudé mailto:phi...@redhat.com>>
---
  hw/i386/pc.c         | 2 +-
  include/hw/i386/pc.h | 2 --
  2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index a7597c6c44..59de0c8a1f 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -346,7 +346,7 @@ GlobalProperty pc_compat_1_4[] = {
  };
  const size_t pc_compat_1_4_len = G_N_ELEMENTS(pc_compat_1_4);

-void gsi_handler(void *opaque, int n, int level)
+static void gsi_handler(void *opaque, int n, int level)
  {
      GSIState *s = opaque;

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index d0c6b9d469..75b44e156c 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -172,8 +172,6 @@ typedef struct GSIState {
      qemu_irq ioapic_irq[IOAPIC_NUM_PINS];
  } GSIState;

-void gsi_handler(void *opaque, int n, int level);
-
  GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled);


Philippe, this 2-line deletion seems not to belong to this patch. If 
true, please place it in another or a separate patch.


It does, this is the point of the change, make it static and remove its 
declaration :)


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

Re: [Xen-devel] [PATCH 20/32] hw/i386/pc: Extract pc_gsi_create()

[Thomas Huth]

On 15/10/2019 18.26, Philippe Mathieu-Daudé wrote:
> The GSI creation code is common to all PC machines, extract the
> common code.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/i386/pc.c | 15 +++
>  hw/i386/pc_piix.c|  9 +
>  hw/i386/pc_q35.c |  9 +
>  include/hw/i386/pc.h |  2 ++
>  4 files changed, 19 insertions(+), 16 deletions(-)

Is this really needed for this series here, or should this and the
following patches maybe rather be handled seperately?

Anyway, it looks like a good modification, so:
Reviewed-by: Thomas Huth 

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

Re: [Xen-devel] [PATCH 02/32] hw/i386/pc: Move kvm_i8259_init() declaration to sysemu/kvm.h

[Philippe Mathieu-Daudé]

On 10/17/19 5:04 PM, Thomas Huth wrote:

On 15/10/2019 18.26, Philippe Mathieu-Daudé wrote:

Move the KVM-related call to "sysemu/kvm.h".

Signed-off-by: Philippe Mathieu-Daudé 
---
  include/hw/i386/pc.h | 1 -
  include/sysemu/kvm.h | 1 +
  2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 6df4f4b6fb..09e74e7764 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -158,7 +158,6 @@ typedef struct PCMachineClass {
  
  extern DeviceState *isa_pic;

  qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq);
-qemu_irq *kvm_i8259_init(ISABus *bus);
  int pic_read_irq(DeviceState *d);
  int pic_get_output(DeviceState *d);
  
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h

index 9d143282bc..da8aa9f5a8 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -513,6 +513,7 @@ void kvm_irqchip_set_qemuirq_gsi(KVMState *s, qemu_irq irq, 
int gsi);
  void kvm_pc_gsi_handler(void *opaque, int n, int level);
  void kvm_pc_setup_irq_routing(bool pci_enabled);
  void kvm_init_irq_routing(KVMState *s);
+qemu_irq *kvm_i8259_init(ISABus *bus);


Why? The function is defined in hw/i386/kvm/ - so moving its prototype
to a generic header sounds wrong to me.


This function is declared when compiling without KVM, and is available 
on the Alpha/HPPA/MIPS which don't have it.


You'd rather move the kvm_pc_* declarations to hw/i386/kvm/?

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

Re: [Xen-devel] [PATCH 22/32] hw/i386/pc: Move gsi_state creation code

[Aleksandar Markovic]

On Tuesday, October 15, 2019, Philippe Mathieu-Daudé 
wrote:

> The block code related to IRQ start few lines later. Move


block code -> code block
start -> starts

the comment and the pc_gsi_create() call

where we start


call -> invocation


> to use the IRQs.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/i386/pc_q35.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> index 52261962b8..6d096eff28 100644
> --- a/hw/i386/pc_q35.c
> +++ b/hw/i386/pc_q35.c
> @@ -209,9 +209,6 @@ static void pc_q35_init(MachineState *machine)
> rom_memory, _memory);
>  }
>
> -/* irq lines */
> -gsi_state = pc_gsi_create(>gsi, pcmc->pci_enabled);
> -
>  /* create pci host bus */
>  q35_host = Q35_HOST_DEVICE(qdev_create(NULL, TYPE_Q35_HOST_DEVICE));
>
> @@ -245,6 +242,9 @@ static void pc_q35_init(MachineState *machine)
>  object_property_set_link(OBJECT(machine), OBJECT(lpc),
>   PC_MACHINE_ACPI_DEVICE_PROP, _abort);
>
> +/* irq lines */
> +gsi_state = pc_gsi_create(>gsi, pcmc->pci_enabled);
> +
>  ich9_lpc = ICH9_LPC_DEVICE(lpc);
>  lpc_dev = DEVICE(lpc);
>  for (i = 0; i < GSI_NUM_PINS; i++) {
> --
> 2.21.0
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 14/32] piix4: add a i8257 dma controller as specified in datasheet

[Thomas Huth]

On 15/10/2019 18.26, Philippe Mathieu-Daudé wrote:
> 
> Remove i8257 instanciated in malta board, to not have it twice.

s/instanciated/instantiated/

 Thomas

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

Re: [Xen-devel] [PATCH 11/32] Revert "irq: introduce qemu_irq_proxy()"

[Thomas Huth]

On 15/10/2019 18.26, Philippe Mathieu-Daudé wrote:
> From: Philippe Mathieu-Daudé 
> 
> This function isn't used anymore.
> 
> This reverts commit 22ec3283efba9ba0792790da786d6776d83f2a92.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/core/irq.c| 14 --
>  include/hw/irq.h |  5 -
>  2 files changed, 19 deletions(-)
>
Reviewed-by: Thomas Huth 

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

Re: [Xen-devel] [PATCH 21/32] hw/i386/pc: Reduce gsi_handler scope

[Aleksandar Markovic]

On Tuesday, October 15, 2019, Philippe Mathieu-Daudé 
wrote:

> pc_gsi_create() is the single function that uses gsi_handler.
> Make it a static variable.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/i386/pc.c | 2 +-
>  include/hw/i386/pc.h | 2 --
>  2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index a7597c6c44..59de0c8a1f 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -346,7 +346,7 @@ GlobalProperty pc_compat_1_4[] = {
>  };
>  const size_t pc_compat_1_4_len = G_N_ELEMENTS(pc_compat_1_4);
>
> -void gsi_handler(void *opaque, int n, int level)
> +static void gsi_handler(void *opaque, int n, int level)
>  {
>  GSIState *s = opaque;
>
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index d0c6b9d469..75b44e156c 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -172,8 +172,6 @@ typedef struct GSIState {
>  qemu_irq ioapic_irq[IOAPIC_NUM_PINS];
>  } GSIState;
>
> -void gsi_handler(void *opaque, int n, int level);
> -
>  GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled);
>
>
Philippe, this 2-line deletion seems not to belong to this patch. If true,
please place it in another or a separate patch.

A.



>  /* vmport.c */
> --
> 2.21.0
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 2/4] x2APIC: simplify resume

[Roger Pau Monné]

On Thu, Oct 17, 2019 at 10:26:08AM +0200, Marek Marczykowski-Górecki wrote:
> On Tue, Oct 15, 2019 at 05:47:34PM +0200, Roger Pau Monne wrote:
> > There's no need to save and restore the IO-APIC entries, the entries
> > prior to suspension have already been saved by ioapic_suspend, and
> > will be restored by ioapic_resume. Note that at the point where
> > resume_x2apic gets called the IO-APIC has not yet resumed, and hence
> > all entries should be masked.
> > 
> > Note this shouldn't introduce any functional change.
> > 
> > Suggested-by: Jan Beulich 
> > Signed-off-by: Roger Pau Monné 
> 
> I've tried host suspend without any domU running and it works. I've tested
> just this patch without others in the series, does it matter?

No that's fine.

> Tested-by: Marek Marczykowski-Górecki 

Thanks.

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

Re: [Xen-devel] [PATCH 08/32] piix4: rename some variables in realize function

[Thomas Huth]

On 15/10/2019 18.26, Philippe Mathieu-Daudé wrote:
> From: Hervé Poussineau 
> 
> PIIX4 structure is now 's'
> PCI device is now 'pci_dev'
> DeviceState is now 'dev'

Why? Just for the sake of it?

> Acked-by: Michael S. Tsirkin 
> Acked-by: Paolo Bonzini 
> Signed-off-by: Hervé Poussineau 
> Message-Id: <20171216090228.28505-6-hpous...@reactos.org>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/isa/piix4.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
> index 3294056cd5..4202243e41 100644
> --- a/hw/isa/piix4.c
> +++ b/hw/isa/piix4.c
> @@ -88,16 +88,17 @@ static const VMStateDescription vmstate_piix4 = {
>  }
>  };
>  
> -static void piix4_realize(PCIDevice *dev, Error **errp)
> +static void piix4_realize(PCIDevice *pci_dev, Error **errp)
>  {
> -PIIX4State *d = PIIX4_PCI_DEVICE(dev);
> +DeviceState *dev = DEVICE(pci_dev);
> +PIIX4State *s = DO_UPCAST(PIIX4State, dev, pci_dev);

AFAIK we rather want to get rid of DO_UPCAST in the long run, so please
don't introduce new ones!

See:
https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg05244.html

Unless there is a real need for the rename, I'd suggest to rather drop
this patch.

 Thomas

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

Re: [Xen-devel] How PV frontend and backend initializes?

[Roger Pau Monné]

On Wed, Oct 16, 2019 at 10:47:09PM +, tosher 1 wrote:
> 
> Anthony and Roger, thanks for your informative responses. It helped a lot.
> 
> 
> > I'm however unsure by what you mean with instance, so you might have
> > to clarify exactly what you mean in order to get a more concise
> > reply.
> 
> Let's say there are two DomU's, and their respective network interfaces are 
> xenbr0 and xenbr1. Therefore, there supposed to be two PV netback drivers 
> running in Dom0 (or driver domain): one for xenbr0 and another for xenbr1. By 
> the term instance, I am refering to these drivers. If later there comes 
> another interface xenbr3, there will be the third instance of the backend 
> driver. I was wondering how these multiple instances are created and when.

I would avoid using xenbr* as the nomenclature here. xenbr0 is usually
a bridge with a physical network interface that provides outside
access to guests. The network interfaces you are refereeing to are
usually called vifs, and have vif. nomenclature by
default (you can change the interface name on the xl.cfg config file).

> Now, as you pointed to the xen toolstack, I explored xl/libxl a little bit. I 
> realized for two separate devices, libxl creates two different paths both for 
> the frontend and backend. The OSes keeps watching xenstore paths. If an OS 
> finds a device of the type it is interested in, it creates the instance of 
> the corresponding driver (frontend or backend) if the device is not 
> initialized already. The path is the parameter which make one instance 
> different from the others.

Those instances are ultimately created by netback as a response to
device data being populated on xenstore, see xenvif_alloc in the Linux
kernel.

Roger.

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

Re: [Xen-devel] [PATCH 20/32] hw/i386/pc: Extract pc_gsi_create()

[Aleksandar Markovic]

On Tuesday, October 15, 2019, Philippe Mathieu-Daudé 
wrote:

> The GSI creation code is common to all PC machines, extract the
> common code.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/i386/pc.c | 15 +++
>  hw/i386/pc_piix.c|  9 +
>  hw/i386/pc_q35.c |  9 +
>  include/hw/i386/pc.h |  2 ++
>  4 files changed, 19 insertions(+), 16 deletions(-)
>
>
Reviewed-by: Aleksandar Markovic 


> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index bcda50efcc..a7597c6c44 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -357,6 +357,21 @@ void gsi_handler(void *opaque, int n, int level)
>  qemu_set_irq(s->ioapic_irq[n], level);
>  }
>
> +GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled)
> +{
> +GSIState *s;
> +
> +s = g_new0(GSIState, 1);
> +if (kvm_ioapic_in_kernel()) {
> +kvm_pc_setup_irq_routing(pci_enabled);
> +*irqs = qemu_allocate_irqs(kvm_pc_gsi_handler, s, GSI_NUM_PINS);
> +} else {
> +*irqs = qemu_allocate_irqs(gsi_handler, s, GSI_NUM_PINS);
> +}
> +
> +return s;
> +}
> +
>  static void ioport80_write(void *opaque, hwaddr addr, uint64_t data,
> unsigned size)
>  {
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 431965d921..452b107e1b 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -188,14 +188,7 @@ static void pc_init1(MachineState *machine,
>  xen_load_linux(pcms);
>  }
>
> -gsi_state = g_malloc0(sizeof(*gsi_state));
> -if (kvm_ioapic_in_kernel()) {
> -kvm_pc_setup_irq_routing(pcmc->pci_enabled);
> -pcms->gsi = qemu_allocate_irqs(kvm_pc_gsi_handler, gsi_state,
> -   GSI_NUM_PINS);
> -} else {
> -pcms->gsi = qemu_allocate_irqs(gsi_handler, gsi_state,
> GSI_NUM_PINS);
> -}
> +gsi_state = pc_gsi_create(>gsi, pcmc->pci_enabled);
>
>  if (pcmc->pci_enabled) {
>  pci_bus = i440fx_init(host_type,
> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
> index 8fad20f314..52261962b8 100644
> --- a/hw/i386/pc_q35.c
> +++ b/hw/i386/pc_q35.c
> @@ -210,14 +210,7 @@ static void pc_q35_init(MachineState *machine)
>  }
>
>  /* irq lines */
> -gsi_state = g_malloc0(sizeof(*gsi_state));
> -if (kvm_ioapic_in_kernel()) {
> -kvm_pc_setup_irq_routing(pcmc->pci_enabled);
> -pcms->gsi = qemu_allocate_irqs(kvm_pc_gsi_handler, gsi_state,
> -   GSI_NUM_PINS);
> -} else {
> -pcms->gsi = qemu_allocate_irqs(gsi_handler, gsi_state,
> GSI_NUM_PINS);
> -}
> +gsi_state = pc_gsi_create(>gsi, pcmc->pci_enabled);
>
>  /* create pci host bus */
>  q35_host = Q35_HOST_DEVICE(qdev_create(NULL, TYPE_Q35_HOST_DEVICE));
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index b63fc7631e..d0c6b9d469 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -174,6 +174,8 @@ typedef struct GSIState {
>
>  void gsi_handler(void *opaque, int n, int level);
>
> +GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled);
> +
>  /* vmport.c */
>  #define TYPE_VMPORT "vmport"
>  typedef uint32_t (VMPortReadFunc)(void *opaque, uint32_t address);
> --
> 2.21.0
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 04/32] mc146818rtc: Move RTC_ISA_IRQ definition

[Philippe Mathieu-Daudé]

On 10/17/19 5:02 PM, Aleksandar Markovic wrote:



On Tuesday, October 15, 2019, Philippe Mathieu-Daudé > wrote:


From: Philippe Mathieu-Daudé mailto:f4...@amsat.org>>

The ISA default number for the RTC devices is not related to its
registers neither. Move this definition to "hw/timer/mc146818rtc.h".

Signed-off-by: Philippe Mathieu-Daudé mailto:phi...@redhat.com>>
---
  include/hw/timer/mc146818rtc.h      | 2 ++
  include/hw/timer/mc146818rtc_regs.h | 2 --
  tests/rtc-test.c                    | 1 +
  3 files changed, 3 insertions(+), 2 deletions(-)


Philippe, do this and related patches clash with your recent 
reorganization of timers/rtcs?


Indeed, but since big boring series take time to get merged, I prefer to 
have it reviewed already, then I'll rebase and fix conflicts on the one 
that isn't merged.


Thanks for reviewing the other patches!


A.

diff --git a/include/hw/timer/mc146818rtc.h
b/include/hw/timer/mc146818rtc.h
index 0f1c886e5b..17761cf6d9 100644
--- a/include/hw/timer/mc146818rtc.h
+++ b/include/hw/timer/mc146818rtc.h
@@ -39,6 +39,8 @@ typedef struct RTCState {
      QLIST_ENTRY(RTCState) link;
  } RTCState;

+#define RTC_ISA_IRQ 8
+
  ISADevice *mc146818_rtc_init(ISABus *bus, int base_year,
                               qemu_irq intercept_irq);
  void rtc_set_memory(ISADevice *dev, int addr, int val);
diff --git a/include/hw/timer/mc146818rtc_regs.h
b/include/hw/timer/mc146818rtc_regs.h
index bfbb57e570..631f71cfd9 100644
--- a/include/hw/timer/mc146818rtc_regs.h
+++ b/include/hw/timer/mc146818rtc_regs.h
@@ -27,8 +27,6 @@

  #include "qemu/timer.h"

-#define RTC_ISA_IRQ 8
-
  #define RTC_SECONDS             0
  #define RTC_SECONDS_ALARM       1
  #define RTC_MINUTES             2
diff --git a/tests/rtc-test.c b/tests/rtc-test.c
index 6309b0ef6c..18f895690f 100644
--- a/tests/rtc-test.c
+++ b/tests/rtc-test.c
@@ -15,6 +15,7 @@

  #include "libqtest-single.h"
  #include "qemu/timer.h"
+#include "hw/timer/mc146818rtc.h"
  #include "hw/timer/mc146818rtc_regs.h"

  #define UIP_HOLD_LENGTH           (8 * NANOSECONDS_PER_SECOND / 32768)
-- 
2.21.0





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

Re: [Xen-devel] [PATCH 13/32] piix4: convert reset function to QOM

[Aleksandar Markovic]

On Tuesday, October 15, 2019, Philippe Mathieu-Daudé 
wrote:

> From: Hervé Poussineau 
>
> Acked-by: Michael S. Tsirkin 
> Acked-by: Paolo Bonzini 
> Signed-off-by: Hervé Poussineau 
> Message-Id: <20180106153730.30313-15-hpous...@reactos.org>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/isa/piix4.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
>
Reviewed-by: Aleksandar Markovic 


> diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
> index c3a2bd0d70..8998b0ca47 100644
> --- a/hw/isa/piix4.c
> +++ b/hw/isa/piix4.c
> @@ -48,10 +48,10 @@ typedef struct PIIX4State {
>  #define PIIX4_PCI_DEVICE(obj) \
>  OBJECT_CHECK(PIIX4State, (obj), TYPE_PIIX4_PCI_DEVICE)
>
> -static void piix4_reset(void *opaque)
> +static void piix4_reset(DeviceState *dev)
>  {
> -PIIX4State *d = opaque;
> -uint8_t *pci_conf = d->dev.config;
> +PIIX4State *s = PIIX4_PCI_DEVICE(dev);
> +uint8_t *pci_conf = s->dev.config;
>
>  pci_conf[0x04] = 0x07; // master, memory and I/O
>  pci_conf[0x05] = 0x00;
> @@ -165,7 +165,6 @@ static void piix4_realize(PCIDevice *pci_dev, Error
> **errp)
>  isa_bus_irqs(isa_bus, s->isa);
>
>  piix4_dev = pci_dev;
> -qemu_register_reset(piix4_reset, s);
>  }
>
>  static void piix4_class_init(ObjectClass *klass, void *data)
> @@ -177,6 +176,7 @@ static void piix4_class_init(ObjectClass *klass, void
> *data)
>  k->vendor_id = PCI_VENDOR_ID_INTEL;
>  k->device_id = PCI_DEVICE_ID_INTEL_82371AB_0;
>  k->class_id = PCI_CLASS_BRIDGE_ISA;
> +dc->reset = piix4_reset;
>  dc->desc = "ISA bridge";
>  dc->vmsd = _piix4;
>  /*
> --
> 2.21.0
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 02/32] hw/i386/pc: Move kvm_i8259_init() declaration to sysemu/kvm.h

[Philippe Mathieu-Daudé]

On 10/17/19 4:57 PM, Aleksandar Markovic wrote:



On Tuesday, October 15, 2019, Philippe Mathieu-Daudé > wrote:


Move the KVM-related call to "sysemu/kvm.h".


Maybe s/call/function declaration/



Signed-off-by: Philippe Mathieu-Daudé mailto:phi...@redhat.com>>
---
  include/hw/i386/pc.h | 1 -
  include/sysemu/kvm.h | 1 +
  2 files changed, 1 insertion(+), 1 deletion(-)


Is there any other similar case in our code base?


These look appropriate:

include/hw/ppc/openpic_kvm.h:5:int kvm_openpic_connect_vcpu(DeviceState 
*d, CPUState *cs);
include/hw/timer/i8254.h:67:static inline ISADevice *kvm_pit_init(ISABus 
*bus, int base)
hw/intc/vgic_common.h:25: * kvm_arm_gic_set_irq - Send an IRQ to the 
in-kernel vGIC
hw/intc/vgic_common.h:33:void kvm_arm_gic_set_irq(uint32_t num_irq, int 
irq, int level);


although kvm_pit_init() is probably borderline.



A.

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 6df4f4b6fb..09e74e7764 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -158,7 +158,6 @@ typedef struct PCMachineClass {

  extern DeviceState *isa_pic;
  qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq);
-qemu_irq *kvm_i8259_init(ISABus *bus);
  int pic_read_irq(DeviceState *d);
  int pic_get_output(DeviceState *d);

diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index 9d143282bc..da8aa9f5a8 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -513,6 +513,7 @@ void kvm_irqchip_set_qemuirq_gsi(KVMState *s,
qemu_irq irq, int gsi);
  void kvm_pc_gsi_handler(void *opaque, int n, int level);
  void kvm_pc_setup_irq_routing(bool pci_enabled);
  void kvm_init_irq_routing(KVMState *s);
+qemu_irq *kvm_i8259_init(ISABus *bus);

  /**
   * kvm_arch_irqchip_create:
-- 
2.21.0





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

Re: [Xen-devel] [PATCH 09/32] piix4: add Reset Control Register

[Aleksandar Markovic]

On Tuesday, October 15, 2019, Philippe Mathieu-Daudé 
wrote:

> From: Hervé Poussineau 
>
> The RCR I/O port (0xcf9) is used to generate a hard reset or a soft reset.
>
> Acked-by: Michael S. Tsirkin 
> Acked-by: Paolo Bonzini 
> Signed-off-by: Hervé Poussineau 
> Message-Id: <20171216090228.28505-7-hpous...@reactos.org>
> [PMD: rebased, updated includes]
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/isa/piix4.c | 40 
>  1 file changed, 40 insertions(+)
>
>
Reviewed-by: Aleksandar Markovic 



> diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
> index 4202243e41..6e2d9b9774 100644
> --- a/hw/isa/piix4.c
> +++ b/hw/isa/piix4.c
> @@ -2,6 +2,7 @@
>   * QEMU PIIX4 PCI Bridge Emulation
>   *
>   * Copyright (c) 2006 Fabrice Bellard
> + * Copyright (c) 2018 Hervé Poussineau
>   *
>   * Permission is hereby granted, free of charge, to any person obtaining
> a copy
>   * of this software and associated documentation files (the "Software"),
> to deal
> @@ -29,11 +30,16 @@
>  #include "hw/sysbus.h"
>  #include "migration/vmstate.h"
>  #include "sysemu/reset.h"
> +#include "sysemu/runstate.h"
>
>  PCIDevice *piix4_dev;
>
>  typedef struct PIIX4State {
>  PCIDevice dev;
> +
> +/* Reset Control Register */
> +MemoryRegion rcr_mem;
> +uint8_t rcr;
>  } PIIX4State;
>
>  #define TYPE_PIIX4_PCI_DEVICE "PIIX4"
> @@ -88,6 +94,34 @@ static const VMStateDescription vmstate_piix4 = {
>  }
>  };
>
> +static void piix4_rcr_write(void *opaque, hwaddr addr, uint64_t val,
> +unsigned int len)
> +{
> +PIIX4State *s = opaque;
> +
> +if (val & 4) {
> +qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET);
> +return;
> +}
> +s->rcr = val & 2; /* keep System Reset type only */
> +}
> +
> +static uint64_t piix4_rcr_read(void *opaque, hwaddr addr, unsigned int
> len)
> +{
> +PIIX4State *s = opaque;
> +return s->rcr;
> +}
> +
> +static const MemoryRegionOps piix4_rcr_ops = {
> +.read = piix4_rcr_read,
> +.write = piix4_rcr_write,
> +.endianness = DEVICE_LITTLE_ENDIAN,
> +.impl = {
> +.min_access_size = 1,
> +.max_access_size = 1,
> +},
> +};
> +
>  static void piix4_realize(PCIDevice *pci_dev, Error **errp)
>  {
>  DeviceState *dev = DEVICE(pci_dev);
> @@ -97,6 +131,12 @@ static void piix4_realize(PCIDevice *pci_dev, Error
> **errp)
>   pci_address_space_io(pci_dev), errp)) {
>  return;
>  }
> +
> +memory_region_init_io(>rcr_mem, OBJECT(dev), _rcr_ops, s,
> +  "reset-control", 1);
> +memory_region_add_subregion_overlap(pci_address_space_io(pci_dev),
> 0xcf9,
> +>rcr_mem, 1);
> +
>  piix4_dev = pci_dev;
>  qemu_register_reset(piix4_reset, s);
>  }
> --
> 2.21.0
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 08/32] piix4: rename some variables in realize function

[Aleksandar Markovic]

On Tuesday, October 15, 2019, Philippe Mathieu-Daudé 
wrote:

> From: Hervé Poussineau 
>
> PIIX4 structure is now 's'
> PCI device is now 'pci_dev'
> DeviceState is now 'dev'
>
> Acked-by: Michael S. Tsirkin 
> Acked-by: Paolo Bonzini 
> Signed-off-by: Hervé Poussineau 
> Message-Id: <20171216090228.28505-6-hpous...@reactos.org>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/isa/piix4.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
>
>
Reviewed-by: Aleksandar Markovic 



> diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
> index 3294056cd5..4202243e41 100644
> --- a/hw/isa/piix4.c
> +++ b/hw/isa/piix4.c
> @@ -88,16 +88,17 @@ static const VMStateDescription vmstate_piix4 = {
>  }
>  };
>
> -static void piix4_realize(PCIDevice *dev, Error **errp)
> +static void piix4_realize(PCIDevice *pci_dev, Error **errp)
>  {
> -PIIX4State *d = PIIX4_PCI_DEVICE(dev);
> +DeviceState *dev = DEVICE(pci_dev);
> +PIIX4State *s = DO_UPCAST(PIIX4State, dev, pci_dev);
>
> -if (!isa_bus_new(DEVICE(d), pci_address_space(dev),
> - pci_address_space_io(dev), errp)) {
> +if (!isa_bus_new(dev, pci_address_space(pci_dev),
> + pci_address_space_io(pci_dev), errp)) {
>  return;
>  }
> -piix4_dev = >dev;
> -qemu_register_reset(piix4_reset, d);
> +piix4_dev = pci_dev;
> +qemu_register_reset(piix4_reset, s);
>  }
>
>  int piix4_init(PCIBus *bus, ISABus **isa_bus, int devfn)
> --
> 2.21.0
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 02/32] hw/i386/pc: Move kvm_i8259_init() declaration to sysemu/kvm.h

[Thomas Huth]

On 15/10/2019 18.26, Philippe Mathieu-Daudé wrote:
> Move the KVM-related call to "sysemu/kvm.h".
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  include/hw/i386/pc.h | 1 -
>  include/sysemu/kvm.h | 1 +
>  2 files changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index 6df4f4b6fb..09e74e7764 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -158,7 +158,6 @@ typedef struct PCMachineClass {
>  
>  extern DeviceState *isa_pic;
>  qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq);
> -qemu_irq *kvm_i8259_init(ISABus *bus);
>  int pic_read_irq(DeviceState *d);
>  int pic_get_output(DeviceState *d);
>  
> diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
> index 9d143282bc..da8aa9f5a8 100644
> --- a/include/sysemu/kvm.h
> +++ b/include/sysemu/kvm.h
> @@ -513,6 +513,7 @@ void kvm_irqchip_set_qemuirq_gsi(KVMState *s, qemu_irq 
> irq, int gsi);
>  void kvm_pc_gsi_handler(void *opaque, int n, int level);
>  void kvm_pc_setup_irq_routing(bool pci_enabled);
>  void kvm_init_irq_routing(KVMState *s);
> +qemu_irq *kvm_i8259_init(ISABus *bus);

Why? The function is defined in hw/i386/kvm/ - so moving its prototype
to a generic header sounds wrong to me.

 Thomas

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

Re: [Xen-devel] [PATCH 08/32] piix4: rename some variables in realize function

[Aleksandar Markovic]

On Tuesday, October 15, 2019, Philippe Mathieu-Daudé 
wrote:

> From: Hervé Poussineau 
>
> PIIX4 structure is now 's'
> PCI device is now 'pci_dev'
> DeviceState is now 'dev'
>
> Acked-by: Michael S. Tsirkin 
> Acked-by: Paolo Bonzini 
> Signed-off-by: Hervé Poussineau 
> Message-Id: <20171216090228.28505-6-hpous...@reactos.org>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/isa/piix4.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
>
>
Reviewed-by: Aleksandar Markovic 


> diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
> index 3294056cd5..4202243e41 100644
> --- a/hw/isa/piix4.c
> +++ b/hw/isa/piix4.c
> @@ -88,16 +88,17 @@ static const VMStateDescription vmstate_piix4 = {
>  }
>  };
>
> -static void piix4_realize(PCIDevice *dev, Error **errp)
> +static void piix4_realize(PCIDevice *pci_dev, Error **errp)
>  {
> -PIIX4State *d = PIIX4_PCI_DEVICE(dev);
> +DeviceState *dev = DEVICE(pci_dev);
> +PIIX4State *s = DO_UPCAST(PIIX4State, dev, pci_dev);
>
> -if (!isa_bus_new(DEVICE(d), pci_address_space(dev),
> - pci_address_space_io(dev), errp)) {
> +if (!isa_bus_new(dev, pci_address_space(pci_dev),
> + pci_address_space_io(pci_dev), errp)) {
>  return;
>  }
> -piix4_dev = >dev;
> -qemu_register_reset(piix4_reset, d);
> +piix4_dev = pci_dev;
> +qemu_register_reset(piix4_reset, s);
>  }
>
>  int piix4_init(PCIBus *bus, ISABus **isa_bus, int devfn)
> --
> 2.21.0
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 04/32] mc146818rtc: Move RTC_ISA_IRQ definition

[Aleksandar Markovic]

On Tuesday, October 15, 2019, Philippe Mathieu-Daudé 
wrote:

> From: Philippe Mathieu-Daudé 
>
> The ISA default number for the RTC devices is not related to its
> registers neither. Move this definition to "hw/timer/mc146818rtc.h".
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  include/hw/timer/mc146818rtc.h  | 2 ++
>  include/hw/timer/mc146818rtc_regs.h | 2 --
>  tests/rtc-test.c| 1 +
>  3 files changed, 3 insertions(+), 2 deletions(-)
>
>
Philippe, do this and related patches clash with your recent reorganization
of timers/rtcs?

A.



> diff --git a/include/hw/timer/mc146818rtc.h b/include/hw/timer/
> mc146818rtc.h
> index 0f1c886e5b..17761cf6d9 100644
> --- a/include/hw/timer/mc146818rtc.h
> +++ b/include/hw/timer/mc146818rtc.h
> @@ -39,6 +39,8 @@ typedef struct RTCState {
>  QLIST_ENTRY(RTCState) link;
>  } RTCState;
>
> +#define RTC_ISA_IRQ 8
> +
>  ISADevice *mc146818_rtc_init(ISABus *bus, int base_year,
>   qemu_irq intercept_irq);
>  void rtc_set_memory(ISADevice *dev, int addr, int val);
> diff --git a/include/hw/timer/mc146818rtc_regs.h b/include/hw/timer/
> mc146818rtc_regs.h
> index bfbb57e570..631f71cfd9 100644
> --- a/include/hw/timer/mc146818rtc_regs.h
> +++ b/include/hw/timer/mc146818rtc_regs.h
> @@ -27,8 +27,6 @@
>
>  #include "qemu/timer.h"
>
> -#define RTC_ISA_IRQ 8
> -
>  #define RTC_SECONDS 0
>  #define RTC_SECONDS_ALARM   1
>  #define RTC_MINUTES 2
> diff --git a/tests/rtc-test.c b/tests/rtc-test.c
> index 6309b0ef6c..18f895690f 100644
> --- a/tests/rtc-test.c
> +++ b/tests/rtc-test.c
> @@ -15,6 +15,7 @@
>
>  #include "libqtest-single.h"
>  #include "qemu/timer.h"
> +#include "hw/timer/mc146818rtc.h"
>  #include "hw/timer/mc146818rtc_regs.h"
>
>  #define UIP_HOLD_LENGTH   (8 * NANOSECONDS_PER_SECOND / 32768)
> --
> 2.21.0
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 03/32] mc146818rtc: move structure to header file

[Aleksandar Markovic]

On Tuesday, October 15, 2019, Philippe Mathieu-Daudé 
wrote:

> From: Hervé Poussineau 
>
> We are now able to embed a timer in another object.
>
> Acked-by: Michael S. Tsirkin 
> Acked-by: Paolo Bonzini 
> Signed-off-by: Hervé Poussineau 
> Message-Id: <20171216090228.28505-4-hpous...@reactos.org>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/timer/mc146818rtc.c | 30 --
>  include/hw/timer/mc146818rtc.h | 33 +
>  2 files changed, 33 insertions(+), 30 deletions(-)
>
>
Reviewed-by: Aleksandar Markovic 



> diff --git a/hw/timer/mc146818rtc.c b/hw/timer/mc146818rtc.c
> index 6cb378751b..e40b54e743 100644
> --- a/hw/timer/mc146818rtc.c
> +++ b/hw/timer/mc146818rtc.c
> @@ -71,36 +71,6 @@
>  #define RTC_CLOCK_RATE32768
>  #define UIP_HOLD_LENGTH   (8 * NANOSECONDS_PER_SECOND / 32768)
>
> -#define MC146818_RTC(obj) OBJECT_CHECK(RTCState, (obj), TYPE_MC146818_RTC)
> -
> -typedef struct RTCState {
> -ISADevice parent_obj;
> -
> -MemoryRegion io;
> -MemoryRegion coalesced_io;
> -uint8_t cmos_data[128];
> -uint8_t cmos_index;
> -int32_t base_year;
> -uint64_t base_rtc;
> -uint64_t last_update;
> -int64_t offset;
> -qemu_irq irq;
> -int it_shift;
> -/* periodic timer */
> -QEMUTimer *periodic_timer;
> -int64_t next_periodic_time;
> -/* update-ended timer */
> -QEMUTimer *update_timer;
> -uint64_t next_alarm_time;
> -uint16_t irq_reinject_on_ack_count;
> -uint32_t irq_coalesced;
> -uint32_t period;
> -QEMUTimer *coalesced_timer;
> -LostTickPolicy lost_tick_policy;
> -Notifier suspend_notifier;
> -QLIST_ENTRY(RTCState) link;
> -} RTCState;
> -
>  static void rtc_set_time(RTCState *s);
>  static void rtc_update_time(RTCState *s);
>  static void rtc_set_cmos(RTCState *s, const struct tm *tm);
> diff --git a/include/hw/timer/mc146818rtc.h b/include/hw/timer/
> mc146818rtc.h
> index fe6ed63f71..0f1c886e5b 100644
> --- a/include/hw/timer/mc146818rtc.h
> +++ b/include/hw/timer/mc146818rtc.h
> @@ -1,10 +1,43 @@
>  #ifndef MC146818RTC_H
>  #define MC146818RTC_H
>
> +#include "qapi/qapi-types-misc.h"
> +#include "qemu/queue.h"
> +#include "qemu/timer.h"
>  #include "hw/isa/isa.h"
>  #include "hw/timer/mc146818rtc_regs.h"
>
>  #define TYPE_MC146818_RTC "mc146818rtc"
> +#define MC146818_RTC(obj) OBJECT_CHECK(RTCState, (obj), TYPE_MC146818_RTC)
> +
> +typedef struct RTCState {
> +ISADevice parent_obj;
> +
> +MemoryRegion io;
> +MemoryRegion coalesced_io;
> +uint8_t cmos_data[128];
> +uint8_t cmos_index;
> +int32_t base_year;
> +uint64_t base_rtc;
> +uint64_t last_update;
> +int64_t offset;
> +qemu_irq irq;
> +int it_shift;
> +/* periodic timer */
> +QEMUTimer *periodic_timer;
> +int64_t next_periodic_time;
> +/* update-ended timer */
> +QEMUTimer *update_timer;
> +uint64_t next_alarm_time;
> +uint16_t irq_reinject_on_ack_count;
> +uint32_t irq_coalesced;
> +uint32_t period;
> +QEMUTimer *coalesced_timer;
> +Notifier clock_reset_notifier;
> +LostTickPolicy lost_tick_policy;
> +Notifier suspend_notifier;
> +QLIST_ENTRY(RTCState) link;
> +} RTCState;
>
>  ISADevice *mc146818_rtc_init(ISABus *bus, int base_year,
>   qemu_irq intercept_irq);
> --
> 2.21.0
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 02/32] hw/i386/pc: Move kvm_i8259_init() declaration to sysemu/kvm.h

[Aleksandar Markovic]

On Tuesday, October 15, 2019, Philippe Mathieu-Daudé 
wrote:

> Move the KVM-related call to "sysemu/kvm.h".
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  include/hw/i386/pc.h | 1 -
>  include/sysemu/kvm.h | 1 +
>  2 files changed, 1 insertion(+), 1 deletion(-)
>
>
Is there any other similar case in our code base?

A.



> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index 6df4f4b6fb..09e74e7764 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -158,7 +158,6 @@ typedef struct PCMachineClass {
>
>  extern DeviceState *isa_pic;
>  qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq);
> -qemu_irq *kvm_i8259_init(ISABus *bus);
>  int pic_read_irq(DeviceState *d);
>  int pic_get_output(DeviceState *d);
>
> diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
> index 9d143282bc..da8aa9f5a8 100644
> --- a/include/sysemu/kvm.h
> +++ b/include/sysemu/kvm.h
> @@ -513,6 +513,7 @@ void kvm_irqchip_set_qemuirq_gsi(KVMState *s,
> qemu_irq irq, int gsi);
>  void kvm_pc_gsi_handler(void *opaque, int n, int level);
>  void kvm_pc_setup_irq_routing(bool pci_enabled);
>  void kvm_init_irq_routing(KVMState *s);
> +qemu_irq *kvm_i8259_init(ISABus *bus);
>
>  /**
>   * kvm_arch_irqchip_create:
> --
> 2.21.0
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 12/32] piix4: rename PIIX4 object to piix4-isa

[Aleksandar Markovic]

On Tuesday, October 15, 2019, Philippe Mathieu-Daudé 
wrote:

> From: Hervé Poussineau 
>
> Other piix4 parts are already named piix4-ide and piix4-usb-uhci.
>
> Reviewed-by: Philippe Mathieu-Daudé 
> Acked-by: Michael S. Tsirkin 
> Acked-by: Paolo Bonzini 
> Signed-off-by: Hervé Poussineau 
> Message-Id: <20171216090228.28505-15-hpous...@reactos.org>
> [PMD: rebased]
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/isa/piix4.c   | 1 -
>  hw/mips/mips_malta.c | 2 +-
>  include/hw/isa/isa.h | 2 ++
>  3 files changed, 3 insertions(+), 2 deletions(-)
>
>
Reviewed-by: Aleksandar Markovic 


> diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
> index 1cfc51335a..c3a2bd0d70 100644
> --- a/hw/isa/piix4.c
> +++ b/hw/isa/piix4.c
> @@ -45,7 +45,6 @@ typedef struct PIIX4State {
>  uint8_t rcr;
>  } PIIX4State;
>
> -#define TYPE_PIIX4_PCI_DEVICE "PIIX4"
>  #define PIIX4_PCI_DEVICE(obj) \
>  OBJECT_CHECK(PIIX4State, (obj), TYPE_PIIX4_PCI_DEVICE)
>
> diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
> index 7d25ab6c23..e499b7a6bb 100644
> --- a/hw/mips/mips_malta.c
> +++ b/hw/mips/mips_malta.c
> @@ -1414,7 +1414,7 @@ void mips_malta_init(MachineState *machine)
>  ide_drive_get(hd, ARRAY_SIZE(hd));
>
>  pci = pci_create_simple_multifunction(pci_bus, PCI_DEVFN(10, 0),
> -  true, "PIIX4");
> +  true, TYPE_PIIX4_PCI_DEVICE);
>  dev = DEVICE(pci);
>  isa_bus = ISA_BUS(qdev_get_child_bus(dev, "isa.0"));
>  piix4_devfn = pci->devfn;
> diff --git a/include/hw/isa/isa.h b/include/hw/isa/isa.h
> index 018ada4f6f..79f703fd6c 100644
> --- a/include/hw/isa/isa.h
> +++ b/include/hw/isa/isa.h
> @@ -147,4 +147,6 @@ static inline ISABus *isa_bus_from_device(ISADevice *d)
>  return ISA_BUS(qdev_get_parent_bus(DEVICE(d)));
>  }
>
> +#define TYPE_PIIX4_PCI_DEVICE "piix4-isa"
> +
>  #endif
> --
> 2.21.0
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 19/32] hw/isa/piix4: Move piix4_create() to hw/isa/piix4.c

[Aleksandar Markovic]

On Tuesday, October 15, 2019, Philippe Mathieu-Daudé 
wrote:

> From: Philippe Mathieu-Daudé 
>
> Now that we properly refactored the piix4_create() function, let's
> move it to hw/isa/piix4.c where it belongs, so it can be reused
> on other places.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/isa/piix4.c| 30 ++
>  hw/mips/gt64xxx_pci.c |  1 +
>  hw/mips/mips_malta.c  | 28 
>  include/hw/i386/pc.h  |  2 --
>  include/hw/southbridge/piix.h |  6 ++
>  5 files changed, 37 insertions(+), 30 deletions(-)
>
>
Reviewed-by: Aleksandar Markovic 



> diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
> index 9f554747af..d90899e122 100644
> --- a/hw/isa/piix4.c
> +++ b/hw/isa/piix4.c
> @@ -27,12 +27,14 @@
>  #include "qapi/error.h"
>  #include "hw/irq.h"
>  #include "hw/i386/pc.h"
> +#include "hw/southbridge/piix.h"
>  #include "hw/pci/pci.h"
>  #include "hw/isa/isa.h"
>  #include "hw/sysbus.h"
>  #include "hw/dma/i8257.h"
>  #include "hw/timer/i8254.h"
>  #include "hw/timer/mc146818rtc.h"
> +#include "hw/ide.h"
>  #include "migration/vmstate.h"
>  #include "sysemu/reset.h"
>  #include "sysemu/runstate.h"
> @@ -234,3 +236,31 @@ static void piix4_register_types(void)
>  }
>
>  type_init(piix4_register_types)
> +
> +DeviceState *piix4_create(PCIBus *pci_bus, ISABus **isa_bus,
> +  I2CBus **smbus, size_t ide_buses)
> +{
> +size_t ide_drives = ide_buses * MAX_IDE_DEVS;
> +DriveInfo **hd;
> +PCIDevice *pci;
> +DeviceState *dev;
> +
> +pci = pci_create_simple_multifunction(pci_bus, PCI_DEVFN(10, 0),
> +  true, TYPE_PIIX4_PCI_DEVICE);
> +dev = DEVICE(pci);
> +if (isa_bus) {
> +*isa_bus = ISA_BUS(qdev_get_child_bus(dev, "isa.0"));
> +}
> +
> +hd = g_new(DriveInfo *, ide_drives);
> +ide_drive_get(hd, ide_drives);
> +pci_piix4_ide_init(pci_bus, hd, pci->devfn + 1);
> +g_free(hd);
> +pci_create_simple(pci_bus, pci->devfn + 2, "piix4-usb-uhci");
> +if (smbus) {
> +*smbus = piix4_pm_init(pci_bus, pci->devfn + 3, 0x1100,
> +   isa_get_irq(NULL, 9), NULL, 0, NULL);
> +   }
> +
> +return dev;
> +}
> diff --git a/hw/mips/gt64xxx_pci.c b/hw/mips/gt64xxx_pci.c
> index f325bd6c1c..c277398c0d 100644
> --- a/hw/mips/gt64xxx_pci.c
> +++ b/hw/mips/gt64xxx_pci.c
> @@ -28,6 +28,7 @@
>  #include "hw/mips/mips.h"
>  #include "hw/pci/pci.h"
>  #include "hw/pci/pci_host.h"
> +#include "hw/southbridge/piix.h"
>  #include "migration/vmstate.h"
>  #include "hw/i386/pc.h"
>  #include "hw/irq.h"
> diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
> index 0d4312840b..477a4725c0 100644
> --- a/hw/mips/mips_malta.c
> +++ b/hw/mips/mips_malta.c
> @@ -1210,34 +1210,6 @@ static void mips_create_cpu(MachineState *ms,
> MaltaState *s,
>  }
>  }
>
> -static DeviceState *piix4_create(PCIBus *pci_bus, ISABus **isa_bus,
> - I2CBus **smbus, size_t ide_buses)
> -{
> -const size_t ide_drives = ide_buses * MAX_IDE_DEVS;
> -DriveInfo **hd;
> -PCIDevice *pci;
> -DeviceState *dev;
> -
> -pci = pci_create_simple_multifunction(pci_bus, PCI_DEVFN(10, 0),
> -  true, TYPE_PIIX4_PCI_DEVICE);
> -dev = DEVICE(pci);
> -if (isa_bus) {
> -*isa_bus = ISA_BUS(qdev_get_child_bus(dev, "isa.0"));
> -}
> -
> -hd = g_new(DriveInfo *, ide_drives);
> -ide_drive_get(hd, ide_drives);
> -pci_piix4_ide_init(pci_bus, hd, pci->devfn + 1);
> -g_free(hd);
> -pci_create_simple(pci_bus, pci->devfn + 2, "piix4-usb-uhci");
> -if (smbus) {
> -*smbus = piix4_pm_init(pci_bus, pci->devfn + 3, 0x1100,
> -   isa_get_irq(NULL, 9), NULL, 0, NULL);
> -   }
> -
> -return dev;
> -}
> -
>  static
>  void mips_malta_init(MachineState *machine)
>  {
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index c671c9fd2a..b63fc7631e 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -274,8 +274,6 @@ PCIBus *i440fx_init(const char *host_type, const char
> *pci_type,
>  MemoryRegion *ram_memory);
>
>  PCIBus *find_i440fx(void);
> -/* piix4.c */
> -extern PCIDevice *piix4_dev;
>
>  /* pc_sysfw.c */
>  void pc_system_flash_create(PCMachineState *pcms);
> diff --git a/include/hw/southbridge/piix.h b/include/hw/southbridge/piix.h
> index b8ce26fec4..add352456b 100644
> --- a/include/hw/southbridge/piix.h
> +++ b/include/hw/southbridge/piix.h
> @@ -2,6 +2,7 @@
>   * QEMU PIIX South Bridge Emulation
>   *
>   * Copyright (c) 2006 Fabrice Bellard
> + * Copyright (c) 2018 Hervé Poussineau
>   *
>   * This work is licensed under the terms of the GNU GPL, version 2 or
> later.
>   * See the COPYING file in the top-level directory.
> @@ -17,4 +18,9 @@ I2CBus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t
> smb_io_base,
>

Re: [Xen-devel] [PATCH 18/32] hw/mips/mips_malta: Extract the PIIX4 creation code as piix4_create()

[Aleksandar Markovic]

On Tuesday, October 15, 2019, Philippe Mathieu-Daudé 
wrote:

> The Malta board instantiate a PIIX4 chipset doing various
> calls. Refactor all those related calls into a single
> function: piix4_create().
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/mips/mips_malta.c | 47 +++-
>  1 file changed, 29 insertions(+), 18 deletions(-)
>
>
Reviewed-by: Aleksandar Markovic 



> diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
> index 774bb810f6..0d4312840b 100644
> --- a/hw/mips/mips_malta.c
> +++ b/hw/mips/mips_malta.c
> @@ -1210,6 +1210,34 @@ static void mips_create_cpu(MachineState *ms,
> MaltaState *s,
>  }
>  }
>
> +static DeviceState *piix4_create(PCIBus *pci_bus, ISABus **isa_bus,
> + I2CBus **smbus, size_t ide_buses)
> +{
> +const size_t ide_drives = ide_buses * MAX_IDE_DEVS;
> +DriveInfo **hd;
> +PCIDevice *pci;
> +DeviceState *dev;
> +
> +pci = pci_create_simple_multifunction(pci_bus, PCI_DEVFN(10, 0),
> +  true, TYPE_PIIX4_PCI_DEVICE);
> +dev = DEVICE(pci);
> +if (isa_bus) {
> +*isa_bus = ISA_BUS(qdev_get_child_bus(dev, "isa.0"));
> +}
> +
> +hd = g_new(DriveInfo *, ide_drives);
> +ide_drive_get(hd, ide_drives);
> +pci_piix4_ide_init(pci_bus, hd, pci->devfn + 1);
> +g_free(hd);
> +pci_create_simple(pci_bus, pci->devfn + 2, "piix4-usb-uhci");
> +if (smbus) {
> +*smbus = piix4_pm_init(pci_bus, pci->devfn + 3, 0x1100,
> +   isa_get_irq(NULL, 9), NULL, 0, NULL);
> +   }
> +
> +return dev;
> +}
> +
>  static
>  void mips_malta_init(MachineState *machine)
>  {
> @@ -1231,12 +1259,8 @@ void mips_malta_init(MachineState *machine)
>  PCIBus *pci_bus;
>  ISABus *isa_bus;
>  qemu_irq cbus_irq, i8259_irq;
> -PCIDevice *pci;
> -int piix4_devfn;
>  I2CBus *smbus;
>  DriveInfo *dinfo;
> -const size_t ide_drives = MAX_IDE_BUS * MAX_IDE_DEVS;
> -DriveInfo **hd;
>  int fl_idx = 0;
>  int be;
>
> @@ -1407,14 +1431,7 @@ void mips_malta_init(MachineState *machine)
>  pci_bus = gt64120_register(s->i8259);
>
>  /* Southbridge */
> -hd = g_new(DriveInfo *, ide_drives);
> -ide_drive_get(hd, ide_drives);
> -
> -pci = pci_create_simple_multifunction(pci_bus, PCI_DEVFN(10, 0),
> -  true, TYPE_PIIX4_PCI_DEVICE);
> -dev = DEVICE(pci);
> -isa_bus = ISA_BUS(qdev_get_child_bus(dev, "isa.0"));
> -piix4_devfn = pci->devfn;
> +dev = piix4_create(pci_bus, _bus, , MAX_IDE_BUS);
>
>  /* Interrupt controller */
>  qdev_connect_gpio_out_named(dev, "intr", 0, i8259_irq);
> @@ -1422,12 +1439,6 @@ void mips_malta_init(MachineState *machine)
>  s->i8259[i] = qdev_get_gpio_in_named(dev, "isa", i);
>  }
>
> -pci_piix4_ide_init(pci_bus, hd, piix4_devfn + 1);
> -g_free(hd);
> -pci_create_simple(pci_bus, piix4_devfn + 2, "piix4-usb-uhci");
> -smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100,
> -  isa_get_irq(NULL, 9), NULL, 0, NULL);
> -
>  /* generate SPD EEPROM data */
>  generate_eeprom_spd(_eeprom_buf[0 * 256], ram_size);
>  generate_eeprom_serial(_eeprom_buf[6 * 256]);
> --
> 2.21.0
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 17/32] hw/mips/mips_malta: Create IDE hard drive array dynamically

[Aleksandar Markovic]

On Tuesday, October 15, 2019, Philippe Mathieu-Daudé 
wrote:

> In the next commit we'll refactor the PIIX4 code out of
> mips_malta_init(). As a preliminary step, add the 'ide_drives'
> variable and create the drive array dynamically.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/mips/mips_malta.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
>
Reviewed-by: Aleksandar Markovic 


> diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
> index 528c34a1c3..774bb810f6 100644
> --- a/hw/mips/mips_malta.c
> +++ b/hw/mips/mips_malta.c
> @@ -1235,7 +1235,8 @@ void mips_malta_init(MachineState *machine)
>  int piix4_devfn;
>  I2CBus *smbus;
>  DriveInfo *dinfo;
> -DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
> +const size_t ide_drives = MAX_IDE_BUS * MAX_IDE_DEVS;
> +DriveInfo **hd;
>  int fl_idx = 0;
>  int be;
>
> @@ -1406,7 +1407,8 @@ void mips_malta_init(MachineState *machine)
>  pci_bus = gt64120_register(s->i8259);
>
>  /* Southbridge */
> -ide_drive_get(hd, ARRAY_SIZE(hd));
> +hd = g_new(DriveInfo *, ide_drives);
> +ide_drive_get(hd, ide_drives);
>
>  pci = pci_create_simple_multifunction(pci_bus, PCI_DEVFN(10, 0),
>true, TYPE_PIIX4_PCI_DEVICE);
> @@ -1421,6 +1423,7 @@ void mips_malta_init(MachineState *machine)
>  }
>
>  pci_piix4_ide_init(pci_bus, hd, piix4_devfn + 1);
> +g_free(hd);
>  pci_create_simple(pci_bus, piix4_devfn + 2, "piix4-usb-uhci");
>  smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100,
>isa_get_irq(NULL, 9), NULL, 0, NULL);
> --
> 2.21.0
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 16/32] piix4: add a mc146818rtc controller as specified in datasheet

[Aleksandar Markovic]

On Tuesday, October 15, 2019, Philippe Mathieu-Daudé 
wrote:

> From: Philippe Mathieu-Daudé 
>
> Remove mc146818rtc instanciated in malta board, to not have it twice.
>
> Acked-by: Michael S. Tsirkin 
> Acked-by: Paolo Bonzini 
> Signed-off-by: Hervé Poussineau 
> Message-Id: <20171216090228.28505-13-hpous...@reactos.org>
> [PMD: rebased, set RTC base_year to 2000]
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  MAINTAINERS   |  3 ++-
>  hw/acpi/piix4.c   |  2 +-
>  hw/i386/acpi-build.c  |  3 +--
>  hw/i386/pc_piix.c |  1 +
>  hw/isa/piix4.c| 22 ++
>  hw/mips/mips_malta.c  |  4 +---
>  include/hw/acpi/piix4.h   |  6 --
>  include/hw/i386/pc.h  |  6 --
>  include/hw/southbridge/piix.h | 20 
>  9 files changed, 48 insertions(+), 19 deletions(-)
>  delete mode 100644 include/hw/acpi/piix4.h
>  create mode 100644 include/hw/southbridge/piix.h
>
>
Reviewed-by: Aleksandar Markovic 



> diff --git a/MAINTAINERS b/MAINTAINERS
> index c9f625fc2e..556f58bd8c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1235,7 +1235,7 @@ F: hw/i2c/smbus_ich9.c
>  F: hw/acpi/piix4.c
>  F: hw/acpi/ich9.c
>  F: include/hw/acpi/ich9.h
> -F: include/hw/acpi/piix4.h
> +F: include/hw/southbridge/piix.h
>  F: hw/misc/sga.c
>  F: hw/isa/apm.c
>  F: include/hw/isa/apm.h
> @@ -1720,6 +1720,7 @@ M: Hervé Poussineau 
>  M: Philippe Mathieu-Daudé 
>  S: Maintained
>  F: hw/isa/piix4.c
> +F: include/hw/southbridge/piix.h
>
>  Firmware configuration (fw_cfg)
>  M: Philippe Mathieu-Daudé 
> diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
> index 1d29d438c7..27270621ab 100644
> --- a/hw/acpi/piix4.c
> +++ b/hw/acpi/piix4.c
> @@ -21,6 +21,7 @@
>
>  #include "qemu/osdep.h"
>  #include "hw/i386/pc.h"
> +#include "hw/southbridge/piix.h"
>  #include "hw/irq.h"
>  #include "hw/isa/apm.h"
>  #include "hw/i2c/pm_smbus.h"
> @@ -33,7 +34,6 @@
>  #include "qapi/error.h"
>  #include "qemu/range.h"
>  #include "exec/address-spaces.h"
> -#include "hw/acpi/piix4.h"
>  #include "hw/acpi/pcihp.h"
>  #include "hw/acpi/cpu_hotplug.h"
>  #include "hw/acpi/cpu.h"
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index 4e0f9f425a..aa6fe61191 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -34,7 +34,6 @@
>  #include "hw/acpi/acpi-defs.h"
>  #include "hw/acpi/acpi.h"
>  #include "hw/acpi/cpu.h"
> -#include "hw/acpi/piix4.h"
>  #include "hw/nvram/fw_cfg.h"
>  #include "hw/acpi/bios-linker-loader.h"
>  #include "hw/isa/isa.h"
> @@ -52,7 +51,7 @@
>  #include "sysemu/reset.h"
>
>  /* Supported chipsets: */
> -#include "hw/acpi/piix4.h"
> +#include "hw/southbridge/piix.h"
>  #include "hw/acpi/pcihp.h"
>  #include "hw/i386/ich9.h"
>  #include "hw/pci/pci_bus.h"
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 6824b72124..431965d921 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -29,6 +29,7 @@
>  #include "hw/loader.h"
>  #include "hw/i386/pc.h"
>  #include "hw/i386/apic.h"
> +#include "hw/southbridge/piix.h"
>  #include "hw/display/ramfb.h"
>  #include "hw/firmware/smbios.h"
>  #include "hw/pci/pci.h"
> diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
> index 0b0a0ecab1..9f554747af 100644
> --- a/hw/isa/piix4.c
> +++ b/hw/isa/piix4.c
> @@ -24,6 +24,7 @@
>   */
>
>  #include "qemu/osdep.h"
> +#include "qapi/error.h"
>  #include "hw/irq.h"
>  #include "hw/i386/pc.h"
>  #include "hw/pci/pci.h"
> @@ -31,6 +32,7 @@
>  #include "hw/sysbus.h"
>  #include "hw/dma/i8257.h"
>  #include "hw/timer/i8254.h"
> +#include "hw/timer/mc146818rtc.h"
>  #include "migration/vmstate.h"
>  #include "sysemu/reset.h"
>  #include "sysemu/runstate.h"
> @@ -42,6 +44,7 @@ typedef struct PIIX4State {
>  qemu_irq cpu_intr;
>  qemu_irq *isa;
>
> +RTCState rtc;
>  /* Reset Control Register */
>  MemoryRegion rcr_mem;
>  uint8_t rcr;
> @@ -144,6 +147,7 @@ static void piix4_realize(PCIDevice *pci_dev, Error
> **errp)
>  PIIX4State *s = DO_UPCAST(PIIX4State, dev, pci_dev);
>  ISABus *isa_bus;
>  qemu_irq *i8259_out_irq;
> +Error *err = NULL;
>
>  isa_bus = isa_bus_new(dev, pci_address_space(pci_dev),
>pci_address_space_io(pci_dev), errp);
> @@ -172,9 +176,26 @@ static void piix4_realize(PCIDevice *pci_dev, Error
> **errp)
>  /* DMA */
>  i8257_dma_init(isa_bus, 0);
>
> +/* RTC */
> +qdev_set_parent_bus(DEVICE(>rtc), BUS(isa_bus));
> +qdev_prop_set_int32(DEVICE(>rtc), "base_year", 2000);
> +object_property_set_bool(OBJECT(>rtc), true, "realized", );
> +if (err) {
> +error_propagate(errp, err);
> +return;
> +}
> +isa_init_irq(ISA_DEVICE(>rtc), >rtc.irq, RTC_ISA_IRQ);
> +
>  piix4_dev = pci_dev;
>  }
>
> +static void piix4_init(Object *obj)
> +{
> +PIIX4State *s = PIIX4_PCI_DEVICE(obj);
> +
> +object_initialize(>rtc, sizeof(s->rtc), TYPE_MC146818_RTC);
> +}
> +
>  static void 

Re: [Xen-devel] [PATCH 15/32] piix4: add a i8254 pit controller as specified in datasheet

[Aleksandar Markovic]

On Tuesday, October 15, 2019, Philippe Mathieu-Daudé 
wrote:

> From: Hervé Poussineau 
>
> Remove i8254 instanciated in malta board, to not have it twice.
>
> Acked-by: Michael S. Tsirkin 
> Acked-by: Paolo Bonzini 
> Signed-off-by: Hervé Poussineau 
> Message-Id: <20171216090228.28505-10-hpous...@reactos.org>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/isa/piix4.c   | 4 
>  hw/mips/mips_malta.c | 4 
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
>
Reviewed-by: Aleksandar Markovic 



> diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
> index 1bc91b590c..0b0a0ecab1 100644
> --- a/hw/isa/piix4.c
> +++ b/hw/isa/piix4.c
> @@ -30,6 +30,7 @@
>  #include "hw/isa/isa.h"
>  #include "hw/sysbus.h"
>  #include "hw/dma/i8257.h"
> +#include "hw/timer/i8254.h"
>  #include "migration/vmstate.h"
>  #include "sysemu/reset.h"
>  #include "sysemu/runstate.h"
> @@ -165,6 +166,9 @@ static void piix4_realize(PCIDevice *pci_dev, Error
> **errp)
>  /* initialize ISA irqs */
>  isa_bus_irqs(isa_bus, s->isa);
>
> +/* initialize pit */
> +i8254_pit_init(isa_bus, 0x40, 0, NULL);
> +
>  /* DMA */
>  i8257_dma_init(isa_bus, 0);
>
> diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
> index df247177ca..16d7a0e785 100644
> --- a/hw/mips/mips_malta.c
> +++ b/hw/mips/mips_malta.c
> @@ -45,7 +45,6 @@
>  #include "hw/loader.h"
>  #include "elf.h"
>  #include "hw/timer/mc146818rtc.h"
> -#include "hw/timer/i8254.h"
>  #include "exec/address-spaces.h"
>  #include "hw/sysbus.h" /* SysBusDevice */
>  #include "qemu/host-utils.h"
> @@ -99,8 +98,6 @@ typedef struct {
>  qemu_irq i8259[16];
>  } MaltaState;
>
> -static ISADevice *pit;
> -
>  static struct _loaderparams {
>  int ram_size, ram_low_size;
>  const char *kernel_filename;
> @@ -1428,7 +1425,6 @@ void mips_malta_init(MachineState *machine)
>  pci_create_simple(pci_bus, piix4_devfn + 2, "piix4-usb-uhci");
>  smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100,
>isa_get_irq(NULL, 9), NULL, 0, NULL);
> -pit = i8254_pit_init(isa_bus, 0x40, 0, NULL);
>  mc146818_rtc_init(isa_bus, 2000, NULL);
>
>  /* generate SPD EEPROM data */
> --
> 2.21.0
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 14/32] piix4: add a i8257 dma controller as specified in datasheet

[Aleksandar Markovic]

On Tuesday, October 15, 2019, Philippe Mathieu-Daudé 
wrote:

> From: Hervé Poussineau 
>
> Remove i8257 instanciated in malta board, to not have it twice.
>
> Acked-by: Michael S. Tsirkin 
> Acked-by: Paolo Bonzini 
> Signed-off-by: Hervé Poussineau 
> Message-Id: <20171216090228.28505-9-hpous...@reactos.org>
> [PMD: rebased]
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/isa/piix4.c   | 4 
>  hw/mips/mips_malta.c | 2 --
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> Reviewed-by: Aleksandar Markovic 




> diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
> index 8998b0ca47..1bc91b590c 100644
> --- a/hw/isa/piix4.c
> +++ b/hw/isa/piix4.c
> @@ -29,6 +29,7 @@
>  #include "hw/pci/pci.h"
>  #include "hw/isa/isa.h"
>  #include "hw/sysbus.h"
> +#include "hw/dma/i8257.h"
>  #include "migration/vmstate.h"
>  #include "sysemu/reset.h"
>  #include "sysemu/runstate.h"
> @@ -164,6 +165,9 @@ static void piix4_realize(PCIDevice *pci_dev, Error
> **errp)
>  /* initialize ISA irqs */
>  isa_bus_irqs(isa_bus, s->isa);
>
> +/* DMA */
> +i8257_dma_init(isa_bus, 0);
> +
>  piix4_dev = pci_dev;
>  }
>
> diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
> index e499b7a6bb..df247177ca 100644
> --- a/hw/mips/mips_malta.c
> +++ b/hw/mips/mips_malta.c
> @@ -28,7 +28,6 @@
>  #include "cpu.h"
>  #include "hw/i386/pc.h"
>  #include "hw/isa/superio.h"
> -#include "hw/dma/i8257.h"
>  #include "hw/char/serial.h"
>  #include "net/net.h"
>  #include "hw/boards.h"
> @@ -1430,7 +1429,6 @@ void mips_malta_init(MachineState *machine)
>  smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100,
>isa_get_irq(NULL, 9), NULL, 0, NULL);
>  pit = i8254_pit_init(isa_bus, 0x40, 0, NULL);
> -i8257_dma_init(isa_bus, 0);
>  mc146818_rtc_init(isa_bus, 2000, NULL);
>
>  /* generate SPD EEPROM data */
> --
> 2.21.0
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 01/32] hw/i386: Remove obsolete LoadStateHandler::load_state_old handlers

[Aleksandar Markovic]

On Tuesday, October 15, 2019, Philippe Mathieu-Daudé 
wrote:

> These devices implemented their load_state_old() handler 10 years
> ago, previous to QEMU v0.12.
> Since commit cc425b5ddf removed the pc-0.10 and pc-0.11 machines,
> we can drop this code.
>
> Note: the mips_r4k machine started to use the i8254 device just
> after QEMU v0.5.0, but the MIPS machine types are not versioned,
> so there is no migration compatibility issue removing this handler.
>
> Suggested-by: Peter Maydell 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/acpi/piix4.c | 40 -
>  hw/intc/apic_common.c   | 49 -
>  hw/pci-host/piix.c  | 25 -
>  hw/timer/i8254_common.c | 40 -
>  4 files changed, 154 deletions(-)
>
>
Reviewed-by: Aleksandar Markovic 



> diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
> index 5742c3df87..1d29d438c7 100644
> --- a/hw/acpi/piix4.c
> +++ b/hw/acpi/piix4.c
> @@ -42,7 +42,6 @@
>  #include "hw/acpi/memory_hotplug.h"
>  #include "hw/acpi/acpi_dev_interface.h"
>  #include "hw/xen/xen.h"
> -#include "migration/qemu-file-types.h"
>  #include "migration/vmstate.h"
>  #include "hw/core/cpu.h"
>  #include "trace.h"
> @@ -205,43 +204,6 @@ static const VMStateDescription vmstate_pci_status = {
>  }
>  };
>
> -static int acpi_load_old(QEMUFile *f, void *opaque, int version_id)
> -{
> -PIIX4PMState *s = opaque;
> -int ret, i;
> -uint16_t temp;
> -
> -ret = pci_device_load(PCI_DEVICE(s), f);
> -if (ret < 0) {
> -return ret;
> -}
> -qemu_get_be16s(f, >ar.pm1.evt.sts);
> -qemu_get_be16s(f, >ar.pm1.evt.en);
> -qemu_get_be16s(f, >ar.pm1.cnt.cnt);
> -
> -ret = vmstate_load_state(f, _apm, >apm, 1);
> -if (ret) {
> -return ret;
> -}
> -
> -timer_get(f, s->ar.tmr.timer);
> -qemu_get_sbe64s(f, >ar.tmr.overflow_time);
> -
> -qemu_get_be16s(f, (uint16_t *)s->ar.gpe.sts);
> -for (i = 0; i < 3; i++) {
> -qemu_get_be16s(f, );
> -}
> -
> -qemu_get_be16s(f, (uint16_t *)s->ar.gpe.en);
> -for (i = 0; i < 3; i++) {
> -qemu_get_be16s(f, );
> -}
> -
> -ret = vmstate_load_state(f, _pci_status,
> ->acpi_pci_hotplug.acpi_pcihp_pci_status[ACPI_PCIHP_BSEL_DEFAULT],
> 1);
> -return ret;
> -}
> -
>  static bool vmstate_test_use_acpi_pci_hotplug(void *opaque, int
> version_id)
>  {
>  PIIX4PMState *s = opaque;
> @@ -313,8 +275,6 @@ static const VMStateDescription vmstate_acpi = {
>  .name = "piix4_pm",
>  .version_id = 3,
>  .minimum_version_id = 3,
> -.minimum_version_id_old = 1,
> -.load_state_old = acpi_load_old,
>  .post_load = vmstate_acpi_post_load,
>  .fields = (VMStateField[]) {
>  VMSTATE_PCI_DEVICE(parent_obj, PIIX4PMState),
> diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c
> index aafd8e0e33..375cb6abe9 100644
> --- a/hw/intc/apic_common.c
> +++ b/hw/intc/apic_common.c
> @@ -31,7 +31,6 @@
>  #include "sysemu/kvm.h"
>  #include "hw/qdev-properties.h"
>  #include "hw/sysbus.h"
> -#include "migration/qemu-file-types.h"
>  #include "migration/vmstate.h"
>
>  static int apic_irq_delivered;
> @@ -262,52 +261,6 @@ static void apic_reset_common(DeviceState *dev)
>  apic_init_reset(dev);
>  }
>
> -/* This function is only used for old state version 1 and 2 */
> -static int apic_load_old(QEMUFile *f, void *opaque, int version_id)
> -{
> -APICCommonState *s = opaque;
> -APICCommonClass *info = APIC_COMMON_GET_CLASS(s);
> -int i;
> -
> -if (version_id > 2) {
> -return -EINVAL;
> -}
> -
> -/* XXX: what if the base changes? (registered memory regions) */
> -qemu_get_be32s(f, >apicbase);
> -qemu_get_8s(f, >id);
> -qemu_get_8s(f, >arb_id);
> -qemu_get_8s(f, >tpr);
> -qemu_get_be32s(f, >spurious_vec);
> -qemu_get_8s(f, >log_dest);
> -qemu_get_8s(f, >dest_mode);
> -for (i = 0; i < 8; i++) {
> -qemu_get_be32s(f, >isr[i]);
> -qemu_get_be32s(f, >tmr[i]);
> -qemu_get_be32s(f, >irr[i]);
> -}
> -for (i = 0; i < APIC_LVT_NB; i++) {
> -qemu_get_be32s(f, >lvt[i]);
> -}
> -qemu_get_be32s(f, >esr);
> -qemu_get_be32s(f, >icr[0]);
> -qemu_get_be32s(f, >icr[1]);
> -qemu_get_be32s(f, >divide_conf);
> -s->count_shift = qemu_get_be32(f);
> -qemu_get_be32s(f, >initial_count);
> -s->initial_count_load_time = qemu_get_be64(f);
> -s->next_time = qemu_get_be64(f);
> -
> -if (version_id >= 2) {
> -s->timer_expiry = qemu_get_be64(f);
> -}
> -
> -if (info->post_load) {
> -info->post_load(s);
> -}
> -return 0;
> -}
> -
>  static const VMStateDescription vmstate_apic_common;
>
>  static void apic_common_realize(DeviceState *dev, Error **errp)
> @@ -408,8 +361,6 @@ static const VMStateDescription vmstate_apic_common = {
>  .name = "apic",
>  .version_id = 3,
>  

Re: [Xen-devel] [PATCH 10/32] piix4: add a i8259 interrupt controller as specified in datasheet

[Aleksandar Markovic]

On Tuesday, October 15, 2019, Philippe Mathieu-Daudé 
wrote:

> From: Hervé Poussineau 
>
> Add ISA irqs as piix4 gpio in, and CPU interrupt request as piix4 gpio out.
> Remove i8259 instanciated in malta board, to not have it twice.
>
> We can also remove the now unused piix4_init() function.
>
> Acked-by: Michael S. Tsirkin 
> Acked-by: Paolo Bonzini 
> Signed-off-by: Hervé Poussineau 
> Message-Id: <20171216090228.28505-8-hpous...@reactos.org>
> [PMD: rebased, updated includes, use ISA_NUM_IRQS in for loop]
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/isa/piix4.c   | 41 ++---
>  hw/mips/mips_malta.c | 32 +---
>  include/hw/i386/pc.h |  1 -
>  3 files changed, 43 insertions(+), 31 deletions(-)
>
>
Reviewed-by: Aleksandar Markovic 



> diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
> index 6e2d9b9774..1cfc51335a 100644
> --- a/hw/isa/piix4.c
> +++ b/hw/isa/piix4.c
> @@ -24,6 +24,7 @@
>   */
>
>  #include "qemu/osdep.h"
> +#include "hw/irq.h"
>  #include "hw/i386/pc.h"
>  #include "hw/pci/pci.h"
>  #include "hw/isa/isa.h"
> @@ -36,6 +37,8 @@ PCIDevice *piix4_dev;
>
>  typedef struct PIIX4State {
>  PCIDevice dev;
> +qemu_irq cpu_intr;
> +qemu_irq *isa;
>
>  /* Reset Control Register */
>  MemoryRegion rcr_mem;
> @@ -94,6 +97,18 @@ static const VMStateDescription vmstate_piix4 = {
>  }
>  };
>
> +static void piix4_request_i8259_irq(void *opaque, int irq, int level)
> +{
> +PIIX4State *s = opaque;
> +qemu_set_irq(s->cpu_intr, level);
> +}
> +
> +static void piix4_set_i8259_irq(void *opaque, int irq, int level)
> +{
> +PIIX4State *s = opaque;
> +qemu_set_irq(s->isa[irq], level);
> +}
> +
>  static void piix4_rcr_write(void *opaque, hwaddr addr, uint64_t val,
>  unsigned int len)
>  {
> @@ -126,30 +141,34 @@ static void piix4_realize(PCIDevice *pci_dev, Error
> **errp)
>  {
>  DeviceState *dev = DEVICE(pci_dev);
>  PIIX4State *s = DO_UPCAST(PIIX4State, dev, pci_dev);
> +ISABus *isa_bus;
> +qemu_irq *i8259_out_irq;
>
> -if (!isa_bus_new(dev, pci_address_space(pci_dev),
> - pci_address_space_io(pci_dev), errp)) {
> +isa_bus = isa_bus_new(dev, pci_address_space(pci_dev),
> +  pci_address_space_io(pci_dev), errp);
> +if (!isa_bus) {
>  return;
>  }
>
> +qdev_init_gpio_in_named(dev, piix4_set_i8259_irq, "isa",
> ISA_NUM_IRQS);
> +qdev_init_gpio_out_named(dev, >cpu_intr, "intr", 1);
> +
>  memory_region_init_io(>rcr_mem, OBJECT(dev), _rcr_ops, s,
>"reset-control", 1);
>  memory_region_add_subregion_overlap(pci_address_space_io(pci_dev),
> 0xcf9,
>  >rcr_mem, 1);
>
> +/* initialize i8259 pic */
> +i8259_out_irq = qemu_allocate_irqs(piix4_request_i8259_irq, s, 1);
> +s->isa = i8259_init(isa_bus, *i8259_out_irq);
> +
> +/* initialize ISA irqs */
> +isa_bus_irqs(isa_bus, s->isa);
> +
>  piix4_dev = pci_dev;
>  qemu_register_reset(piix4_reset, s);
>  }
>
> -int piix4_init(PCIBus *bus, ISABus **isa_bus, int devfn)
> -{
> -PCIDevice *d;
> -
> -d = pci_create_simple_multifunction(bus, devfn, true, "PIIX4");
> -*isa_bus = ISA_BUS(qdev_get_child_bus(DEVICE(d), "isa.0"));
> -return d->devfn;
> -}
> -
>  static void piix4_class_init(ObjectClass *klass, void *data)
>  {
>  DeviceClass *dc = DEVICE_CLASS(klass);
> diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
> index 4d9c64b36a..7d25ab6c23 100644
> --- a/hw/mips/mips_malta.c
> +++ b/hw/mips/mips_malta.c
> @@ -97,7 +97,7 @@ typedef struct {
>  SysBusDevice parent_obj;
>
>  MIPSCPSState cps;
> -qemu_irq *i8259;
> +qemu_irq i8259[16];
>  } MaltaState;
>
>  static ISADevice *pit;
> @@ -1235,8 +1235,8 @@ void mips_malta_init(MachineState *machine)
>  int64_t kernel_entry, bootloader_run_addr;
>  PCIBus *pci_bus;
>  ISABus *isa_bus;
> -qemu_irq *isa_irq;
>  qemu_irq cbus_irq, i8259_irq;
> +PCIDevice *pci;
>  int piix4_devfn;
>  I2CBus *smbus;
>  DriveInfo *dinfo;
> @@ -1407,30 +1407,24 @@ void mips_malta_init(MachineState *machine)
>  /* Board ID = 0x420 (Malta Board with CoreLV) */
>  stl_p(memory_region_get_ram_ptr(bios_copy) + 0x10, 0x0420);
>
> -/*
> - * We have a circular dependency problem: pci_bus depends on isa_irq,
> - * isa_irq is provided by i8259, i8259 depends on ISA, ISA depends
> - * on piix4, and piix4 depends on pci_bus.  To stop the cycle we have
> - * qemu_irq_proxy() adds an extra bit of indirection, allowing us
> - * to resolve the isa_irq -> i8259 dependency after i8259 is
> initialized.
> - */
> -isa_irq = qemu_irq_proxy(>i8259, 16);
> -
>  /* Northbridge */
> -pci_bus = gt64120_register(isa_irq);
> +pci_bus = gt64120_register(s->i8259);
>
>  /* Southbridge */
>  ide_drive_get(hd, 

Re: [Xen-devel] [PATCH 07/32] MAINTAINERS: Keep PIIX4 South Bridge separate from PC Chipsets

[Aleksandar Markovic]

On Tuesday, October 15, 2019, Philippe Mathieu-Daudé 
wrote:

> From: Philippe Mathieu-Daudé 
>
> The PIIX4 Southbridge is not used by the PC machine,
> but by the Malta board (MIPS). Add a new section to
> keep it covered.
>
> Suggested-by: Michael S. Tsirkin 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  MAINTAINERS | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)


Reviewed-by: Aleksandar Markovic 


>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fe4dc51b08..c9f625fc2e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1230,7 +1230,6 @@ F: hw/pci-host/q35.c
>  F: hw/pci-host/pam.c
>  F: include/hw/pci-host/q35.h
>  F: include/hw/pci-host/pam.h
> -F: hw/isa/piix4.c
>  F: hw/isa/lpc_ich9.c
>  F: hw/i2c/smbus_ich9.c
>  F: hw/acpi/piix4.c
> @@ -1716,6 +1715,12 @@ F: hw/display/edid*
>  F: include/hw/display/edid.h
>  F: qemu-edid.c
>
> +PIIX4 South Bridge (i82371AB)
> +M: Hervé Poussineau 
> +M: Philippe Mathieu-Daudé 
> +S: Maintained
> +F: hw/isa/piix4.c
> +
>  Firmware configuration (fw_cfg)
>  M: Philippe Mathieu-Daudé 
>  R: Laszlo Ersek 
> --
> 2.21.0
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure

[Lars Kurth]

On 16/10/2019, 17:35, "Rich Persaud"  wrote:

> On Oct 15, 2019, at 08:27, Lars Kurth  wrote:
...
> 
> My point really was is that due to storing the files in git, we 
essentially do NOT today do this.
> So we would need to take extra action: e.g. manually or through tooling
> 
>>>   4.2: We could require individual authors to be credited: in that
>>>   case we probably ought to lead by example and list the authors
>>>   in a credit/license section and extract the information from
>>>   git logs when we generate it (at some point in the future)
>>> 5: You give an indication whether you made changes ... in practice
>>> this means you have to state significant changes made to the works
>> 
>> This is also helpful for provenance of changes, which is relevant in 
safety-oriented documentation.  It can be used to clearly delineate CC-licensed 
content (which may be reused by many companies) from "All Rights Reserved" 
commercial content that may be added for a specific commercial audience or 
purpose.
> 
> I agree
> 
> I think the outcome of this analysis is really that the only significant 
difference between BSD and CC-BY in this context is the  "All Rights Reserved" 
portion

Also - BSD is a "software" license while CC-BY is a "content" license, so 
they are not strictly comparable, even if they use similar terminology.

True, but as we have noticed the boundary between content and in-code docs 
content is fuzzy.

>> There is a difference between "software" which "runs on machines" and 
"documentation" which "runs on humans".  Combined software (e.g. BSD code from 
two origins) is executed identically, despite origin.  Humans make value 
judgements based on the author/origin of content, hence the focus on 
attribution.  Yes, there is a provenance graph in git (software/data), but 
that's not typically visible to human readers, except as a generated report, 
i.e. documentation.
> 
> Yes true. But also true for CC-BY-4 sources stored in git unless extra 
action is taken 
> 
> But my point is: 
> * If we take extra action as e.g. proposed in 4.2 we can apply this 
uniformly to BSD as well as CC-BY pages
> * We can add a section on re-use as proposed in 4.2 which recommends best 
practices around 5.  
> * We can highlight sections that are BSD vs CC-BY in such a section, such 
that someone who has issue can remove these easily
> 
> In addition to these points: maybe it is too impractical to create ABI 
documentation based on CC-BY-4 (given that a lot of what we need is already in 
BSD sources). 
> We could just copy some of the content in the BSD sources to new CC-BY-4 
sources, but in practice it would just be hiding the potential legal issues 
behind it. 
> Someone could contest the creation and argue that portions of the now 
CC-BY-4 sources are in fact BSD: in practice this is extremely unlikely, but it 
is possible.
> 
>>> As such, BSD-2/3-Clause in our context works similarly to CC-BY-4
>>> from a downstream's perspective. In fact CC-BY-4 is somewhat stricter
>> 
>> If we don't want the incentives and provenance properties of CC-BY, 
there is the option of CC0, which is the equivalent of public domain.  This 
would delegate the task of separating commercial vs CC content to each reader, 
without any license-required attribution or separation.
>> 
>> Some background on licenses designed for documentation, which has 
different legal requirements than software:
>> 
>> https://www.dreamsongs.com/IHE/IHE-50.html
>> https://creativecommons.org/faq/#what-are-creative-commons-licenses (not 
for s/w)
> 
> I will have a look. But the core issue - which is why I have proposed 
what I have - is the question on how practically ABI documentation published 
under CC-BY-4, when much of this information has already been published in the 
past as code under BSD.

Is there a reference sample of:

- previously published, BSD-licensed, ABI specification-as-source-code

All of http://xenbits.xen.org/docs/unstable/hypercall
And some can be content rich as seen in 
http://xenbits.xen.org/docs/unstable/hypercall/arm/include,public,xen.h.html#Func_HYPERVISOR_mmu_update
 
- the corresponding FuSA ABI documentation for that source file

We do NOT have ANY FuSA documentation at this stage. And there are NO examples 
of such docs in the public domain
I am waiting for a sanitised smallish system software example to be made 
available, which should help us identify the practical implications 
However, ABI documentation would be part of it

If there is almost a 1:1 correspondence between ABI "docs" and "code", 
could the necessary FuSA annotations become part of the source code file, e.g. 
comments or tags?  Or is there a requirement for the ABI documentation to have 
a specific layout in a printable report?
   

Re: [Xen-devel] [PATCH] xen/arm: add warning if memory modules overlap

[Julien Grall]

Hi,

Sorry for the late answer.

On 11/10/2019 20:07, Brian Woods wrote:

On Fri, Oct 11, 2019 at 07:17:29PM +0100, Julien Grall wrote:

This code is also only called at boot where there are bigger time consuming
part (such as domheap initialization). So I would be surprised if you see
any improvement (other than a couple of cycles) in boot time here.

Therefore, I would favor a readable solution over a micro-optimized solution
here.


Which is why I wanted to put it where it was in the patch.  Where the
user would see the warning after the information about the memory
modules were printed (and fair early).


I had a think about it, dumping the modules informations before is useful if you 
know that you have one module max per kind. So you avoid to print the modules 
address/size in the warning.


However, it is possible to have multiple kernel module (as long as they don't 
have the same start address), you could end up with the following message:


"WARNING: modules Kernel and Kernel overlap"

To make the message more meaningful, we would need to print the modules 
address/size. Therefore, I don't view that it is important to check overlapping 
in early_print_info(). In this case I would favor any code that don't add a 
double for loop.


While thinking about this case, it made me realize that we only check the start 
address to consider a match. This means if the size is different, then it will 
be ignored. I think we ought to throw at least warning for this case as well.


Would you mind to have a look?



Either way, take your pick of location and if it's only debug or not and
I can write it up and test it.


I would still prefer in add_boot_module(). See why above.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 2/4] x2APIC: simplify resume

[Marek Marczykowski-Górecki]

On Tue, Oct 15, 2019 at 05:47:34PM +0200, Roger Pau Monne wrote:
> There's no need to save and restore the IO-APIC entries, the entries
> prior to suspension have already been saved by ioapic_suspend, and
> will be restored by ioapic_resume. Note that at the point where
> resume_x2apic gets called the IO-APIC has not yet resumed, and hence
> all entries should be masked.
> 
> Note this shouldn't introduce any functional change.
> 
> Suggested-by: Jan Beulich 
> Signed-off-by: Roger Pau Monné 

I've tried host suspend without any domU running and it works. I've tested
just this patch without others in the series, does it matter?

Tested-by: Marek Marczykowski-Górecki 

> ---
> I'm Ccing Marek since I think he usually tests suspend/resume. Could
> you give this patch a try?
> ---
> Cc: Marek Marczykowski-Górecki 
> Cc: Juergen Gross 
> ---
> Changes since v2:
>  - New in this version.
> ---
>  xen/arch/x86/apic.c | 27 ---
>  1 file changed, 27 deletions(-)
> 
> diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
> index 6cdb50cf41..0607eb92a8 100644
> --- a/xen/arch/x86/apic.c
> +++ b/xen/arch/x86/apic.c
> @@ -492,35 +492,8 @@ static void __enable_x2apic(void)
>  
>  static void resume_x2apic(void)
>  {
> -struct IO_APIC_route_entry **ioapic_entries = NULL;
> -
> -ASSERT(x2apic_enabled);
> -
> -ioapic_entries = alloc_ioapic_entries();
> -if ( !ioapic_entries )
> -{
> -printk("Allocate ioapic_entries failed\n");
> -goto out;
> -}
> -
> -if ( save_IO_APIC_setup(ioapic_entries) )
> -{
> -printk("Saving IO-APIC state failed\n");
> -goto out;
> -}
> -
> -mask_8259A();
> -mask_IO_APIC_setup(ioapic_entries);
> -
>  iommu_enable_x2apic();
>  __enable_x2apic();
> -
> -restore_IO_APIC_setup(ioapic_entries);
> -unmask_8259A();
> -
> -out:
> -if ( ioapic_entries )
> -free_ioapic_entries(ioapic_entries);
>  }
>  
>  void setup_local_APIC(void)

-- 
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
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH -tip v4 0/4] x86: kprobes: Prohibit kprobes on Xen/KVM emulate prefixes

[Peter Zijlstra]

On Thu, Oct 17, 2019 at 12:26:55PM +0900, Masami Hiramatsu wrote:
> Hi Peter,
> 
> On Wed, 9 Oct 2019 14:31:06 +0200
> Peter Zijlstra  wrote:
> 
> > On Tue, Sep 17, 2019 at 03:14:03PM +0900, Masami Hiramatsu wrote:
> > > Hi Peter,
> > > 
> > > Could you review this version?
> > 
> > These look good to me; shall I merge them or what was the plan?
> 
> Thanks for the review, yes, could you merge this series to support emulated 
> prefixes correctly?

OK, I'll get them merged.

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

[Xen-devel] [PATCH] MAINTAINERS: drop Tim Deegan from 'The Rest'

[Tim Deegan]

I have not been active in this role for a while now.

Signed-off-by: Tim Deegan 
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 533cfdc08f..f60d765baf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -537,7 +537,6 @@ M:  Jan Beulich 
 M: Julien Grall 
 M: Konrad Rzeszutek Wilk 
 M: Stefano Stabellini 
-M: Tim Deegan 
 M: Wei Liu 
 L: xen-devel@lists.xenproject.org
 S: Supported
-- 
2.20.1

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