Re: [Xen-devel] [PATCH v6 02/10] xen/arm: optee: add OP-TEE header files

[Lars Kurth]

On 17/06/2019, 18:28, "Stefano Stabellini"  wrote:

On Mon, 17 Jun 2019, Julien Grall wrote:
> On 17/06/2019 17:28, Stefano Stabellini wrote:
> > Looking at https://www.gnu.org/licenses/license-list.en.html and also
> > looking at the usage in the Linux kernel, I am pretty sure it is
> > compatible. However, given that the Xen hypervisor as a whole is GPLv2,
> > I think it would be more precise to say:
> > 
> > SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> 
> Well, this is imported from OP-TEE. So I don't think we have the freedom 
to
> change this copyright header here...

Interesting point: I would have thought that given that this is a GPLv2
project, if we went with SPDX, all files would need to have a
GPL-2.0-only tag on them, plus, optionally, an OR XXX clause.

Something for Lars to investigate.

That is not really how this works. The resulting Xen binary would be GPL 2.0, 
while individual parts of the source tree can be of different licenses.   

> What I was asking is whether this is OK to import BSD-2-Clause code in 
Xen.
> You seem to agree that it should be possible.

Yep. The problematic BSD license is the BSD-4-Clause.

It is definitely OK: see 
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=CONTRIBUTING

Lars 

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

Re: [Xen-devel] Xen Project Community Call June 6th: @15:00 UTC Call for agenda items

[Lars Kurth]

Hi all,
a quick reminder that the call will be today
Regards
Lars

On 30/05/2019, 18:35, "Lars Kurth"  wrote:

Hi all,

Please propose topics by either editing the running agenda document at 
https://cryptpad.fr/pad/#/2/pad/edit/WZr2VTdfmaPdvIxjXp+cgSF- or by replying to 
the mail.
Ideally by Tuesday!
Note that I am using another sharing mechanism as per request. Let me know 
if you have difficulties

Best Regards
Lars

== Dial-in Information ==

 ## Meeting time
 15:00 - 16:00 UTC
 Further International meeting times: 
 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019=6=6=15=0=0=225=224=24=179=136=37=33


 ## Dial in details
 Web: https://www.gotomeet.me/larskurth

 You can also dial in using your phone.
 Access Code: 906-886-965

 China (Toll Free): 4008 811084
 Germany: +49 692 5736 7317
 Poland (Toll Free): 00 800 1124759
 United Kingdom: +44 330 221 0088
 United States: +1 (571) 317-3129

 More phone numbers
 Australia: +61 2 9087 3604
 Austria: +43 7 2081 5427
 Argentina (Toll Free): 0 800 444 3375
 Bahrain (Toll Free): 800 81 111
 Belarus (Toll Free): 8 820 0011 0400
 Belgium: +32 28 93 7018
 Brazil (Toll Free): 0 800 047 4906
 Bulgaria (Toll Free): 00800 120 4417
 Canada: +1 (647) 497-9391
 Chile (Toll Free): 800 395 150
 Colombia (Toll Free): 01 800 518 4483
  Czech Republic (Toll Free): 800 500448
 Denmark: +45 32 72 03 82
 Finland: +358 923 17 0568
 France: +33 170 950 594
 Greece (Toll Free): 00 800 4414 3838
 Hong Kong (Toll Free): 30713169
 Hungary (Toll Free): (06) 80 986 255
 Iceland (Toll Free): 800 7204
 India (Toll Free): 18002669272
 Indonesia (Toll Free): 007 803 020 5375
 Ireland: +353 15 360 728
 Israel (Toll Free): 1 809 454 830
 Italy: +39 0 247 92 13 01
 Japan (Toll Free): 0 120 663 800
 Korea, Republic of (Toll Free): 00798 14 207 4914
 Luxembourg (Toll Free): 800 85158
 Malaysia (Toll Free): 1 800 81 6854
 Mexico (Toll Free): 01 800 522 1133
 Netherlands: +31 207 941 377
 New Zealand: +64 9 280 6302
 Norway: +47 21 93 37 51
 Panama (Toll Free): 00 800 226 7928
 Peru (Toll Free): 0 800 77023
 Philippines (Toll Free): 1 800 1110 1661
 Portugal (Toll Free): 800 819 575
 Romania (Toll Free): 0 800 410 029
 Russian Federation (Toll Free): 8 800 100 6203
 Saudi Arabia (Toll Free): 800 844 3633
 Singapore (Toll Free): 18007231323
 South Africa (Toll Free): 0 800 555 447
 Spain: +34 932 75 2004
 Sweden: +46 853 527 827
 Switzerland: +41 225 4599 78
 Taiwan (Toll Free): 0 800 666 854
 Thailand (Toll Free): 001 800 011 023
 Turkey (Toll Free): 00 800 4488 23683
 Ukraine (Toll Free): 0 800 50 1733
 United Arab Emirates (Toll Free): 800 044 40439
 Uruguay (Toll Free): 0004 019 1018
 Viet Nam (Toll Free): 122 80 481

 First GoToMeeting? Let's do a quick system check:
 https://link.gotomeeting.com/system-check




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

[Xen-devel] Xen Project Community Call June 6th: @15:00 UTC Call for agenda items

[Lars Kurth]

Hi all,

Please propose topics by either editing the running agenda document at 
https://cryptpad.fr/pad/#/2/pad/edit/WZr2VTdfmaPdvIxjXp+cgSF- or by replying to 
the mail.
Ideally by Tuesday!
Note that I am using another sharing mechanism as per request. Let me know if 
you have difficulties

Best Regards
Lars

== Dial-in Information ==

 ## Meeting time
 15:00 - 16:00 UTC
 Further International meeting times: 
 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019=6=6=15=0=0=225=224=24=179=136=37=33


 ## Dial in details
 Web: https://www.gotomeet.me/larskurth

 You can also dial in using your phone.
 Access Code: 906-886-965

 China (Toll Free): 4008 811084
 Germany: +49 692 5736 7317
 Poland (Toll Free): 00 800 1124759
 United Kingdom: +44 330 221 0088
 United States: +1 (571) 317-3129

 More phone numbers
 Australia: +61 2 9087 3604
 Austria: +43 7 2081 5427
 Argentina (Toll Free): 0 800 444 3375
 Bahrain (Toll Free): 800 81 111
 Belarus (Toll Free): 8 820 0011 0400
 Belgium: +32 28 93 7018
 Brazil (Toll Free): 0 800 047 4906
 Bulgaria (Toll Free): 00800 120 4417
 Canada: +1 (647) 497-9391
 Chile (Toll Free): 800 395 150
 Colombia (Toll Free): 01 800 518 4483
  Czech Republic (Toll Free): 800 500448
 Denmark: +45 32 72 03 82
 Finland: +358 923 17 0568
 France: +33 170 950 594
 Greece (Toll Free): 00 800 4414 3838
 Hong Kong (Toll Free): 30713169
 Hungary (Toll Free): (06) 80 986 255
 Iceland (Toll Free): 800 7204
 India (Toll Free): 18002669272
 Indonesia (Toll Free): 007 803 020 5375
 Ireland: +353 15 360 728
 Israel (Toll Free): 1 809 454 830
 Italy: +39 0 247 92 13 01
 Japan (Toll Free): 0 120 663 800
 Korea, Republic of (Toll Free): 00798 14 207 4914
 Luxembourg (Toll Free): 800 85158
 Malaysia (Toll Free): 1 800 81 6854
 Mexico (Toll Free): 01 800 522 1133
 Netherlands: +31 207 941 377
 New Zealand: +64 9 280 6302
 Norway: +47 21 93 37 51
 Panama (Toll Free): 00 800 226 7928
 Peru (Toll Free): 0 800 77023
 Philippines (Toll Free): 1 800 1110 1661
 Portugal (Toll Free): 800 819 575
 Romania (Toll Free): 0 800 410 029
 Russian Federation (Toll Free): 8 800 100 6203
 Saudi Arabia (Toll Free): 800 844 3633
 Singapore (Toll Free): 18007231323
 South Africa (Toll Free): 0 800 555 447
 Spain: +34 932 75 2004
 Sweden: +46 853 527 827
 Switzerland: +41 225 4599 78
 Taiwan (Toll Free): 0 800 666 854
 Thailand (Toll Free): 001 800 011 023
 Turkey (Toll Free): 00 800 4488 23683
 Ukraine (Toll Free): 0 800 50 1733
 United Arab Emirates (Toll Free): 800 044 40439
 Uruguay (Toll Free): 0004 019 1018
 Viet Nam (Toll Free): 122 80 481

 First GoToMeeting? Let's do a quick system check:
 https://link.gotomeeting.com/system-check


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

Re: [Xen-devel] Guest Testing in OSSTEST - What distros and versions should we test against

[Lars Kurth]

I was hoping we'd get a list of distros + versions together, but have not had 
any input on specific distros

To make this easier, I created 
https://cryptpad.fr/pad/#/2/pad/edit/9MppkbU36LDcWT12uC6Xk3SQ/ 
Trying something else, as some people have trouble with google docs

Regards
Lars

> On 9 May 2019, at 19:28, Lars Kurth  wrote:
> 
> Hi all,
> 
> following a discussion with committers about Guest testing in OSSTEST, it 
> surfaced that we have not updated what distros we test in OSSTEST for a very 
> long time. All agreed that we should regularly review what we test against: 
> maybe at the beginning of a release cycle
> 
> In any case, currently we test against
> 
> x86 HVM guests:
>  debian-9.4.0-{i386,amd64}-CD-1.iso
>  rhel-server-6.1-i386-dvd.iso
>  win10v1703-x86.iso
>  win7-x64.iso
>  ws16-x64.iso
>  FreeBSD-10.1-CUSTOM-{i386,amd64}-20150525.raw.xz
>  Debian HVM {i386,amd64} via debian-installer netinst [1]
> 
> x86 PV guests:
>  Debian PV {i386,amd64} via debian-installer netinst [1]
> 
> ARM guests:
>  Debian PV via debian-installer netinst [1]
> 
> [1] whatever Debian release osstest itself mostly runs
> 
> So I am opening the floor to suggestions.
> 
> With regards to Windows testing we have some restrictions. We have tried 
> several times to buy additional test licenses, but this never went anywhere 
> (some of the VM licenses are not available for our environment, unless you 
> bulk buy, which is very expensive). The only approach that would allow us to 
> test against different windows versions would be to require everyone who may 
> touch OSSTEST which is not doable.
> 
> I can bring this up with the MS open source office, if there are strong 
> feelings about this and try again
> 
> Lars
> 


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

Re: [Xen-devel] Guest Testing in OSSTEST - What distros and versions should we test against

[Lars Kurth]

> On 9 May 2019, at 19:43, Rich Persaud  wrote:
> 
> On May 9, 2019, at 21:28, Lars Kurth  <mailto:lars.kurth@gmail.com>> wrote:
> 
>> With regards to Windows testing we have some restrictions. We have tried 
>> several times to buy additional test licenses, but this never went anywhere 
>> (some of the VM licenses are not available for our environment, unless you 
>> bulk buy, which is very expensive). The only approach that would allow us to 
>> test against different windows versions would be to require everyone who may 
>> touch OSSTEST which is not doable.
> 
> Are the 90-day test/eval versions of Windows incompatible with OSSTEST?
> 
>   https://www.microsoft.com/en-us/evalcenter/evaluate-windows-10-enterprise 
> <https://www.microsoft.com/en-us/evalcenter/evaluate-windows-10-enterprise>
>   https://www.microsoft.com/en-us/evalcenter/ 
> <https://www.microsoft.com/en-us/evalcenter/>
> 

Actually, that's a possibility. Our use may not be compatible with the T's of 
the eval license though. It wasn't when we checked last time. But that can be 
checked.
Lars

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

[Xen-devel] [PATCH v3] Add TRACKING.IMPORTS to xen.git to more easily manage imported files that need to be kept in sync with an upstream

[Lars Kurth]

Following the recent discussion, we had on IRC and the action I had in 
the March community call, this file provides a file format that 
enables writing an automated test to check whether files are out of sync. 

An example, what file content may look like is embedded below
repo: linux-torvalds git 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
file: xen/drivers/passthrough/arm/smmu.c linux-torvalds 
linux/drivers/iommu/arm-smmu.c b77cf11f094136

Once the file format is agree, I will write a test or script.

I also need some more correct test data, aka entries in the file from
committers looking after the following files
[Jan]
xen/arch/x86/cpu/mwait-idle.c 
[Stefano, Julien - this has to be finalized]
xen/drivers/passthrough/arm/smmu.c
xen/arch/arm/vgic/*
xen/include/asm-arm/div64.h
xen/drivers/char/meson-uart.c
xen/arch/arm/arm32/lib/*
xen/arch/arm/arm64/lib/*
xen/arch/arm/arm64/cache.S
xen/arch/arm/arm64/bpi.S
xen/include/asm-arm/system.h
xen/arch/arm/arm64/insn.c
[Others?]
xen/common/rbtree.c

Note that in some cases Linux has diverged and some Linux files have 
disappeared. 
Julien also raised the point, that in some cases only a subset of code from 
Linux Xen files was applied or that only some functions get moved across to Xen.

I believe that is entirely OK. The workflow would be in most cases that:
- We use a Linux (source) commit as a benchmark and record the commit ID
- If there is a change in Linux the test will fail
- The committer looks at the diff and either
  - Decides to ignore it and bumps the commit ID in this file
  - Decides the change is needed, integrates it into Xen and then 
bumps the commit ID in this file

Changes since v1
* Require a colon after repo:, file:, ... keywords
* Replace manual:|auto: with file: as there auto: use-case was invalid
* Added more verbose description of format

Changes since v2
* Changed some formatting
* Removed examples
* Removed references to https

Signed-off-by: Lars Kurth 
CC: committ...@xenproject.org
---
 TRACKING.FILES | 44 
 1 file changed, 44 insertions(+)
 create mode 100644 TRACKING.FILES

diff --git a/TRACKING.FILES b/TRACKING.FILES
new file mode 100644
index 00..60c47bdefb
--- /dev/null
+++ b/TRACKING.FILES
@@ -0,0 +1,44 @@
+# This file contains information about source files that have been
+# copied from other sources and need to be tracked
+#
+# The file may contain lines starting with ...
+# 
+# version: of file format
+# repo: repository definition
+# file: a mapping to track files
+#
+# Note that repo: entries must come *before* file: entries
+#
+# Repository Definitions are of the following format
+# --
+# repo: name-of-source-repo git|svn url-of-source-repo
+#
+# name-of-source-repo
+#   Name of source repository. The name will be used as reference in file:
+#   statements
+#
+# git|svn
+#   Type of source repository
+#
+# url-of-source-repo
+#   URL of source repository
+#
+# Mappings to track files are of the following format
+# ---
+# file: xen-file name-of-original-repo original-file commit-id
+#
+# xen-file
+#   Xen file that needs to be tracked
+#
+# name-of-original-repo
+#   A reference to a source repository defined by *repo* keyword
+#
+# original-file
+#   File in original-repo from which we regularly want to merge changes
+#   into xen-file
+#
+# commit id
+#   Last commit id of original-file that was deemed to be ok
+#   and either imported into the tree or rejected
+
+version: 1
-- 
2.13.0


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

Re: [Xen-devel] [PATCH v2] Add TRACKING.IMPORTS to xen.git to more easily manage imported files that need to be kept in sync with an upstream

[Lars Kurth]

On 24/05/2019, 05:24, "Jan Beulich"  wrote:

>>> On 24.05.19 at 03:36,  wrote:
> --- /dev/null
> +++ b/TRACKING.FILES
> @@ -0,0 +1,50 @@
> +# This file contains information about source files that have been
> +# copied from other sources and need to be tracked
> +#
> +# The file may contain lines starting with ...
> +# 
> +# version: of file format
> +# repo: repository definition
> +# file: a mapping to track files
> +#
> +# Note that repo: entries must come *before* file: entries
> +#
> +# Repository Definitions are of the following format
> +# --
> +# repo: name-of-source-repo git|svn https-url-of-source-repo
> +#
> +# name-of-source-repo:
> +#   Name of source repository. The name will be used as reference in 
file:
> +#   statements

May I suggest another formatting change, as the colon uses now
have different meaning:

# repo:   
#
# 
#   Name of source repository. The name will be used as reference in file:
#   statements

> +# git|svn:
> +#   Type ofsource repository

Nit: Missing blank.

> +# https-url-of-source-repo:
> +#   URL of source repository

Why https? Any form of URL should be fine here.

Sure. I think Ian suggested originally.

> +# For example:
> +#   repo: linux-torvalds git 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 

Didn't we agree on examples moving into the commit message,
or the post-commit-message area, as they'll become redundant
(and eventually stale) once we gain actual content here?

Ah yes, I had forgotten about this

Lars



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

[Xen-devel] [PATCH v2] Add TRACKING.IMPORTS to xen.git to more easily manage imported files that need to be kept in sync with an upstream

[Lars Kurth]

Following the recent discussion, we had on IRC and the action I had in 
the March community call, this file provides a file format that 
enables writing an automated test to check whether files are out of sync. 

Once the file format is agree, I will write a test or script.

I also need some more correct test data, aka entries in the file from
committers looking after the following files
[Jan]
xen/arch/x86/cpu/mwait-idle.c 
[Stefano, Julien - this has to be finalized]
xen/drivers/passthrough/arm/smmu.c
xen/arch/arm/vgic/*
xen/include/asm-arm/div64.h
xen/drivers/char/meson-uart.c
xen/arch/arm/arm32/lib/*
xen/arch/arm/arm64/lib/*
xen/arch/arm/arm64/cache.S
xen/arch/arm/arm64/bpi.S
xen/include/asm-arm/system.h
xen/arch/arm/arm64/insn.c
[Others?]
xen/common/rbtree.c

Note that in some cases Linux has diverged and some Linux files have 
disappeared. 
Julien also raised the point, that in some cases only a subset of code from 
Linux Xen files was applied or that only some functions get moved across to Xen.

I believe that is entirely OK. The workflow would be in most cases that:
- We use a Linux (source) commit as a benchmark and record the commit ID
- If there is a change in Linux the test will fail
- The committer looks at the diff and either
  - Decides to ignore it and bumps the commit ID in this file
  - Decides the change is needed, integrates it into Xen and then 
bumps the commit ID in this file

Changes since v1
* Require a colon after repo:, file:, ... keywords
* Replace manual:|auto: with file: as there auto: use-case was invalid
* Added more verbose description of format

Signed-off-by: Lars Kurth 
CC: committ...@xenproject.org

---
 TRACKING.FILES | 50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 TRACKING.FILES

diff --git a/TRACKING.FILES b/TRACKING.FILES
new file mode 100644
index 00..3afb468ed7
--- /dev/null
+++ b/TRACKING.FILES
@@ -0,0 +1,50 @@
+# This file contains information about source files that have been
+# copied from other sources and need to be tracked
+#
+# The file may contain lines starting with ...
+# 
+# version: of file format
+# repo: repository definition
+# file: a mapping to track files
+#
+# Note that repo: entries must come *before* file: entries
+#
+# Repository Definitions are of the following format
+# --
+# repo: name-of-source-repo git|svn https-url-of-source-repo
+#
+# name-of-source-repo:
+#   Name of source repository. The name will be used as reference in file:
+#   statements
+#
+# git|svn:
+#   Type ofsource repository
+#
+# https-url-of-source-repo:
+#   URL of source repository
+#
+# For example:
+#   repo: linux-torvalds git 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
+#
+# Mappings to track files are of the following format
+# ---
+# file: xen-file name-of-original-repo original-file commit-id
+#
+# xen-file:
+#   Xen file that needs to be tracked
+#
+# name-of-original-repo:
+#   A reference to a source repository defined by *repo* keyword
+#
+# original-file:
+#   File in original-repo from which we regularly want to merge changes
+#   into xen-file
+#
+# commit id:
+#   Last commit id of original-file that was deemed to be ok
+#   and either imported into the tree or rejected
+#
+# For example:
+#   file: xen/drivers/passthrough/arm/smmu.c linux-torvalds 
linux/drivers/iommu/arm-smmu.c b77cf11f094136
+
+version: 1
-- 
2.13.0


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

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Lars Kurth]

@Adam and Fedora Testing & QA:
any views on my proposal?
Regards
Lars

> On 13 May 2019, at 16:29, Lars Kurth  wrote:
> 
> Hi all,
> 
> I am going to step in here with my hat as Xen Project community
> manager. We had a discussion about this issue as part of last week's
> community call. I CC'ed a number of stake-holders, which probably
> should have been on the thread such as ITL (which builds QubesOS
> on top of Fedora) and Michael A Young (the Xen package manager).
> 
> First of all apologies that this issue has lingered so long. Key
> members of the community were not aware of the issues raised in
> this thread, otherwise we would have acted earlier. With this in
> mind, please in future raise issues with me, on xen-devel@,
> committers@ or the Xen-Fedora package manager. The Xen Community
> would like to see Fedora running as guest: in fact it would be
> somewhat odd if there was a Xen-Dom0 package and guest support
> didn't work. And there are some downstreams such as QubesOS,
> which depend on this support.
> 
>> On 6 Jul 2017, at 13:45, Adam Williamson  wrote:
>> 
>> On Thu, 2017-07-06 at 15:13 -0400, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Jul 06, 2017 at 11:59:01AM -0700, Adam Williamson wrote:
>>>> Hi, folks! A while ago, Xen virtualization functionality was added to
>>>> the criteria and the validation test case set, on the understanding
>>>> that Oracle would provide testing for it (and help fix bugs as they
>>>> arose).
>>>> 
>>>> For the last couple of releases we really have not had any such testing
>>> 
>>> We had been doing the testing, it just that we (or rather me and
>>> Dariof) seem to get a wind of this at the last minute. Not sure exactly
>>> how to fix that thought.
>> 
>> Well, I mean, every few *days* a compose gets nominated for validation
>> testing, and a mail is sent to test-announce. Just check your test-
>> announce archives for mails with "nominated for testing" in their
>> subject lines, and you'll see dozens. Is this not sufficient
>> notification?
> 
> We discussed this at the community call and came to the conclusion that
> we can run regular tests of Fedora RC's as part of our OSSTEST
> infrastructure. Ian Jackson volunteered to implement this, but there
> are some questions on
> a) The installer (which we can handle ourselves)
> b) When we would trigger a test - aka is there some trigger other than the
> c) How would results best be reported back to Fedora
> 
> Apologies, I am not very familiar with how the Fedora Test group works.
> Is there some documentation which would help integrate what you to with
> the test system of another open source project?
> 
>>>> from Oracle. On that basis, I'm proposing we remove this Final
>>>> criterion:
>>> 
>>> s/Oracle/Xen Project/ I believe?
>> 
>> Perhaps, it's just that it always seemed to be you doing the testing,
>> so they got a bit conflated :)
> 
> Can we come to some arrangement, by which such issues get communicated
> to the Xen Project earlier? Aka me, xen-devel@ or committers@
> 
>>>> "The release must boot successfully as Xen DomU with releases providing
>>>> a functional, supported Xen Dom0 and widely used cloud providers
>>>> utilizing Xen."
>>>> 
>>>> and change the 'milestone' for the test case -
>>>> https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Xen_Para_Virt -
>>>> from Final to Optional.
>>>> 
>>>> Thoughts? Comments? Thanks!
>>> 
>>> I would prefer for it to remain as it is.
>> 
>> This is only practical if it's going to be tested, and tested regularly
>> - not *only* on the final release candidate, right before we sign off
>> on the release. It needs to be tested regularly throughout the release
>> cycle, on the composes that are "nominated for testing".
> 
> Would the proposal above work for you? I think it satisfies what you are
> looking for. We would also have someone who monitors these test results
> pro-actively.
> 
> Then, there are the specific grub issues that need resolving
> [A1] https://bugzilla.redhat.com/show_bug.cgi?id=1486002 
> <https://bugzilla.redhat.com/show_bug.cgi?id=1486002>
> (and a recently filed duplicate @
>  https://bugzilla.redhat.com/show_bug.cgi?id=1691559 
> <https://bugzilla.redhat.com/show_bug.cgi?id=1691559>) caused by
>  [A2])
> [A2] https://bugzilla.redhat.com/show_bug.cgi?id=1264103 
> <https://bugzilla.redhat.com/show_bug.cgi?id=1264103>[B1] 
> https://bugzi

Re: [Xen-devel] [PATCH] Add TRACKING.IMPORTS to xen.git to more easily manage imported files that need to be kept in sync with an upstream

[Lars Kurth]

On 20/05/2019, 10:37, "Ian Jackson"  wrote:

This is going in the right direction IMO.
    
Lars Kurth writes ("Re: [PATCH] Add TRACKING.IMPORTS to xen.git to more 
easily manage imported files that need to be kept in sync with an upstream"):
> That makes perfect sense now. In that case, I tend to agree that "auto" 
is probably not needed. Would be quite happy to drop it.

It will considerably complicate things to add a way to define
seddery.  Let us leave that to a future extension.

That suggests that `manual' should become `file:'.

As for delimiters

> On 17/05/2019, 01:34, "Jan Beulich"  wrote:
> > I am not sure what you mean, which colons? Are you saying, the 
format should be
> > version: 1
> > repo: ...
> 
> Yes. This would make it even more prominent that these are tags of
> some sort. But this was only a thought of mine, it's in no way meant
> to be a requirement I have.

It will make writing a parser easier if each entry is a single line
with the fields in a defined order and if we can say that a `repo:'
must precede every `file:' that mentions it.

That sounds perfectly sensible
Version 2 on its way, sometimes next week

Lars


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

Re: [Xen-devel] [PATCH] Add TRACKING.IMPORTS to xen.git to more easily manage imported files that need to be kept in sync with an upstream

[Lars Kurth]

On 17/05/2019, 01:34, "Jan Beulich"  wrote:

>>> On 16.05.19 at 17:54,  wrote:

> 
> On 16/05/2019, 04:47, "Jan Beulich"  wrote:
> 
> >>> On 16.05.19 at 00:18,  wrote:
> > +# Mappings to track files are of the following format
> > +# ---
> > +# manual|auto xen-file name-of-original-repo original-file 
commit-id
> > +#
> > +# auto:
> > +#   The xen-file needs to track the the original-file exactly
> > +#   In other words, we can automatically update the file using a 
script
> 
> Do we have _any_ example of this? I can't even imagine one, due
> to e.g. our includes all starting with xen/ whereas Linux'es (just to
> take as example) all start with linux/. Perhaps "auto" needs to
> include sed expressions that need to be applied before actually
> applying the original change to our tree?
> 
> I am not sure I fully understand your concern. 
> This was intended for the case where say we would exactly track 
> xen/.../foo.bar with linux/.../foo.bar
> In other words, auto only applies to the content of a file: the filename 
> isn't relevant, because all the information that would be needed to do 
this 
> is in the file.

When talking about file names in my reply, I referred to C language
#include directives inside the file in question, as a (pretty important)
example. There was no talk about the cloned/copied file's name itself.
Hence the suggestion to accompany auto: with a set of sed
expressions, which could then e.g. transform #include 
into #include .

That makes perfect sense now. In that case, I tend to agree that "auto" is 
probably not needed. Would be quite happy to drop it.

> @Julien, @Stefano, @Jan: are any of the files you listed fall into the 
> "should be tracked exactly" category?

As I've said before - I can't even imagine such a file to exist.

> > +# manual:
> > +#   A developer needs to make a decision whether a
> > +#   specific change is applied or ignored and update the last 
commit id
> > +#   accordingly
> > +#
> > +# name-of-original-repo:
> > +#   A reference to a source repository defined by *repo* keyword
> > +#
> > +# commit id:
> > +#   Last commit id of source file that was deemed to be ok
> > +#   and either imported into the tree or rejected
> > +#
> > +# For example:
> > +#   manual xen/drivers/passthrough/arm/smmu.c linux-torvalds 
> linux/drivers/iommu/arm-smmu.c b77cf11f094136
> > +
> > +version 1
> 
> Perhaps it wouldn't hurt to include the colons in the actual entries 
as
> well? 
> 
> I am not sure what you mean, which colons? Are you saying, the format 
should be
> version: 1
> repo: ...

Yes. This would make it even more prominent that these are tags of
some sort. But this was only a thought of mine, it's in no way meant
to be a requirement I have.

> I think the confusion comes because I used colons after statements in the 
> comments. 

Right, that's how I got there.

> I think that "version: 1" is slightly more human-readable, so I would be 
OK 
> with that

A well defined non-blank separator also allows machine processing
to notice more easily if there's a malformed line. Plus (if need be)
it would permit tags with blanks in their names.

I can do that. No problem.

Any other comments from anyone, before sending version 2?

Lars


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

Re: [Xen-devel] [PATCH] Add TRACKING.IMPORTS to xen.git to more easily manage imported files that need to be kept in sync with an upstream

[Lars Kurth]

On 16/05/2019, 04:47, "Jan Beulich"  wrote:

>>> On 16.05.19 at 00:18,  wrote:
> +# Mappings to track files are of the following format
> +# ---
> +# manual|auto xen-file name-of-original-repo original-file commit-id
> +#
> +# auto:
> +#   The xen-file needs to track the the original-file exactly
> +#   In other words, we can automatically update the file using a script

Do we have _any_ example of this? I can't even imagine one, due
to e.g. our includes all starting with xen/ whereas Linux'es (just to
take as example) all start with linux/. Perhaps "auto" needs to
include sed expressions that need to be applied before actually
applying the original change to our tree?

I am not sure I fully understand your concern. 
This was intended for the case where say we would exactly track xen/.../foo.bar 
with linux/.../foo.bar
In other words, auto only applies to the content of a file: the filename isn't 
relevant, because all the information that would be needed to do this is in the 
file.

But if there is no need for it, we can drop it. And if needed, we can add in 
future.
@Julien, @Stefano, @Jan: are any of the files you listed fall into the "should 
be tracked exactly" category?

> +# manual:
> +#   A developer needs to make a decision whether a
> +#   specific change is applied or ignored and update the last commit id
> +#   accordingly
> +#
> +# name-of-original-repo:
> +#   A reference to a source repository defined by *repo* keyword
> +#
> +# commit id:
> +#   Last commit id of source file that was deemed to be ok
> +#   and either imported into the tree or rejected
> +#
> +# For example:
> +#   manual xen/drivers/passthrough/arm/smmu.c linux-torvalds 
linux/drivers/iommu/arm-smmu.c b77cf11f094136
> +
> +version 1

Perhaps it wouldn't hurt to include the colons in the actual entries as
well? 

I am not sure what you mean, which colons? Are you saying, the format should be
version: 1
repo: ...

I think the confusion comes because I used colons after statements in the 
comments. 
I think that "version: 1" is slightly more human-readable, so I would be OK 
with that

I also don't think examples are needed once we get the first
real entries. Hence I'd move them to the commit message or a
post-commit message remark.

Agreed.

Lars





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

[Xen-devel] [PATCH] Add TRACKING.IMPORTS to xen.git to more easily manage imported files that need to be kept in sync with an upstream

[Lars Kurth]

Following the recent discussion, we had on IRC and the action I had in 
the March community call, this file provides a file format that 
enables writing an automated test to check whether files are out of sync. 

Unlike in the IRC discussion, which suggested a single line for all
information, I broke out the repository into a separate statement for
- Better readability (aka shorter lines)
- Better maintainability if a repo URL changes

The list of files that need to be included are

Once the file format is agree, I will write a test or script.

I also need some more correct test data, aka entries in the file from
committers looking after the following files
[Jan]
xen/arch/x86/cpu/mwait-idle.c 
[Stefano, Julien - this has to be finalized]
xen/drivers/passthrough/arm/smmu.c
xen/arch/arm/vgic/*
xen/include/asm-arm/div64.h
xen/drivers/char/meson-uart.c
xen/arch/arm/arm32/lib/*
xen/arch/arm/arm64/lib/*
xen/arch/arm/arm64/cache.S
xen/arch/arm/arm64/bpi.S
xen/include/asm-arm/system.h
xen/arch/arm/arm64/insn.c
[Others?]
xen/common/rbtree.c

Note that in some cases Linux has diverged and some Linux files have 
disappeared. 
Julien also raised the point, that in some cases only a subset of code from 
Linux Xen files was applied or that only some functions get moved across to Xen.

I believe that is entirely OK. The workflow would be in most cases that:
- We use a Linux (source) commit as a benchmark and record the commit ID
- If there is a change in Linux the test will fail
- The committer looks at the diff and either
  - Decides to ignore it and bumps the commit ID in this file
  - Decides the change is needed, integrates it into Xen and then 
bumps the commit ID in this file

Signed-off-by: Lars Kurth 
CC: committ...@xenproject.org
---
 TRACKING.IMPORTS | 40 
 1 file changed, 40 insertions(+)
 create mode 100644 TRACKING.IMPORTS

diff --git a/TRACKING.IMPORTS b/TRACKING.IMPORTS
new file mode 100644
index 00..39829e078c
--- /dev/null
+++ b/TRACKING.IMPORTS
@@ -0,0 +1,40 @@
+# This file contains information about source files that have been
+# copied from other sources and need to be tracked
+#
+# The file may contain lines starting with ...
+# 
+# version: of file format
+# repo: repository definition
+# auto|manual: a mapping to track files
+#
+# Repository Definitions are of the following format
+# --
+# repo name-of-source-repo git|svn https-url-of-source-repo
+#
+# For example:
+#   repo linux-torvalds git 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
+#
+# Mappings to track files are of the following format
+# ---
+# manual|auto xen-file name-of-original-repo original-file commit-id
+#
+# auto:
+#   The xen-file needs to track the the original-file exactly
+#   In other words, we can automatically update the file using a script
+#
+# manual:
+#   A developer needs to make a decision whether a
+#   specific change is applied or ignored and update the last commit id
+#   accordingly
+#
+# name-of-original-repo:
+#   A reference to a source repository defined by *repo* keyword
+#
+# commit id:
+#   Last commit id of source file that was deemed to be ok
+#   and either imported into the tree or rejected
+#
+# For example:
+#   manual xen/drivers/passthrough/arm/smmu.c linux-torvalds 
linux/drivers/iommu/arm-smmu.c b77cf11f094136
+
+version 1
-- 
2.13.0


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

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Lars Kurth]

Apologies,
I mixed up some references
Lars

> On 13 May 2019, at 16:29, Lars Kurth  wrote:
> 
> Hi all,
> 
> I am going to step in here with my hat as Xen Project community
> manager. We had a discussion about this issue as part of last week's
> community call. I CC'ed a number of stake-holders, which probably
> should have been on the thread such as ITL (which builds QubesOS
> on top of Fedora) and Michael A Young (the Xen package manager).
> 
> First of all apologies that this issue has lingered so long. Key
> members of the community were not aware of the issues raised in
> this thread, otherwise we would have acted earlier. With this in
> mind, please in future raise issues with me, on xen-devel@,
> committers@ or the Xen-Fedora package manager. The Xen Community
> would like to see Fedora running as guest: in fact it would be
> somewhat odd if there was a Xen-Dom0 package and guest support
> didn't work. And there are some downstreams such as QubesOS,
> which depend on this support.
> 
>> On 6 Jul 2017, at 13:45, Adam Williamson  wrote:
>> 
>> On Thu, 2017-07-06 at 15:13 -0400, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Jul 06, 2017 at 11:59:01AM -0700, Adam Williamson wrote:
>>>> Hi, folks! A while ago, Xen virtualization functionality was added to
>>>> the criteria and the validation test case set, on the understanding
>>>> that Oracle would provide testing for it (and help fix bugs as they
>>>> arose).
>>>> 
>>>> For the last couple of releases we really have not had any such testing
>>> 
>>> We had been doing the testing, it just that we (or rather me and
>>> Dariof) seem to get a wind of this at the last minute. Not sure exactly
>>> how to fix that thought.
>> 
>> Well, I mean, every few *days* a compose gets nominated for validation
>> testing, and a mail is sent to test-announce. Just check your test-
>> announce archives for mails with "nominated for testing" in their
>> subject lines, and you'll see dozens. Is this not sufficient
>> notification?
> 
> We discussed this at the community call and came to the conclusion that
> we can run regular tests of Fedora RC's as part of our OSSTEST
> infrastructure. Ian Jackson volunteered to implement this, but there
> are some questions on
> a) The installer (which we can handle ourselves)
> b) When we would trigger a test - aka is there some trigger other than the
> c) How would results best be reported back to Fedora
> 
> Apologies, I am not very familiar with how the Fedora Test group works.
> Is there some documentation which would help integrate what you to with
> the test system of another open source project?
> 
>>>> from Oracle. On that basis, I'm proposing we remove this Final
>>>> criterion:
>>> 
>>> s/Oracle/Xen Project/ I believe?
>> 
>> Perhaps, it's just that it always seemed to be you doing the testing,
>> so they got a bit conflated :)
> 
> Can we come to some arrangement, by which such issues get communicated
> to the Xen Project earlier? Aka me, xen-devel@ or committers@
> 
>>>> "The release must boot successfully as Xen DomU with releases providing
>>>> a functional, supported Xen Dom0 and widely used cloud providers
>>>> utilizing Xen."
>>>> 
>>>> and change the 'milestone' for the test case -
>>>> https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Xen_Para_Virt -
>>>> from Final to Optional.
>>>> 
>>>> Thoughts? Comments? Thanks!
>>> 
>>> I would prefer for it to remain as it is.
>> 
>> This is only practical if it's going to be tested, and tested regularly
>> - not *only* on the final release candidate, right before we sign off
>> on the release. It needs to be tested regularly throughout the release
>> cycle, on the composes that are "nominated for testing".
> 
> Would the proposal above work for you? I think it satisfies what you are
> looking for. We would also have someone who monitors these test results
> pro-actively.
> 
> Then, there are the specific grub issues that need resolving
> [A1] https://bugzilla.redhat.com/show_bug.cgi?id=1486002 
> <https://bugzilla.redhat.com/show_bug.cgi?id=1486002>
> (and a recently filed duplicate @
>  https://bugzilla.redhat.com/show_bug.cgi?id=1691559 
> <https://bugzilla.redhat.com/show_bug.cgi?id=1691559>) caused by
>  [A2])
> [A2] https://bugzilla.redhat.com/show_bug.cgi?id=1703700 
> <https://bugzilla.redhat.com/show_bug.cgi?id=1703700>
> [B1] https://bugzilla.redhat.com/show_bug.cgi?id=1

Re: [Xen-devel] Criteria / validation proposal: drop Xen

[Lars Kurth]

Hi all,

I am going to step in here with my hat as Xen Project community
manager. We had a discussion about this issue as part of last week's
community call. I CC'ed a number of stake-holders, which probably
should have been on the thread such as ITL (which builds QubesOS
on top of Fedora) and Michael A Young (the Xen package manager).

First of all apologies that this issue has lingered so long. Key
members of the community were not aware of the issues raised in
this thread, otherwise we would have acted earlier. With this in
mind, please in future raise issues with me, on xen-devel@,
committers@ or the Xen-Fedora package manager. The Xen Community
would like to see Fedora running as guest: in fact it would be
somewhat odd if there was a Xen-Dom0 package and guest support
didn't work. And there are some downstreams such as QubesOS,
which depend on this support.

> On 6 Jul 2017, at 13:45, Adam Williamson  wrote:
> 
> On Thu, 2017-07-06 at 15:13 -0400, Konrad Rzeszutek Wilk wrote:
>> On Thu, Jul 06, 2017 at 11:59:01AM -0700, Adam Williamson wrote:
>>> Hi, folks! A while ago, Xen virtualization functionality was added to
>>> the criteria and the validation test case set, on the understanding
>>> that Oracle would provide testing for it (and help fix bugs as they
>>> arose).
>>> 
>>> For the last couple of releases we really have not had any such testing
>> 
>> We had been doing the testing, it just that we (or rather me and
>> Dariof) seem to get a wind of this at the last minute. Not sure exactly
>> how to fix that thought.
> 
> Well, I mean, every few *days* a compose gets nominated for validation
> testing, and a mail is sent to test-announce. Just check your test-
> announce archives for mails with "nominated for testing" in their
> subject lines, and you'll see dozens. Is this not sufficient
> notification?

We discussed this at the community call and came to the conclusion that
we can run regular tests of Fedora RC's as part of our OSSTEST
infrastructure. Ian Jackson volunteered to implement this, but there
are some questions on
a) The installer (which we can handle ourselves)
b) When we would trigger a test - aka is there some trigger other than the
c) How would results best be reported back to Fedora

Apologies, I am not very familiar with how the Fedora Test group works.
Is there some documentation which would help integrate what you to with
the test system of another open source project?

>>> from Oracle. On that basis, I'm proposing we remove this Final
>>> criterion:
>> 
>> s/Oracle/Xen Project/ I believe?
> 
> Perhaps, it's just that it always seemed to be you doing the testing,
> so they got a bit conflated :)

Can we come to some arrangement, by which such issues get communicated
to the Xen Project earlier? Aka me, xen-devel@ or committers@

>>> "The release must boot successfully as Xen DomU with releases providing
>>> a functional, supported Xen Dom0 and widely used cloud providers
>>> utilizing Xen."
>>> 
>>> and change the 'milestone' for the test case -
>>> https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Xen_Para_Virt -
>>> from Final to Optional.
>>> 
>>> Thoughts? Comments? Thanks!
>> 
>> I would prefer for it to remain as it is.
> 
> This is only practical if it's going to be tested, and tested regularly
> - not *only* on the final release candidate, right before we sign off
> on the release. It needs to be tested regularly throughout the release
> cycle, on the composes that are "nominated for testing".

Would the proposal above work for you? I think it satisfies what you are
looking for. We would also have someone who monitors these test results
pro-actively.

Then, there are the specific grub issues that need resolving
[A1] https://bugzilla.redhat.com/show_bug.cgi?id=1486002
 (and a recently filed duplicate @
  https://bugzilla.redhat.com/show_bug.cgi?id=1691559) caused by
  [A2])
[A2] https://bugzilla.redhat.com/show_bug.cgi?id=1703700
[B1] https://bugzilla.redhat.com/show_bug.cgi?id=1264103

The first makes it harder to boot Fedora _dom0_ (but workarounds exist).
While it is unpleasant, it doesn't break the release criterion, but
probably has deterred people from testing. The second one [B1] is about
Fedora _domU_, which breaks the release criterion.

Marek and Michael had a discussion about these and there was also
a summary from Daniel.

== On [A1]/[A2] ==
Lack of GRUB2 multiboot2/module2 commands in Fedora/RH which does not
allow you load Xen as dom0 on EFI platforms with or without secure
boot. Here are some relevant snippets from the discussions:

"In general both modules were dropped due to CVE-2015-5281 (grub2:
modules built in on EFI builds that allow loading arbitrary code,
circumventing secure boot) [A3][A4]. Of course this makes sense
because we do not want to break UEFI secure boot. But this means
that you cannot boot Xen dom0 on UEFI platforms. The Multiboot2
protocol support is required to do that. Potentially you can
use xen.efi directly but 

Re: [Xen-devel] [PATCH v2] docs/xl: Clarify documentation for mem-max and mem-set

[Lars Kurth]

On 13/05/2019, 08:28, "Wei Liu"  wrote:

On Mon, May 13, 2019 at 02:59:30PM +0100, Wei Liu wrote:
> On Wed, May 01, 2019 at 03:59:41PM +0100, George Dunlap wrote:
> > On 4/8/19 12:09 PM, George Dunlap wrote:
> > > mem-set is the primary command that users will need to use and
> > > understand.  Move it first, and clarify the wording; also specify that
> > > you can't set the target higher than maxmem from the domain config.
> > > 
> > > mem-max is actually a pretty useless command at the moment.  Clarify
> > > that users are not expected to use it; and document all of its quirky
> > > behavior.
> > > 
> > > Signed-off-by: George Dunlap 
> > 
> > Wei / Ian: Ping?
> > 
> > Juergen replied to my "review note" comment, not to anything actionable
> > in the patch (or commit message) itself.
> 
> Acked-by: Wei Liu 
> 
> (I already said this looked okay to me in v1)

I believe Lars' Rb from v1 still stands.

Yes
Lars


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

[Xen-devel] [ANNOUNCE] Xen Developer and Design Summit Program for 2019 is live

[Lars Kurth]

Dear Community Members,

we are excited to unveil the Xen Project Developer and Design Summit program 
and speaker schedule [1]. The ​Xen Project ​Developer ​and ​Design ​Summit 
​brings ​together ​the ​Xen ​Project’s ​community ​of ​developers ​and ​power 
​users ​for ​their ​annual ​conference. ​The ​conference ​is ​about ​sharing 
​ideas ​and ​the ​latest ​developments, ​sharing ​experience, ​planning, 
​collaboration ​and ​above ​all ​to ​have ​fun ​and ​to ​meet ​the ​community 
​that ​defines ​the ​Xen ​Project.
This year’s Summit is taking place in Chicago from July 9th to 11th [2]. 

In addition to presentations, the Xen Project will be running design sessions. 
These are problem-solving sessions with tangible outputs. Community members can 
submit sessions until July 10th [3]. 

To submit a design session, go to [3]
For a full list of submitted design sessions, go to [4]

Check out the event page for all details and we look forward to seeing you in 
July!

Best Regards
Lars

[1] https://events.linuxfoundation.org/events/xensummit-2019/program/schedule/
[2] https://events.linuxfoundation.org/events/xensummit-2019/
[3] https://design-sessions.xenproject.org/
[4] https://design-sessions.xenproject.org/list/discussion
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] RFC: File format to allow us to track imported files

[Lars Kurth]

Hi all,

following the recent discussion, we had on IRC and the action I had in the March
community call, I wanted to make a proposal related to the file format to track
files. I am not yet submitting a fully formed patch as there may be differing
opinions about the file format and name of the file.

I propose TRACKINGIMPORTS or for better readability TRACKING.IMPORTS in the
xen.git root as file name, but don’t have a strong opinion.

Ian originally proposed to add all information related to a mapping into
one single line. That however leads to VERY long lines. So, I decided to break
repository definitions into separate statements and allow referring to repos by
a shorthand.

That also has the advantage that should source repository locations ever change,
only a single line needs modification.

Let me know what you think.

Cheers
Lars

# This file contains information about source files that have been
# copied from other sources and need to be tracked
#
# The file may contain lines starting with ...
# 
# version: of file format
# repo: repository definition
# manual|auto: a mapping to track files
#
# Repository Definitions are of the following format
# --
# repo name-of-source-repo git|svn https-url-of-source-repo
#
# Mappings to track files are of the following format
# ---
# manual|auto xen-file name-of-source-repo source-file commit-id
#
# auto: we can automatically update the file using a script
# manual: a committer needs to make a decision as to whether a
#   change is applied or ignored and update the last commit id
#   accordingly
# name-of-source-repo: must be defined by *repo*
# commit id: last commit id of source file that was deemed to be ok
#   and either imported into the tree or rejected
#
version 1

# Example of a repository definitions
repo linux-master git 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

# Example of a mapping
manual xen/drivers/passthrough/arm/smmu.c linux-master 
linux/drivers/iommu/arm-smmu.c b77cf11f094136
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Guest Testing in OSSTEST - What distros and versions should we test against

[Lars Kurth]

> On 10 May 2019, at 01:48, Jan Beulich  wrote:
>> 
>> With regards to Windows testing we have some restrictions. We have tried 
>> several times to buy additional test licenses, but this never went anywhere 
>> (some of the VM licenses are not available for our environment, unless you 
>> bulk buy, which is very expensive). The only approach that would allow us to 
>> test against different windows versions would be to require everyone who may 
>> touch OSSTEST which is not doable.
>> 
>> I can bring this up with the MS open source office, if there are strong 
>> feelings about this and try again
> 
> If there's at least a (not overly) small chance of succeeding, I think this
> may be worth it, unless Rich's suggestion already helps.
> 

I will try again. Let's work on the basis that this is possible and see where 
it goes
Lars___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Guest Testing in OSSTEST - What distros and versions should we test against

[Lars Kurth]

Hi all,

following a discussion with committers about Guest testing in OSSTEST, it 
surfaced that we have not updated what distros we test in OSSTEST for a very 
long time. All agreed that we should regularly review what we test against: 
maybe at the beginning of a release cycle

In any case, currently we test against

x86 HVM guests:
  debian-9.4.0-{i386,amd64}-CD-1.iso
  rhel-server-6.1-i386-dvd.iso
  win10v1703-x86.iso
  win7-x64.iso
  ws16-x64.iso
  FreeBSD-10.1-CUSTOM-{i386,amd64}-20150525.raw.xz
  Debian HVM {i386,amd64} via debian-installer netinst [1]

x86 PV guests:
  Debian PV {i386,amd64} via debian-installer netinst [1]

ARM guests:
  Debian PV via debian-installer netinst [1]

[1] whatever Debian release osstest itself mostly runs

So I am opening the floor to suggestions.

With regards to Windows testing we have some restrictions. We have tried 
several times to buy additional test licenses, but this never went anywhere 
(some of the VM licenses are not available for our environment, unless you bulk 
buy, which is very expensive). The only approach that would allow us to test 
against different windows versions would be to require everyone who may touch 
OSSTEST which is not doable.

I can bring this up with the MS open source office, if there are strong 
feelings about this and try again

Lars

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

Re: [Xen-devel] [ANNOUNCE] Xen Project Community Call May 9th @15:00 UTC Call for agenda items

[Lars Kurth]

I added these to the agenda 
https://docs.google.com/document/d/1ktN-5u8uScEvhf9N8Um5o6poF12lVEnnySHJw_7Jk8k/edit#
 
<https://docs.google.com/document/d/1ktN-5u8uScEvhf9N8Um5o6poF12lVEnnySHJw_7Jk8k/edit#>
Feel free to add to it
Lars

> On 6 May 2019, at 09:23, Lars Kurth  wrote:
> 
> 
> 
>> On 6 May 2019, at 09:11, Woods, Brian > <mailto:brian.wo...@amd.com>> wrote:
>> 
>> On Mon, May 06, 2019 at 07:51:17AM -0600, Lars Kurth wrote:
>>> [CAUTION: External Email]
>>> 
>>> Hi all,
>>> 
>>> Please propose topics by either editing the running agenda document at 
>>> https://docs.google.com/document/d/1ktN-5u8uScEvhf9N8Um5o6poF12lVEnnySHJw_7Jk8k/edit#
>>>  
>>> <https://docs.google.com/document/d/1ktN-5u8uScEvhf9N8Um5o6poF12lVEnnySHJw_7Jk8k/edit#>
>>>  or by replying to the mail. Ideally by Wednesday!
>>> 
>>> Best Regards
>>> Lars
>>> 
>> 
>> I'd like to add the AMD mwait V2 patch set to the list of topics.  I'd
>> like to come to some sort of conclusion about that set.
>> 
> 
> I would like to add an item related to "[Xen-devel] Criteria / validation 
> proposal: drop Xen" which raises some questions about testing. More details 
> to follow
> 
> Lars

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

Re: [Xen-devel] [ANNOUNCE] Xen Project Community Call May 9th @15:00 UTC Call for agenda items

[Lars Kurth]

> On 6 May 2019, at 09:11, Woods, Brian  wrote:
> 
> On Mon, May 06, 2019 at 07:51:17AM -0600, Lars Kurth wrote:
>> [CAUTION: External Email]
>> 
>> Hi all,
>> 
>> Please propose topics by either editing the running agenda document at 
>> https://docs.google.com/document/d/1ktN-5u8uScEvhf9N8Um5o6poF12lVEnnySHJw_7Jk8k/edit#
>>  or by replying to the mail. Ideally by Wednesday!
>> 
>> Best Regards
>> Lars
>> 
> 
> I'd like to add the AMD mwait V2 patch set to the list of topics.  I'd
> like to come to some sort of conclusion about that set.
> 

I would like to add an item related to "[Xen-devel] Criteria / validation 
proposal: drop Xen" which raises some questions about testing. More details to 
follow

Lars

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

[Xen-devel] [ANNOUNCE] Xen Project Community Call May 9th @15:00 UTC Call for agenda items

[Lars Kurth]

Hi all,

Please propose topics by either editing the running agenda document at 
https://docs.google.com/document/d/1ktN-5u8uScEvhf9N8Um5o6poF12lVEnnySHJw_7Jk8k/edit#
 or by replying to the mail. Ideally by Wednesday!

Best Regards
Lars

== Dial-in Information ==

 ## Meeting time
 15:00 - 16:00 UTC
 Further International meeting times: 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019=5=9=15=0=0=225=224=24=179=136=37=33

 ## Dial in details
 Web: https://www.gotomeet.me/larskurth

 You can also dial in using your phone.
 Access Code: 906-886-965

 China (Toll Free): 4008 811084
 Germany: +49 692 5736 7317
 Poland (Toll Free): 00 800 1124759
 United Kingdom: +44 330 221 0088
 United States: +1 (571) 317-3129

 More phone numbers
 Australia: +61 2 9087 3604
 Austria: +43 7 2081 5427
 Argentina (Toll Free): 0 800 444 3375
 Bahrain (Toll Free): 800 81 111
 Belarus (Toll Free): 8 820 0011 0400
 Belgium: +32 28 93 7018
 Brazil (Toll Free): 0 800 047 4906
 Bulgaria (Toll Free): 00800 120 4417
 Canada: +1 (647) 497-9391
 Chile (Toll Free): 800 395 150
 Colombia (Toll Free): 01 800 518 4483
  Czech Republic (Toll Free): 800 500448
 Denmark: +45 32 72 03 82
 Finland: +358 923 17 0568
 France: +33 170 950 594
 Greece (Toll Free): 00 800 4414 3838
 Hong Kong (Toll Free): 30713169
 Hungary (Toll Free): (06) 80 986 255
 Iceland (Toll Free): 800 7204
 India (Toll Free): 18002669272
 Indonesia (Toll Free): 007 803 020 5375
 Ireland: +353 15 360 728
 Israel (Toll Free): 1 809 454 830
 Italy: +39 0 247 92 13 01
 Japan (Toll Free): 0 120 663 800
 Korea, Republic of (Toll Free): 00798 14 207 4914
 Luxembourg (Toll Free): 800 85158
 Malaysia (Toll Free): 1 800 81 6854
 Mexico (Toll Free): 01 800 522 1133
 Netherlands: +31 207 941 377
 New Zealand: +64 9 280 6302
 Norway: +47 21 93 37 51
 Panama (Toll Free): 00 800 226 7928
 Peru (Toll Free): 0 800 77023
 Philippines (Toll Free): 1 800 1110 1661
 Portugal (Toll Free): 800 819 575
 Romania (Toll Free): 0 800 410 029
 Russian Federation (Toll Free): 8 800 100 6203
 Saudi Arabia (Toll Free): 800 844 3633
 Singapore (Toll Free): 18007231323
 South Africa (Toll Free): 0 800 555 447
 Spain: +34 932 75 2004
 Sweden: +46 853 527 827
 Switzerland: +41 225 4599 78
 Taiwan (Toll Free): 0 800 666 854
 Thailand (Toll Free): 001 800 011 023
 Turkey (Toll Free): 00 800 4488 23683
 Ukraine (Toll Free): 0 800 50 1733
 United Arab Emirates (Toll Free): 800 044 40439
 Uruguay (Toll Free): 0004 019 1018
 Viet Nam (Toll Free): 122 80 481

 First GoToMeeting? Let's do a quick system check:
 https://link.gotomeeting.com/system-check
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] sched/credit: avoid priority boost for capped domains when unpark

[Lars Kurth]

> On 3 May 2019, at 10:48, Dario Faggioli  wrote:
> 
> On Fri, 2019-05-03 at 15:38 +, Eslam Elnikety wrote:
>> When unpausing a capped domain, the scheduler currently clears the
>> CSCHED_FLAG_VCPU_PARKED flag before vcpu_wake(). This, in turn,
>> causes the
>> vcpu_wake to set CSCHED_PRI_TS_BOOST, resulting in an unfair credit
>> boost. The
>> comment around the changed lines already states that clearing the
>> flag should
>> happen AFTER the unpause. This bug was introduced in commit
>> be650750945
>> "credit1: Use atomic bit operations for the flags structure".
>> 
>> Original patch author credit: Xi Xiong.
>> 
> Mmm... I'm not an expert of these things, but doesn't this means we
> need a "Signed-off-by: Xi Xiong " then? Cc-ing Lars...

As far as I can tell from a quick search on xen-devel@ Xi Xiong is or 
was an Amazon employee so a signed-off-by is not strictly necessary
but you may want to say something like.

Original patch author credit: Xi Xiong of Amazon

Lars

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

Re: [Xen-devel] [VOTE] tagging for operational messages sent to xen-devel@ (was Re: Xen 4.13 Development Update)

[Lars Kurth]

On 01/05/2019, 12:56, "Rich Persaud"  wrote:

> On May 1, 2019, at 14:37, Lars Kurth  wrote:
> 
> Rich,
> as nobody replied to the mail, I am inclined to dismiss the proposal of 
ANN for now
> Lars

What do you think about the suggestion to apply a tag ("ANNOUNCE"?) for 
emails that are mirrored to xen-devel from the -announce mailing list?  Jan 
commented on that suggestion in a separate thread.

I think that's fine, although we may have to change how the announce list 
works, otherwise on that list we get "[xen-announce] [ANNOUNCE] ..." if 
messages are cross posted, which would be odd and will surely annoy some people
Lars

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

[Xen-devel] No community call this week, but next week

[Lars Kurth]

Hi all,
I forgot to update my calendar to reflect for the new community call time and 
thus forgot to ask for agenda items. Sincere apologies. So I propose we have 
the meeting next week. Will send out agenda requests tomorrow
Lars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [VOTE] tagging for operational messages sent to xen-devel@ (was Re: Xen 4.13 Development Update)

[Lars Kurth]

Rich,
as nobody replied to the mail, I am inclined to dismiss the proposal of ANN for 
now
Lars

> On 25 Apr 2019, at 16:59, Rich Persaud  wrote:
> 
>> On Apr 25, 2019, at 12:36, Lars Kurth  wrote:
>> 
>> Alright,
>> 
>> there was a lengthy discussion on this topic on IRC - log attached. The 
>> consensus appears to be to use Canonical messages with a CAPITALISED tag. 
>> E.g. "[TAG] Xen 4.13 Development Update".
>> 
>> The options which seemed to have least objections are
>> 1: [ANNOUNCE]
>> 2: [OPERATIONS] 
>> 3: [PROCESS]
>> 
>> And that we should use these for other messages/announcements related to the 
>> operation of Xen Project Development.
> 
> On mobile devices, shorter subjects are better.  A [xen-devel] email already 
> has one 11-character tag. Since tags are in CAPITALS, abbreviated tags = less 
> SHOuting.
> 
>> [Diziet] Only because we copy everything from -announce to -devel.
> 
> Some mailing lists use [ANN] for announcements.  Email mirrored to xen-devel 
> from -announce could prefix the [ANN] tag, which would not be used for 
> non-mirrored email, since all announcements would be directed to -announce.
> 
>> [gwd] But in my mind, things like RM updates (which happen pretty regularly) 
>> and say, Developer Summit announcements, are different things.
> 
> The messages which prompted this discussion were related to release 
> management.  These were called RM in the IRC discussion, which suggests [RM] 
> as a possible tag.  It's quick to type and non-distracting to read.  This 
> would not preclude other tags for non [RM] messages.
> 
> Rich
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel


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

Re: [Xen-devel] [VOTE] tagging for operational messages sent to xen-devel@ (was Re: Xen 4.13 Development Update)

[Lars Kurth]

Hi all,

I almost dropped this: apologies. With the votes in, we have a clear winner for 
[ANNOUNCE] over the other options

ANNOUNCE1   2   2
OPERATIONS  -1  -1  1
PROCESS 0   0   -2

Lars

On 26/04/2019, 03:50, "Jan Beulich"  wrote:

>>> On 25.04.19 at 18:36,  wrote:
> Alright,
> 
> there was a lengthy discussion on this topic on IRC - log attached. The 
> consensus appears to be to use Canonical messages with a CAPITALISED tag. 
> E.g. "[TAG] Xen 4.13 Development Update".
> 
> The options which seemed to have least objections are
> 1: [ANNOUNCE]

+1

If mails to xen-announce really get reflected to xen-devel (I didn't
know this, and hence would have pointlessly sent stable release
announcements to both lists), then preferably with the tag
getting added in the process of reflecting.

> 2: [OPERATIONS] 

-1

> 3: [PROCESS]

0

Jan




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

[Xen-devel] Please submit Summit Design Sessions before May 6th

[Lars Kurth]

Hi all,

we are planning to launch the program for the Xen Project Developer Summit the 
week of May 6th. In the interest of attracting more attendees it is important 
that we have a good program when we launch. The talk submissions have been good 
this year, but as 50% of our content are design sessions it would be amazing if 
we could launch with as many design sessions as possible as it will make it 
easier for some attendees to get travel approval to come to the event. 

Thus, if you already have a design session in mind, please submit it now or at 
the latest by May 6th

Best Regards
Lars
P.S.: I BCC'ed people who have submitted talks to the summit 

How to create a design session
==
1: Go to https://design-sessions.xenproject.org/
2: Create a username, but unless you want your e-mail address to be public 
don't use your e-mail address as username
3: Submit a design session

If you are submitting a design session you are expected to moderate and lead 
the discussion. However, if you feel uncomfortable doing so, a more experienced 
moderator such as I or any of the maintainers can help and co-moderate. 

Note that design sessions are NOT talks, but discussions with tangible output 
(e.g. a set of notes published on a list, photos of whiteboards, etc). A few 
slides to introduce a topic are permissible. As moderator, you don't have to 
write the notes, but can nominate someone in the group of people attending the 
session to do so. 

What has been submitted so far
==
See https://design-sessions.xenproject.org/list/discussion
 
What are design sessions?
=
The aim of the Design and Problem Solving sessions are to give developers the 
opportunity to meet face-to-face to:
* Coordinate and plan upcoming features
* Discuss and agree on the design and architecture of future functionality
* Solve specific problems in existing and 
* Discuss and agree on best practices and changes to how the community works
* Interactive lessons learned sessions covering experiences of contributors, 
users and vendors

Examples of past Design Sessions
* Cadence of Xen Project and maintenance releases
* Developing the architecture and design for Xen Project live patching
* Updating the Xen Project security policy
* Evolution of virtual machine introspection (including HW assistance) in the 
Xen Hypervisor
* How to de-privileging QEMU and the x86 emulator to reduce the impact of 
security vulnerabilities in those components,
* Implementing KConfig support which allows to remove parts of Xen at compile 
time and run-time disablement of Xen features to reduce Xen’s trusted computing 
base
* Planning the next stage of PVH (which led to a re-think and PVH v2)
* Planning sessions for Xen Hardware support, including how to implement PCI 
passthrough on ARM, how we can improve testing for the increasing range of ARM 
HW with support for virtualization, and how to implement alt2pm on Intel 
architectures
* Release planning
* Restartable Dom0 and driver domains
* Testing and testing frameworks

There is no CfP for design sessions: sessions can still be submitted during the 
conference. There is also no pre-determined schedule: attendees will during the 
event vote on which sessions to attend and our design session scheduling tool 
will do automatic scheduling trying to minimise conflicts between attendees. 




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

Re: [Xen-devel] Xen Project Community Call April 4th: Minutes

[Lars Kurth]

### Attendees 
Lars Kurth, Wei Liu, George Dunlap, Paul Durrant, Andy Cooper (Citrix) 
Juergen Gross, Jan Beulich (Suse) 
Brian Woods (AMD) 
Tamas K Lengyel (Intel) 
Daniel Smith (Apertus) 
Christopher Clark (OpenXT Project) 
Julien Grall (Arm) 
Rich Persaud (OpenXT) 

### Actions not yet resolved 1: Tailored instances of Xen (Daniel): continuing 
the Nov 2018 discussion of KCONFIG/L0  hypervisor use cases. More details 
upcoming via wiki page. 

ACTION: Should have 1 document of files that lists what comes from Linux and 
need to be monitored - Lars to facilitate (work with Stefano and Jan on this) 

### Agenda Items 

1: Update from Automotive meeting last week in Cambridge (Lars) 

Andy: most of the work required for safety would also be useful for the 
community as a whole

George: Read through the Misra C spec - a lot of the rules look very sensible. 
There are a handful of rules which we would never implement. In many areas 
there is a grey area: e.g. there is a rule which says “don't use recursion, 
unless there is a good reason not to - and then document why”

Open Question
* How much are we willing to change coding style
* We may need to start with a few items and see how things go
* George was going to take the lead with: start with a set of easy rules, 
medium and some more complex ones. One where we clearly can’t fulfil: we need 
to get exceptions
* We also only need to be compliant with a subset (e.g. for ASIL B with ISO 
only requires 12 rules)

Jan: made the valid comment that we already have two data points. 
George: these were some more of the tougher issues. E.g. on stefano’s rule, we 
should probably have gone for an exception. Some patches we posted 

Start posting the requirements for ASIL B/ISO => Make this an action of the SIG.

2: Planning for Xen 4.13

* Release manager for Xen 4.13
Juergen would continue => Juergen will remain RM

Release cadence: keep on going with 8 months. Target early Nov for a release.
ACTION: communicate proposal to the list 

Juergen: could specify a fixed branch date - should discuss at the Developer 
Summit
ACTION: Place holder for release related stuff at the summit

Switch to use domheap page for page table (Wei)
Drop tmem (Wei)
x2APIC support for AMD (Jan)
Core scheduling series (Juergen)
CPUID/MSR handling (Andy)
EIBRS (Andy)

E-mail based approach: people don’t always see the mail
Decided to BCC are couple of years ago - that breaks filtering rules meaning 
people sometimes don’t see the mail
ACTION: Bring this up on IRC to make this more usable

3: Admin 
* Google docs vs. https://hackmd.io 
Agreement: Stick with Google docs
ACTION: Lars to talk to Wei about calendar/making meeting invite better

### New Series / Series that need attention 

Briefly discussed Brian’s mwait series and to find a way forward in which 
driver to implement
Too complex to resolve on the call - needs some more thought to resolve 

### AOB 

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

[Xen-devel] Xen Project Community Call April 4th: @15:00 UTC Call for agenda items

[Lars Kurth]

Hi all,

based on the doodle poll, we are changing the community call day to the first 
Thursday of each month.

Please propose topics by either editing the running agenda document at 
https://docs.google.com/document/d/1B279exjoLW1-7aL4Y-dxtS8NY-EUwJ7uTt8qEKWAmFY/edit#heading
 or by replying to the mail. Ideally by Wednesday!

Best Regards
Lars

== Dial-in Information ==

  ## Meeting time
  15:00 - 16:00 UTC
  Further International meeting times: 
  
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019=4=4=15=0=0=225=224=24=179=136=37=33

  ## Dial in details
  Web: https://www.gotomeet.me/larskurth

  You can also dial in using your phone.
  Access Code: 906-886-965

  China (Toll Free): 4008 811084
  Germany: +49 692 5736 7317
  Poland (Toll Free): 00 800 1124759
  United Kingdom: +44 330 221 0088
  United States: +1 (571) 317-3129

  More phone numbers
  Australia: +61 2 9087 3604
  Austria: +43 7 2081 5427
  Argentina (Toll Free): 0 800 444 3375
  Bahrain (Toll Free): 800 81 111
  Belarus (Toll Free): 8 820 0011 0400
  Belgium: +32 28 93 7018
  Brazil (Toll Free): 0 800 047 4906
  Bulgaria (Toll Free): 00800 120 4417
  Canada: +1 (647) 497-9391
  Chile (Toll Free): 800 395 150
  Colombia (Toll Free): 01 800 518 4483
   Czech Republic (Toll Free): 800 500448
  Denmark: +45 32 72 03 82
  Finland: +358 923 17 0568
  France: +33 170 950 594
  Greece (Toll Free): 00 800 4414 3838
  Hong Kong (Toll Free): 30713169
  Hungary (Toll Free): (06) 80 986 255
  Iceland (Toll Free): 800 7204
  India (Toll Free): 18002669272
  Indonesia (Toll Free): 007 803 020 5375
  Ireland: +353 15 360 728
  Israel (Toll Free): 1 809 454 830
  Italy: +39 0 247 92 13 01
  Japan (Toll Free): 0 120 663 800
  Korea, Republic of (Toll Free): 00798 14 207 4914
  Luxembourg (Toll Free): 800 85158
  Malaysia (Toll Free): 1 800 81 6854
  Mexico (Toll Free): 01 800 522 1133
  Netherlands: +31 207 941 377
  New Zealand: +64 9 280 6302
  Norway: +47 21 93 37 51
  Panama (Toll Free): 00 800 226 7928
  Peru (Toll Free): 0 800 77023
  Philippines (Toll Free): 1 800 1110 1661
  Portugal (Toll Free): 800 819 575
  Romania (Toll Free): 0 800 410 029
  Russian Federation (Toll Free): 8 800 100 6203
  Saudi Arabia (Toll Free): 800 844 3633
  Singapore (Toll Free): 18007231323
  South Africa (Toll Free): 0 800 555 447
  Spain: +34 932 75 2004
  Sweden: +46 853 527 827
  Switzerland: +41 225 4599 78
  Taiwan (Toll Free): 0 800 666 854
  Thailand (Toll Free): 001 800 011 023
  Turkey (Toll Free): 00 800 4488 23683
  Ukraine (Toll Free): 0 800 50 1733
  United Arab Emirates (Toll Free): 800 044 40439
  Uruguay (Toll Free): 0004 019 1018
  Viet Nam (Toll Free): 122 80 481

  First GoToMeeting? Let's do a quick system check:
  https://link.gotomeeting.com/system-check



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

[Xen-devel] Xen Project Developer Summit: CfP Reminder - Friday, April 12

[Lars Kurth]

Dear All,

this is a quick reminder that the CfP for the developer summit is approaching. 
The CfP for talks (aka morning sessions is on April 12th). We are also 
considering to allocate a day dedicated to embedded and safety related topics 
following last week's automotive meeting. The link for submissions is at 
https://events.linuxfoundation.org/events/xensummit-2019/program/call-for-proposals/

Design sessions can also already be submitted - see 
https://events.linuxfoundation.org/events/xensummit-2019/program/design-sessions/
 
There is no deadline for design sessions. However, early submissions are 
important as many attendees will decide whether to attend the event based on 
the program.

Best Regards
Lars


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

Re: [Xen-devel] Xen Project Community Call March: Poll for the best day (originally week of March 11, propose to move to the week of March 17th)

[Lars Kurth]

> On 15 Mar 2019, at 03:00, Jan Beulich  wrote:
> 
 On 14.03.19 at 18:22,  wrote:
>> Options are: 
>> a) Someone steps up and does the meeting either next week or the week after
>> b) Skip the March meeting
>> c) Skip the March meeting and restart April 4 and have the meeting the 1st 
>> Thu of every month thereafter
>> 
>> For a, would a volunteer please step up. I can help with logistics
>> Failing a, my preference is c, unless someone objects
> 
> I'd favor c as well, fwiw; I'm not going to be around Thur next week.
> 
> Jan

That looks like Thursday April 4th is the best option and then the 1st Thursday 
of each month. Will send out meeting details later today
Lars


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

Re: [Xen-devel] Xen 4.8.5 release missing on the website

[Lars Kurth]

This is now fixed
Lars

> On 25 Mar 2019, at 22:41, Lars Kurth  wrote:
> 
> Marek,
> thanks for pointing this out. I will fix this tomorrow
> Lars
> 
>> On 21 Mar 2019, at 23:11, Marek Marczykowski-Górecki 
>>  wrote:
>> 
>> Signed PGP part
>> Hi,
>> 
>> Looks like the new website doesn't list Xen 4.8.5:
>> 
>> https://xenproject.org/downloads/xen-project-archives/xen-project-4-8-series/
>> https://xenproject.org/xen-project-archives/
>> 
>> Both have 4.8.4 as the latest version.
>> 
>> -- 
>> 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?
>> 
>> 
> 


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

Re: [Xen-devel] Xen 4.8.5 release missing on the website

[Lars Kurth]

Marek,
thanks for pointing this out. I will fix this tomorrow
Lars

> On 21 Mar 2019, at 23:11, Marek Marczykowski-Górecki 
>  wrote:
> 
> Signed PGP part
> Hi,
> 
> Looks like the new website doesn't list Xen 4.8.5:
> 
> https://xenproject.org/downloads/xen-project-archives/xen-project-4-8-series/
> https://xenproject.org/xen-project-archives/
> 
> Both have 4.8.4 as the latest version.
> 
> -- 
> 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?
> 
> 


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

[Xen-devel] Xen Project Automotive Workshop (March 25/26, Cambridge, UK, Citrix) - last chance to register for & logistics

[Lars Kurth]

Hi all,

this is a quick reminder that 
https://wiki.xenproject.org/wiki/Developer_Meeting/March2019_-_Safety_Certification
 

 takes place Monday and Tuesday next week

Attending in person
If you are planning to attend in person, but have not registered, please do so 
before 16:00 UTC Tuesday March 18
If you have registered and cannot attend any more, please get in touch with me
The registration link is at 
https://docs.google.com/forms/d/e/1FAIpQLSc0WjJIF1t4_KkQobgi40D-nuKycz-h14HAvtfD6Q5SqipO0Q/viewform
 

 

Attending remotely
I will set up a Gotomeeting for the afternoon sessions for remote participants. 
We will also have an extra web-cam such that remote attendees can participate 
in white-board discussions.
The Gotomeeting will start at UTC 13:45 on Monday and UTC 13:30 on Tuesday
Please register via 
https://docs.google.com/forms/d/e/1FAIpQLSc0WjJIF1t4_KkQobgi40D-nuKycz-h14HAvtfD6Q5SqipO0Q/viewform
 

 such that I can send you a meeting invite

If you are planning to attend a morning session remotely, please let me know 
which session you want to attend such that I can send an invite by sending me 
an email

Parking
If you are driving to Cambridge, we will need your number plate. If you have 
registered already you should have received an e-mail with instructions from 
Vicki MacLennan 

Arriving
Please make sure you arrive at around 8:30, such that we can start on time. 
Note that there will be no breakfast, as most people are staying at hotels. 
However, we do have coffee and snacks in the kitchen next to the meeting rooms. 
When you arrive proceed to the 1st floor, where you will need to sign in (we 
prepared a list with your names) and pick up a name badge

If you arrive late, please send me a mail with expected arrival time.

Looking forward to see you all next week
Please let me know, if you have any questions

Best Regards
Lars


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

Re: [Xen-devel] Xen Project Community Call March: Poll for the best day (originally week of March 11, propose to move to the week of March 17th)

[Lars Kurth]

Hi all,

according to the poll the best two options are Monday (but Jan cant make it) or 
Thursday (Royger cant make it). I suggest we go for Thursday. The timing is 
causing me a problem this month though.
* Next week (wk of 18th), I already have an appointment - also we have 
https://wiki.xenproject.org/wiki/Developer_Meeting/March2019_-_Safety_Certification
 
<https://wiki.xenproject.org/wiki/Developer_Meeting/March2019_-_Safety_Certification>
 the week after
* The following week (week of 26th) I am on a plane on Thursday
* We are in the final stages of making 4.12 in both weeks

Options are: 
a) Someone steps up and does the meeting either next week or the week after
b) Skip the March meeting
c) Skip the March meeting and restart April 4 and have the meeting the 1st Thu 
of every month thereafter
 
For a, would a volunteer please step up. I can help with logistics
Failing a, my preference is c, unless someone objects

Regards
Lars

> On 25 Feb 2019, at 10:12, Lars Kurth  wrote:
> 
> Slight correction: in March daylight saving comes into effect with DST in 
> Europe starting March 31st and in the US March 10th. This means the meeting 
> times in March will be slightly off. Thank you to Stefano for spotting this
> 
>> ## Meeting time
>> 16:00 - 17:00 UTC
>> 8:00 -  9:00 EDT (San Francisco)
> In March only: 9:00 - 10:00, from April the above times are correct
>> 11:00 - 12:00 EDT (New York)
> In March only: 12:00 - 13:00, from April the above times are correct
>> 16:00 - 17:00 BST (London)
>> 17:00 - 18:00 CEST (Berlin)
>> 00:00 - 01:00 CST (Beijing)
> From April: 23:00 - 00:00
> 
> Regards
> Lars
> 
>> On 25 Feb 2019, at 17:59, Lars Kurth  wrote:
>> 
>> Hi all,
>> 
>> I had an action to determine the best day for community calls going forward: 
>> Wednesday clashes with a meeting that Andrew has to attend. This was a 
>> consequence of moving the meeting to the following time slot
>> 
> ...
>> 
>> Firstly, I would like to propose to move the meeting to the week of March 
>> 17th, as I am travelling the week of the 11th and would not be able to host 
>> it.
>> 
>> For the meeting day poll, please see https://doodle.com/poll/9g7ecu3tygw5adz8
>> 
>> Best Regards
>> Lars
> 

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

Re: [Xen-devel] Can someone pls repair patchwork?

[Lars Kurth]

On 14/03/2019, 07:23, "Oleksandr Andrushchenko"  wrote:

On 3/6/19 6:02 PM, Lars Kurth wrote:
>
> Oleksandr sent a mail to +webmas...@kernel.org
> Let's see whether anything comes back
>
> If not, I can try and do this via the LF's infrastructure team: they are 
probably handling this
> Please ping me in a week or so, if that is the case
bump

I reached out and will lot you know whether/what comes back
Best Regards
Lars

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

Re: [Xen-devel] Can someone pls repair patchwork?

[Lars Kurth]

On 06/03/2019, 16:00, "Ian Jackson"  wrote:

Lars Kurth writes ("Re: [Xen-devel] Can someone pls repair patchwork?"):
> Hi all, (+ Florian & +Ian, as NEC runs their own patchwork instance and 
may have some insights)
> 
> before I approach I wanted to ask whether we are sure this has to do with 
the list change. I am assuming that patchwork gets mails from a registered 
account on xen-devel. So it is not clear whether the domain change would cause 
this: see 
https://patchwork-freedesktop.readthedocs.io/en/latest/installation.html#subscribe-a-local-address-to-the-mailing-list
> 
> Looking at registered e-mails (see png), there appear to be two patchwork 
instances registered with xen-devel@
> * patchwork-xen-de...@patchwork.codeaurora.org
> * patchwork-xen-de...@patchwork.kernel.org 
> 
> Note that https://patchwork.codeaurora.org/project/xen-devel/list/ seems 
to have broken at the same time as the kernel.org one
> 
> @Ian: do you know what we did to the lists and/or e-mail handling around 
that time? Could this be primarily an issue caused by some infrastructure 
change?

I don't remember any dates but we did change the lists from
f...@lists.xen.org to f...@lists.xenproject.org for some corporate
tradmark branding kind of reason.  I doubt you want to revert that.

> Is there a way to check whether mails are actually sent from xen-devel@ 
to the patchwork instances?
> If so, maybe a Credativ ticket is needed

I doubt this is the problem.  I think what is needed is for the
patchwork instance owners to update their configuration for our new
mailing list name.

If you look here at this URL Julien provided
  https://patchwork.kernel.org/project/xen-devel/
you see that it says
  List address  xen-de...@lists.xen.org

That is what needs fixing.  Similarly for the codeaurora one I
presume.

I don't know who "owns" this inside the patchwork.kernel.org system.
It says "Maintainers" which is maybe the person who can update the
settings, but it is blank.  Maybe the thing is managed by the site
administrators then.

Unfortunately I could not find contact details for the site admins
for either of these anywhere on those websites.

Oleksandr sent a mail to +webmas...@kernel.org
Let's see whether anything comes back

If not, I can try and do this via the LF's infrastructure team: they are 
probably handling this
Please ping me in a week or so, if that is the case

Best Regards
Lars



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

[Xen-devel] [PATCH] Minor security policy text changes to avoid ambiguity

[Lars Kurth]

See http://xenbits.xen.org/gitweb/?p=people/larsk/governance.git;a=summary
for the repository.

Signed-off-by: Lars Kurth 
CC: committ...@xenproject.org
---
 security-policy.pandoc | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/security-policy.pandoc b/security-policy.pandoc
index 8e07384..74d0d8b 100644
--- a/security-policy.pandoc
+++ b/security-policy.pandoc
@@ -214,8 +214,9 @@ List members are allowed to make available to their users 
only the following:
 -   The planned disclosure date
 
 List members may, if (and only if) the Security Team grants permission, deploy
-fixed versions during the embargo. Permission for deployment, and any
-restrictions, will be stated in the embargoed advisory text.
+fixed versions to their own public facing service during the embargo. 
Permission
+for deployment, and any restrictions, will be stated in the embargoed advisory
+text.
 
 The Security Team will normally permit such deployment, even for systems where
 VMs are managed or used by non-members of the predisclosure list. The Security
@@ -232,6 +233,9 @@ information about the issue (as listed above). This applies 
whether the
 deployment occurs during the embargo (with permission - see above) or is
 planned for after the end of the embargo.
 
+NB: Distribution of updated software is prohibited (except to other members of
+the predisclosure list).
+
 *NOTE:* Prior v2.2 of this policy (25 June 2014) it was permitted to also make
 available the allocated CVE number. This is no longer permitted in accordance
 with MITRE policy.[]()
@@ -408,6 +412,7 @@ Change History {#changelog}
 --
 
 
+-   **v3.22 March 1st 2019:** Minor policy text clarifications
 -   **v3.21 Nov 19th 2018:** Added XCP-ng.org
 -   **v3.20 June 14th 2018:** Added Star Lab
 -   **v3.19 May 9th 2018:**??Remove Google and Xen 3.4 stable tree maintainer
-- 
2.13.0


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

Re: [Xen-devel] Preparing for Xen Project GSoC applications : Deadline Feb 6

[Lars Kurth]

Hi all,

looking through the list of GSoC orgs, the following orgs that sometimes have 
Xen related projects have been accepted into GSoC this year:
* https://wiki.freebsd.org/SummerOfCodeIdeas
* https://gsoc.honeynet.org/
* https://elinux.org/BeagleBoard/GSoC/Ideas [there is a Xen specific proposal 
not yet on the table]

If you come across anyone asking us, please point them in the right direction

Best Regards
Lars


> On 25 Feb 2019, at 18:36, Lars Kurth  wrote:
> 
> Hi all:
> 
> a quick note the we have *not* been accepted into GSoC this year (the current 
> acceptance rate seems to be that projects get GSOC slots every 3 years). A 
> big thank you to those who contributed to the project list. 
> 
> This does not mean that there won't be Xen related projects. There are a 
> number of Xen related projects in a number of other communities. Once the 
> full list of accepted organisations is available, I will collate a list and 
> get back to you
> 
> Best Regards
> Lars
> 
>> On 15 Jan 2019, at 13:33, Lars Kurth  wrote:
>> 
>> Hi all, 
>> 
>> I will be applying as a mentoring organisation for GSoC again this year: the 
>> application deadline is Feb 6 and by then we need to have 
>> https://wiki.xenproject.org/wiki/Outreach_Program_Projects in order. Given 
>> that we didn't get in last year, there is a 50/50 chance we get in this year.
>> 
>> Everyone on the CC list has projects listed on 
>> https://wiki.xenproject.org/wiki/Outreach_Program_Projects
>> 
>> Our project list is a little old and stale and that shows: we do need to 
>> bring this up-to-date and freshen it up with new projects. I believe that 
>> the Mini-OS and Unikraft projects need looking at. And we may have some new 
>> sensible projects in the Hypervisor itself. Mindy already agreed to go over 
>> the Mirage OS list.
>> 
>> If you want to withdraw your project: please let me know and I delete it: 
>> but let me know WHY you want to withdraw. E.g. is it complete
>> 
>> @Doug, @Comitters
>> Re 
>> https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Code_Standards_Checking_using_clang-format
>> Given that there has been some work on clang-format by EPAM, which no-one 
>> has looked at I am tempted to throw this out or re-do the project. Aka, die 
>> a next phase which includes integrating the tool into our workflow. But that 
>> may be too hard
>> Any views?
>> 
>> Regards
>> Lars
> 


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

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

[Lars Kurth]

> On 27 Feb 2019, at 10:16, Jan Beulich  wrote:
> 
 On 27.02.19 at 10:23,  wrote:
>> 
>> I recall that I read in an earlier thread that Julien and Stefano have 
>> access to the document, which would leave Jan and a few members of Citrix 
>> staff. Can those committers who need access raise their hands? I can then go 
>> ahead and order these.
> 
> Well, you've effectively raised my hand already. To be honest I'm not
> sure I want it raised: I fear to break in tears when I would get to read
> that book. In any event, I'd say ...

It's a reference document to look up stuff. Not something you would 
necessarily read upfront.

>> Having followed this thread (and the other MISRA related one from Stefano), 
>> it seems to me that potentially each of these discussions is quite divisive 
>> and take up a lot of discussion and emotional energy. With 143 rules and 16 
>> "directives" (more like guidance) and some of the rules being mandatory 
>> (73%) 
>> and some advisory (27%), but the possibility to justify deviating from the 
>> rule, maybe we are approaching this wrongly. 
>> 
>> I have some thoughts about the approach and will follow up on this thread 
>> later today or tomorrow when I had some more time to clarify my thoughts.
> 
> ... don't order anything before we aren't clear whether we really want
> to do this (or even any part thereof) to the code base.

Alright: firstly I need to explain that I asked EPAM to start looking a half 
dozen or so "interesting" Misra compliance issues and post RFC patches. The 
idea behind this was to gather data about how as a community we would handle 
these  kind of issues. There was a discussion about Misra (or safety related 
coding standards in general) at last years developer summit, which went nowhere 
due to lack of data. 

It is clear to me that as a community we have to deal with Misra C compliance 
and other efforts to make Xen more easily safety certifiable seriously and 
can't just wish it to go away. I think it is fair to say that the project is 
facing increased competition from KVM and containers, while at the same time 
Xen has unique advantages that lead vendors to go down the embedded/safety 
route. If, as a community we just dismiss these efforts, we risk a fork or 
those vendors going elsewhere. Neither would be good for the community.

Having seen the two discussions so far, it appears that even when we agree 
that there is an issue, we seem to have real issues agreeing on workable 
solutions. I also already had complaints that these threads generate to much 
discussion (aka "noise").

What I don't know, is whether the two issues posted (this one and 
https://markmail.org/message/ni3yziazuwb2aolx) are representative for the kind 
of issue we need to fix to achieve on Misra compliance, or whether they are 
difficult outliers.

@Oleksandr: maybe you have some insights 

So the question is how we should approach this:

1: One is to follow what we do now - post patches per issue and work through 
   them. This only really scales if the majority of patches are in essence
   uncontroversial.

2: A slightly different approach would be for EPAM to post a few more examples 
   of the type of issues that we would have to deal with if we want to be MISRA
   compliant. But that we exercise restraint in the discussion knowing that 
these
   are examples to inform a discussion at https://wiki.xenproject.org/wiki/
   Developer_Meeting/March2019_-_Safety_Certification and possible follow-up.

   What I was after when I asked EPAM to post Misra related patches was to
   get a sense of the impact and a sense of how easily resolvable issues are.
   But I wouldn't expect a full resolution at this stage, if there
   is controversy. 

   So maybe we can handle these in a different way. From my PoV, it would be 
good 
   enough if key reviewers communicated per example whether
   - They accept that fixing the issue would be beneficial
   - What concerns they have
   - And how much they would fight for or against such a patch
 (using the -2 ... +2 scale as outlined in "EXPRESSING AGREEMENT AND 
 DISAGREEMENT" in https://xenproject.org/developers/governance/#decisions
   
   Clearly there can be some discussion, but we don't really need to "fight
   to the end" over these. 

3: Or we could change approach completely and go for a more high-level
   design and/or analysis based approach before we do anything else. I will 
expand 
   further down.

My personal preference would be to use 2 for a few patches, followed by 
3 as it gives us a different perspective.

Let me outline my thinking on 3:

There are a few things about Misra that we do not yet fully understand on a
number of different dimensions:
a) Issues are either mandatory or advisory. The scale changes depending on 
   the required level of safety (expressed in ASIL A-D).
b) There will likely be clusters of Misra rules we likely violate frequently
   and others we are hardly or not affected by   

We 

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

[Lars Kurth]

> On 26 Feb 2019, at 18:27, Stefano Stabellini  wrote:
> 
> On Tue, 26 Feb 2019, Jan Beulich wrote:
>>> So, we'll end up having lots of macros then which is obviously
>>> not good. That said, I hope we can work out some common approach
>>> not only to this issue, but how we deal with such in general.
>> 
>> I guess then I have to ask for giving a complete picture of what
>> other code uglifications are going to be proposed. If, to be MISRA-
>> compliant, we have to turn all of our code into an unreadable
>> mess, than I'm afraid I have to question whether we really want
>> to go that route. We then may be better off stopping the whole
>> exercise now, rather than after having done several initial steps
>> already.
> 
> Hi Jan,
> 
> I don't think there is a simple answer to your point. But the best way
> to get an idea is to give a look at MISRA-C [1]. It's less than 50GBP, I
> am hoping Lars will be able to sort it out for you. The purpose of this
> work is also to provide the context for the upcoming f2f discussions.


I can certainly do this: the cost of buying a few copies of MISRA C standard 
documents for a few committers is something I can approve without needing 
advisory board approval. The documents are shipped in PDF and the license is 
single user. To buy them I need the names and e-mail addresses of those who 
need it. 

I recall that I read in an earlier thread that Julien and Stefano have access 
to the document, which would leave Jan and a few members of Citrix staff. Can 
those committers who need access raise their hands? I can then go ahead and 
order these.

Having followed this thread (and the other MISRA related one from Stefano), it 
seems to me that potentially each of these discussions is quite divisive and 
take up a lot of discussion and emotional energy. With 143 rules and 16 
"directives" (more like guidance) and some of the rules being mandatory (73%) 
and some advisory (27%), but the possibility to justify deviating from the 
rule, maybe we are approaching this wrongly. 

I have some thoughts about the approach and will follow up on this thread later 
today or tomorrow when I had some more time to clarify my thoughts.

Regards
Lars  


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

Re: [Xen-devel] Preparing for Xen Project GSoC applications : Deadline Feb 6

[Lars Kurth]

Hi all:

a quick note the we have *not* been accepted into GSoC this year (the current 
acceptance rate seems to be that projects get GSOC slots every 3 years). A big 
thank you to those who contributed to the project list. 

This does not mean that there won't be Xen related projects. There are a number 
of Xen related projects in a number of other communities. Once the full list of 
accepted organisations is available, I will collate a list and get back to you

Best Regards
Lars

> On 15 Jan 2019, at 13:33, Lars Kurth  wrote:
> 
> Hi all, 
> 
> I will be applying as a mentoring organisation for GSoC again this year: the 
> application deadline is Feb 6 and by then we need to have 
> https://wiki.xenproject.org/wiki/Outreach_Program_Projects in order. Given 
> that we didn't get in last year, there is a 50/50 chance we get in this year.
> 
> Everyone on the CC list has projects listed on 
> https://wiki.xenproject.org/wiki/Outreach_Program_Projects
> 
> Our project list is a little old and stale and that shows: we do need to 
> bring this up-to-date and freshen it up with new projects. I believe that the 
> Mini-OS and Unikraft projects need looking at. And we may have some new 
> sensible projects in the Hypervisor itself. Mindy already agreed to go over 
> the Mirage OS list.
> 
> If you want to withdraw your project: please let me know and I delete it: but 
> let me know WHY you want to withdraw. E.g. is it complete
> 
> @Doug, @Comitters
> Re 
> https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Code_Standards_Checking_using_clang-format
> Given that there has been some work on clang-format by EPAM, which no-one has 
> looked at I am tempted to throw this out or re-do the project. Aka, die a 
> next phase which includes integrating the tool into our workflow. But that 
> may be too hard
> Any views?
> 
> Regards
> Lars


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

Re: [Xen-devel] Xen Project Community Call March: Poll for the best day (originally week of March 11, propose to move to the week of March 17th)

[Lars Kurth]

Slight correction: in March daylight saving comes into effect with DST in 
Europe starting March 31st and in the US March 10th. This means the meeting 
times in March will be slightly off. Thank you to Stefano for spotting this

> ## Meeting time
> 16:00 - 17:00 UTC
> 8:00 -  9:00 EDT (San Francisco)
In March only: 9:00 - 10:00, from April the above times are correct
> 11:00 - 12:00 EDT (New York)
In March only: 12:00 - 13:00, from April the above times are correct
> 16:00 - 17:00 BST (London)
> 17:00 - 18:00 CEST (Berlin)
> 00:00 - 01:00 CST (Beijing)
From April: 23:00 - 00:00

Regards
Lars

> On 25 Feb 2019, at 17:59, Lars Kurth  wrote:
> 
> Hi all,
> 
> I had an action to determine the best day for community calls going forward: 
> Wednesday clashes with a meeting that Andrew has to attend. This was a 
> consequence of moving the meeting to the following time slot
> 
...
> 
> Firstly, I would like to propose to move the meeting to the week of March 
> 17th, as I am travelling the week of the 11th and would not be able to host 
> it.
> 
> For the meeting day poll, please see https://doodle.com/poll/9g7ecu3tygw5adz8
> 
> Best Regards
> Lars


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

[Xen-devel] Xen Project Community Call March: Poll for the best day (originally week of March 11, propose to move to the week of March 17th)

[Lars Kurth]

Hi all,

I had an action to determine the best day for community calls going forward: 
Wednesday clashes with a meeting that Andrew has to attend. This was a 
consequence of moving the meeting to the following time slot

## Meeting time
16:00 - 17:00 UTC
 8:00 -  9:00 EDT (San Francisco)
11:00 - 12:00 EDT (New York)
16:00 - 17:00 BST (London)
17:00 - 18:00 CEST (Berlin)
00:00 - 01:00 CST (Beijing)

Firstly, I would like to propose to move the meeting to the week of March 17th, 
as I am travelling the week of the 11th and would not be able to host it.

For the meeting day poll, please see https://doodle.com/poll/9g7ecu3tygw5adz8

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

Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

[Lars Kurth]

> On 25 Feb 2019, at 13:47, Oleksandr Andrushchenko  wrote:
> 
> On 2/25/19 3:40 PM, Julien Grall wrote:
>> 
 My point is not about sending such code on the mailing list. My point is 
 you need to provide as much as possible details in your cover letter so we 
 can be more efficient when reviewing. For instance, many of us does not 
 have access to MISRA spec because it is not free...
>>> While I agree that one has to provide as much supporting information as 
>>> possible
>>> while presenting some work to the community it is that I cannot disclose
>>> MISRA rules here. As you said, MISRA spec is not free. And of course I 
>>> cannot
>>> expect anyone to by it for the reason that someone wants some patch to be
>>> "securely" or blindly reviewed. (BTW, this is the topic that has already 
>>> been
>>> raised in our team internally and being discussed)
>> 
>> I understand that MISRA is not free and does not ask you to copy/paste the 
>> PDF.
>> 
>> What I ask is provide enough pointer for us to understand how this fits in 
>> Xen code base. For instance, a lot of the MISRA rules have explanation 
>> online (see website such as [1] and [2]). Another alternative is to 
>> summarize the issues with your own arguments.
>> 
> Totally agree, I'll try harder next time in finding open sources with rule's
> descriptions

I am wondering, whether it would make sense to buy a set of MISRA C online 
copies for people who regularly review other people's code (eg. one per active 
committer). The cost is not that high per license
The problem is that it would exclude a part of the community
There would also be a minimal management overhead

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

Re: [Xen-devel] Organising a workshop to solve safety certification related questions (March 25/26, Cambridge, UK, Citrix)

[Lars Kurth]

Hi Matt,

> If you want some help putting the business case together at the top of Day 1, 
> I am more than happy to help with that. 
thank you, that would be appreciated. Artem and Alex are also looking at 
helping. But nothing is set in stone: I will fire off 

> Also, should we have some discussion around the Elisa project and if there 
> should be any cross working between Xen and that group?
Agreed: one way of looking at this would be to use learnings from the process 
we are starting in the Xen Project which could serve as input for Elisa.
Do you think it makes sense to invite Kate Steward? I can reach out to her, but 
this maybe somewhat premature. 

Maybe a slot about related initiatives would be good: as far as I understand 
there is an update about SIL2LinuxMP at embedded world Conference 2019 this 
week, which may be worth summarising.

Best Regards
Lars
P.S.: I am currently checking whetherCitrix can host more than 16 people for 
the meeting (which is the capacity of the meeting room I have booked) - it 
looks as if we will be close or beyond that number

> On 25 Feb 2019, at 11:34, Matt Spencer  wrote:
> 
> Hey Lars
> 
> If you want some help putting the business case together at the top of Day 1, 
> I am more than happy to help with that.  Also, should we have some discussion 
> around the Elisa project and if there should be any cross working between Xen 
> and that group?
> 
> /Matt
> From: Lars Kurth mailto:lars.kurth@gmail.com>>
> Sent: 22 February 2019 15:26
> To: xen-devel; Rachel Romoff; Nancy McGrory
> Cc: Committers; Rich Persaud; Jarvis Roach; Matt Spencer; Artem Mygaiev; 
> Robin Randhawa; Stewart Hildebrand; vfac...@de.adit-jv.com 
> <mailto:vfac...@de.adit-jv.com>; Alex Agizim; Irby Thompson; Giulio Corradi; 
> Richard Bellairs; Hisao Munakata; George Dunlap; Oscar Ballan; Stefano 
> Stabellini; Saraschandra Reddy Madem
> Subject: Re: Organising a workshop to solve safety certification related 
> questions (March 25/26, Cambridge, UK, Citrix)
>  
> Hi everyone,
> I made some progress on the agenda: see 
> https://docs.google.com/document/d/1aKjxDLkEnPZ_0gHgAv4xy9iPv6hVBkIC_wiA0rZzRms/edit
>  
> <https://docs.google.com/document/d/1aKjxDLkEnPZ_0gHgAv4xy9iPv6hVBkIC_wiA0rZzRms/edit>
>   
> There are still a few gaps that need filling: feedback, additional 
> suggestions, etc. are very welcome
> Lars
> 
>> On 15 Feb 2019, at 18:38, Lars Kurth > <mailto:lars.kurth@gmail.com>> wrote:
>> 
>> Hi all,
>> 
>> apologies this took a while. 5 weeks to go to the event!
>> I created 
>> https://wiki.xenproject.org/wiki/Developer_Meeting/March2019_-_Safety_Certification
>>  
>> <https://wiki.xenproject.org/wiki/Developer_Meeting/March2019_-_Safety_Certification>
>>  which contains information about the venue, hotels and travel
>> 
>> I also added a registration form: please fill this out if you want to attend 
>> (even if just remotely): see 
>> https://wiki.xenproject.org/wiki/Developer_Meeting/March2019_-_Safety_Certification#Registration_.28both_in_person_and_for_remote_participation.29
>>  
>> <https://wiki.xenproject.org/wiki/Developer_Meeting/March2019_-_Safety_Certification#Registration_.28both_in_person_and_for_remote_participation.29>
>> 
>> I started to put in some thoughts with regards to the agenda: I will be 
>> looking for volunteers to help with some of the content. I am working with 
>> EPAM on some of these, but others are welcome to join.
>> A scratchpad of ideas which will eventually become an agenda are here: 
>> https://docs.google.com/document/d/1aKjxDLkEnPZ_0gHgAv4xy9iPv6hVBkIC_wiA0rZzRms/edit
>>  
>> <https://docs.google.com/document/d/1aKjxDLkEnPZ_0gHgAv4xy9iPv6hVBkIC_wiA0rZzRms/edit>
>>  
>> 
>> If you need a visa invitation letter, there is a 3 working day turnaround. 
>> Please contact me via my Citrix email address as outlined in the Wiki page 
>> if you need an invitation letter
>> 
>> Best Regards
>> Lars
>> 
>> 
>>> On 4 Feb 2019, at 20:25, Lars Kurth >> <mailto:lars.kurth@gmail.com>> wrote:
>>> 
>>> Hi all,
>>> 
>>> from my perspective we have enough momentum to move forward, albeit some 
>>> prospective attendees are still confirming their travel plans. I can 
>>> accommodate a maximum if 15, but possibly, a few more. With this in Mind, 
>>> please start booking flights.
>>> 
>>> Location:
>>> The Citrix office in Milton, just outside of Cambridge
>>> Citrix Systems:
>>> 101 Cambridge Science Park Rd, Milton
>>> Cambridge CB4 0FY
>>> UK
>>

Re: [Xen-devel] Organising a workshop to solve safety certification related questions (March 25/26, Cambridge, UK, Citrix)

[Lars Kurth]

Hi everyone,
I made some progress on the agenda: see 
https://docs.google.com/document/d/1aKjxDLkEnPZ_0gHgAv4xy9iPv6hVBkIC_wiA0rZzRms/edit
 
<https://docs.google.com/document/d/1aKjxDLkEnPZ_0gHgAv4xy9iPv6hVBkIC_wiA0rZzRms/edit>
  
There are still a few gaps that need filling: feedback, additional suggestions, 
etc. are very welcome
Lars

> On 15 Feb 2019, at 18:38, Lars Kurth  wrote:
> 
> Hi all,
> 
> apologies this took a while. 5 weeks to go to the event!
> I created 
> https://wiki.xenproject.org/wiki/Developer_Meeting/March2019_-_Safety_Certification
>  
> <https://wiki.xenproject.org/wiki/Developer_Meeting/March2019_-_Safety_Certification>
>  which contains information about the venue, hotels and travel
> 
> I also added a registration form: please fill this out if you want to attend 
> (even if just remotely): see 
> https://wiki.xenproject.org/wiki/Developer_Meeting/March2019_-_Safety_Certification#Registration_.28both_in_person_and_for_remote_participation.29
>  
> <https://wiki.xenproject.org/wiki/Developer_Meeting/March2019_-_Safety_Certification#Registration_.28both_in_person_and_for_remote_participation.29>
> 
> I started to put in some thoughts with regards to the agenda: I will be 
> looking for volunteers to help with some of the content. I am working with 
> EPAM on some of these, but others are welcome to join.
> A scratchpad of ideas which will eventually become an agenda are here: 
> https://docs.google.com/document/d/1aKjxDLkEnPZ_0gHgAv4xy9iPv6hVBkIC_wiA0rZzRms/edit
>  
> <https://docs.google.com/document/d/1aKjxDLkEnPZ_0gHgAv4xy9iPv6hVBkIC_wiA0rZzRms/edit>
>  
> 
> If you need a visa invitation letter, there is a 3 working day turnaround. 
> Please contact me via my Citrix email address as outlined in the Wiki page if 
> you need an invitation letter
> 
> Best Regards
> Lars
> 
> 
>> On 4 Feb 2019, at 20:25, Lars Kurth > <mailto:lars.kurth@gmail.com>> wrote:
>> 
>> Hi all,
>> 
>> from my perspective we have enough momentum to move forward, albeit some 
>> prospective attendees are still confirming their travel plans. I can 
>> accommodate a maximum if 15, but possibly, a few more. With this in Mind, 
>> please start booking flights.
>> 
>> Location:
>> The Citrix office in Milton, just outside of Cambridge
>> Citrix Systems:
>> 101 Cambridge Science Park Rd, Milton
>> Cambridge CB4 0FY
>> UK
>> 
>> Timing
>> The event will be held on Monday March 25, and ends on the 26th. I expect 
>> days to go from 9:00 to 17:00 and some beverages and food will be provided
>> EPAM will host an evening event on the 25th
>> 
>> Agenda
>> With regards the agenda, I will work selected community members on it.
>> The agenda is yours, so please prepare and be specific about the technical, 
>> community, process and maybe financial problems we have to solve.
>> 
>> Remote Participation
>> I will still need to test this and provide more feedback
>> 
>> Registration
>> I will set up an ad-hoc google doc
>> 
>> Getting To Cambridge/Accommodation
>> London Stansted is the easiest airport to fly to: there is a direct train 
>> that goes frequently and take 30-40 minutes
>> You may have to use London Heathrow you come from the US, China or Japan. In 
>> that case, you can take a fixed rate taxi: see 
>> http://www.expressairporttransport.co.uk/Taxi-Cambridge-To-Heathrow-Airport 
>> <http://www.expressairporttransport.co.uk/Taxi-Cambridge-To-Heathrow-Airport>
>> 
>> The key question you will have to decide upon is whether you stay in the 
>> town centre, which is stunning, but it may take 30 mins to the Citrix 
>> office, or whether you stay close tp the office. I will provide more info in 
>> due time
>> 
>> Regards
>> Lars 
>> 
>>> On 23 Jan 2019, at 10:16, Lars Kurth >> <mailto:lars.kurth@gmail.com>> wrote:
>>> 
>>> Hi all,
>>> 
>>> it looks as if March 25/26 in Frankfurt or Cambridge is the best option. 
>>> For Matt, this would mean that he can only attend the first day, but I 
>>> believe this would be OK. Maybe Robin can attend the second day, instead of 
>>> Matt. Before we finalise the dates, I will need to secure the meeting 
>>> space. I will be able to do this in the next few days and will send an 
>>> update as soon as this is done.
>>> 
>>> Note that we had a few people on this list which have replied to me 
>>> privately. Please let me know privately or publicly whether March 25/26 
>>> would be suitable for you. We can in para

[Xen-devel] Changes to Xen Project websites: xenproject.org & blog.xenproject.org

[Lars Kurth]

Dear Community members,

today and tomorrow, we are making changes to Xen Project web real-estate. 
Specifically, the Xen project website at xenproject.org is replaced by a new 
website and the content of blog.xenproject.org will move to xenproject.org/blog 

While we execute the switch-over there may be some hitches, due to the work 
being executed in different time-zones. This may mean that SSL certificates may 
be temporarily invalid. Please bear with us, while we complete this work.

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

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Lars Kurth]

> On 18 Feb 2019, at 12:16, George Dunlap  wrote:
> 
> On 2/18/19 12:11 PM, George Dunlap wrote:
>> On 2/18/19 12:01 PM, Andrew Cooper wrote:
>>> On 18/02/2019 11:57, Wei Liu wrote:
>>>> On Mon, Feb 18, 2019 at 11:53:15AM +, Lars Kurth wrote:
>>>>> 
>>>>>> On 18 Feb 2019, at 11:30, George Dunlap  wrote:
>>>>>> 
>>>>>> On 2/18/19 11:23 AM, Wei Liu wrote:
>>>>>>> On Mon, Feb 18, 2019 at 11:17:56AM +, Lars Kurth wrote:
>>>>>>>> Thank you Wei. It's interesting though that the full vs HVM only is 
>>>>>>>> almost identical in terms of SLOC's
>>>>>>>> Lars
>>>>>>> The cloc target counts the files in the dependency graph generated by
>>>>>>> make.
>>>>> Do we know for sure that CLOC counts everything in a file or does it 
>>>>> honour the pre-processor settings?
>>>> We certainly don't feed any preprocessor defines to it. I doubt it
>>>> understand C to that level of details anyway.
>>> 
>>> LoC isn't a fantastic metric under any circumstance.
>>> 
>>> Bigger code is definitely better, if the reason it is bigger is because
>>> it is because it is formatted for readability/clarity etc.
>>> 
>>> Attempting to optimise for smaller LoC, other than making entire
>>> functional areas optional, is usually short sighted.
>> 
>> For instance, we could probably decrease the LoC by nearly 20k by
>> changing the style not to give the opening bracket its own line:
>> 
>> $ find . -name '*.c' | xargs grep '^[[:space:]]*{' | wc -l
>> 19896
>> $ find . -name '*.[ch]' | xargs grep '^[[:space:]]*{' | wc -l
>> 21847
> 
> This is hypervisor only BTW (run from xen.git/xen).
> 
> It is a bit mind-boggling to think that there are more open brackets in
> the Xen code base than there is PV-specific code. O_o

As we have the same coding conventions across hypervisor code, that shouldn't 
make a difference

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

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Lars Kurth]

> On 18 Feb 2019, at 12:01, Andrew Cooper  wrote:
> 
> On 18/02/2019 11:57, Wei Liu wrote:
>> On Mon, Feb 18, 2019 at 11:53:15AM +0000, Lars Kurth wrote:
>>> 
>>>> On 18 Feb 2019, at 11:30, George Dunlap  wrote:
>>>> 
>>>> On 2/18/19 11:23 AM, Wei Liu wrote:
>>>>> On Mon, Feb 18, 2019 at 11:17:56AM +, Lars Kurth wrote:
>>>>>> Thank you Wei. It's interesting though that the full vs HVM only is 
>>>>>> almost identical in terms of SLOC's
>>>>>> Lars
>>>>> The cloc target counts the files in the dependency graph generated by
>>>>> make.
>>> Do we know for sure that CLOC counts everything in a file or does it honour 
>>> the pre-processor settings?
>> We certainly don't feed any preprocessor defines to it. I doubt it
>> understand C to that level of details anyway.
> 
> LoC isn't a fantastic metric under any circumstance.
> 
> Bigger code is definitely better, if the reason it is bigger is because
> it is because it is formatted for readability/clarity etc.

I don't disagree. A measure such as Logical Lines Of Code may be more 
appropriate longer term, as it removes the formatting/readability aspect. 

> Attempting to optimise for smaller LoC, other than making entire
> functional areas optional, is usually short sighted.

Agreed. 

We are basically using the SLOC figure as a proxy for "potential cost of safety 
certification" at least for Arm
I was hoping the results were clearer and I could use the figures to illustrate 
the impact of a PV or HVM only build to illustrate the safety impact, but maybe 
I should stay clear of this.

Regards
Lars



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

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Lars Kurth]

> On 18 Feb 2019, at 11:57, Wei Liu  wrote:
> 
> On Mon, Feb 18, 2019 at 11:53:15AM +0000, Lars Kurth wrote:
>> 
>> 
>>> On 18 Feb 2019, at 11:30, George Dunlap  wrote:
>>> 
>>> On 2/18/19 11:23 AM, Wei Liu wrote:
>>>> On Mon, Feb 18, 2019 at 11:17:56AM +, Lars Kurth wrote:
>>>>> Thank you Wei. It's interesting though that the full vs HVM only is 
>>>>> almost identical in terms of SLOC's
>>>>> Lars
>>>> 
>>>> The cloc target counts the files in the dependency graph generated by
>>>> make.
>> 
>> Do we know for sure that CLOC counts everything in a file or does it honour 
>> the pre-processor settings?
> 
> We certainly don't feed any preprocessor defines to it. I doubt it
> understand C to that level of details anyway.

That is interesting, because essentially the CLOC counts provide an upper bound 
instead the real lines of code. So in reality, both the Arm and x86 configs may 
turn out to be lower than we thought
Lars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Lars Kurth]

> On 18 Feb 2019, at 11:30, George Dunlap  wrote:
> 
> On 2/18/19 11:23 AM, Wei Liu wrote:
>> On Mon, Feb 18, 2019 at 11:17:56AM +0000, Lars Kurth wrote:
>>> Thank you Wei. It's interesting though that the full vs HVM only is almost 
>>> identical in terms of SLOC's
>>> Lars
>> 
>> The cloc target counts the files in the dependency graph generated by
>> make.

Do we know for sure that CLOC counts everything in a file or does it honour the 
pre-processor settings?

>> A lot of the files contain both common x86 code and PV only code.
>> So an HVM only build will count some of the PV code.
> 
> Still, what that shows is that there have been nearly 25k likes of code
> identified as "HVM-only", while there have been less than 5k likes of
> code identified as "PV-only".  That's quite a bit more lopsided than I
> was expecting.

I was thinking the same

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

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Lars Kurth]

Thank you Wei. It's interesting though that the full vs HVM only is almost 
identical in terms of SLOC's
Lars

> On 18 Feb 2019, at 11:12, Wei Liu  wrote:
> 
> On Fri, Feb 15, 2019 at 11:08:41AM -0800, Stefano Stabellini wrote:
> [...]
>>> 
>>> Not sure how Stefano got the 157k number. Here are some results from
>>> staging.
>> 
>> See my attached .config
> 
> I see. So these are non-debug builds. I have rerun with your config.
> 
> * HVM only -- Stefano's config
> 
> cloc --list-file=/tmp/tmp.QiL6SOYZeE
> 329 text files.
> 322 unique files.   
>   5 files ignored.
> 
> github.com/AlDanial/cloc v 1.70  T=0.90 s (356.0 files/s, 244295.6 lines/s)
> ---
> Language files  blankcomment   
> code
> ---
> C  303  32750  29021 
> 153649
> Assembly16476710   
> 2320
> ---
> SUM:   319  33226  29731 
> 155969
> ---
> rm /tmp/tmp.QiL6SOYZeE
> 
> * PV only
> 
> cloc --list-file=/tmp/tmp.xa0YAQ1zuO
> 284 text files.
> 281 unique files.   
>   3 files ignored.
> 
> github.com/AlDanial/cloc v 1.70  T=0.52 s (534.8 files/s, 338743.5 lines/s)
> ---
> Language files  blankcomment   
> code
> ---
> C  265  26009  23755 
> 123911
> Assembly15469701   
> 2518
> ---
> SUM:   280  26478  24456 
> 126429
> ---
> rm /tmp/tmp.xa0YAQ1zuO
> 
> 
> * Full build
> 
> cloc --list-file=/tmp/tmp.fZyrQI4xdL
> 348 text files.
> 341 unique files.   
>   5 files ignored.
> 
> github.com/AlDanial/cloc v 1.70  T=0.66 s (514.6 files/s, 343139.6 lines/s)
> ---
> Language files  blankcomment   
> code
> ---
> C  320  33626  29835 
> 157983
> Assembly18513771   
> 2675
> ---
> SUM:   338  34139  30606 
> 160658
> ---
> rm /tmp/tmp.fZyrQI4xdL
> 


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

Re: [Xen-devel] Organising a workshop to solve safety certification related questions (March 25/26, Cambridge, UK, Citrix)

[Lars Kurth]

Hi all,

apologies this took a while. 5 weeks to go to the event!
I created 
https://wiki.xenproject.org/wiki/Developer_Meeting/March2019_-_Safety_Certification
 
<https://wiki.xenproject.org/wiki/Developer_Meeting/March2019_-_Safety_Certification>
 which contains information about the venue, hotels and travel

I also added a registration form: please fill this out if you want to attend 
(even if just remotely): see 
https://wiki.xenproject.org/wiki/Developer_Meeting/March2019_-_Safety_Certification#Registration_.28both_in_person_and_for_remote_participation.29
 
<https://wiki.xenproject.org/wiki/Developer_Meeting/March2019_-_Safety_Certification#Registration_.28both_in_person_and_for_remote_participation.29>

I started to put in some thoughts with regards to the agenda: I will be looking 
for volunteers to help with some of the content. I am working with EPAM on some 
of these, but others are welcome to join.
A scratchpad of ideas which will eventually become an agenda are here: 
https://docs.google.com/document/d/1aKjxDLkEnPZ_0gHgAv4xy9iPv6hVBkIC_wiA0rZzRms/edit
 
<https://docs.google.com/document/d/1aKjxDLkEnPZ_0gHgAv4xy9iPv6hVBkIC_wiA0rZzRms/edit>
 

If you need a visa invitation letter, there is a 3 working day turnaround. 
Please contact me via my Citrix email address as outlined in the Wiki page if 
you need an invitation letter

Best Regards
Lars


> On 4 Feb 2019, at 20:25, Lars Kurth  wrote:
> 
> Hi all,
> 
> from my perspective we have enough momentum to move forward, albeit some 
> prospective attendees are still confirming their travel plans. I can 
> accommodate a maximum if 15, but possibly, a few more. With this in Mind, 
> please start booking flights.
> 
> Location:
> The Citrix office in Milton, just outside of Cambridge
> Citrix Systems:
> 101 Cambridge Science Park Rd, Milton
> Cambridge CB4 0FY
> UK
> 
> Timing
> The event will be held on Monday March 25, and ends on the 26th. I expect 
> days to go from 9:00 to 17:00 and some beverages and food will be provided
> EPAM will host an evening event on the 25th
> 
> Agenda
> With regards the agenda, I will work selected community members on it.
> The agenda is yours, so please prepare and be specific about the technical, 
> community, process and maybe financial problems we have to solve.
> 
> Remote Participation
> I will still need to test this and provide more feedback
> 
> Registration
> I will set up an ad-hoc google doc
> 
> Getting To Cambridge/Accommodation
> London Stansted is the easiest airport to fly to: there is a direct train 
> that goes frequently and take 30-40 minutes
> You may have to use London Heathrow you come from the US, China or Japan. In 
> that case, you can take a fixed rate taxi: see 
> http://www.expressairporttransport.co.uk/Taxi-Cambridge-To-Heathrow-Airport 
> <http://www.expressairporttransport.co.uk/Taxi-Cambridge-To-Heathrow-Airport>
> 
> The key question you will have to decide upon is whether you stay in the town 
> centre, which is stunning, but it may take 30 mins to the Citrix office, or 
> whether you stay close tp the office. I will provide more info in due time
> 
> Regards
> Lars 
> 
>> On 23 Jan 2019, at 10:16, Lars Kurth > <mailto:lars.kurth@gmail.com>> wrote:
>> 
>> Hi all,
>> 
>> it looks as if March 25/26 in Frankfurt or Cambridge is the best option. For 
>> Matt, this would mean that he can only attend the first day, but I believe 
>> this would be OK. Maybe Robin can attend the second day, instead of Matt. 
>> Before we finalise the dates, I will need to secure the meeting space. I 
>> will be able to do this in the next few days and will send an update as soon 
>> as this is done.
>> 
>> Note that we had a few people on this list which have replied to me 
>> privately. Please let me know privately or publicly whether March 25/26 
>> would be suitable for you. We can in parallel work on the agenda.
>>  
>> Best Regards
>> Lars
>> 
>>> On 16 Jan 2019, at 13:09, Lars Kurth >> <mailto:lars.kurth@gmail.com>> wrote:
>>> 
>>> 
>>> 
>>>> On 16 Jan 2019, at 12:16, George Dunlap >>> <mailto:george.dun...@citrix.com>> wrote:
>>>> 
>>>> On 1/8/19 5:59 PM, Lars Kurth wrote:
>>>>> What I need is 
>>>>> - Raise your hands if you are interested 
>>>>> - Let me know of date / location restrictions
>>>>> - We could try and so some of this via video conference: would you be 
>>>>> able to attend if we did open the meeting up to some remote participation
>>>> 
>>>> I'm interested.  All the dates mentioned should w

Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]

[Lars Kurth]

On 15/02/2019, 15:40, "Ian Jackson"  wrote:

Lars Kurth writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 
more messages]"):
> as mentioned earlier, I think we need a legal/admin item for hardware and 
donations. See proposed addition below.
...
> LEGAL
> =

I would prefer not to bake the Linux Foundation address into this
document, nor to have it be the primary repository for legal details,
if that's OK.

How about this:

  LEGAL - XEN PROJECT
  ===

  The Xen Project Test Lab runs public tests, and provides access to its
  hardware to Xen community members so that they can debug the code.
  Accordingly there must not be any restrictions on publication of
  information such as test results, nor any restrictions on access to
  the hardware.  Ie, the Xen Project is not able to agree to any
  nondisclosure agreement (NDA).

  The Xen Project Test Lab does not accept hardware on loan.  We
  purchase it, or, following prior consultation and approval, can accept
  donations.  For donations, the Linux Foundation requires a letter
  confirming some legal details.  The Community Manager will provide
  a list of specific requirements for that `donation form' letter.

This is fine by me
Lars

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

Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages]

[Lars Kurth]

Ian,

as mentioned earlier, I think we need a legal/admin item for hardware and 
donations. See proposed addition below.

On 15/02/2019, 11:57, "Ian Jackson"  wrote:

Ian Jackson writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 
more messages]"):
> So overall, for the reasons I explain, I'm going to commit this
> document (subject to the other comments etc.) *with* the requirement
> that hardware must be supported by Debian (at least, in -backports).

This didn't happen.  THere was considerable further discussion.  The
fact that various kinds of uncertainty meant this document didn't get
committed is now blocking us giving the go-ahead for some new hardware
acquisition:

...

From fae48bd584a0b58934a2df97b6db1d06eacf1724 Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Tue, 30 Oct 2018 16:12:27 +
Subject: [OSSTEST PATCH] README.hardware-acquisition

New document-cum-checklist, for helping with hardware procurement.

Signed-off-by: Ian Jackson 
CC: in...@xenproject.org
CC: George Dunlap 
CC: Stefano Stabellini 
CC: Julien Grall https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Lars Kurth]

> On 15 Feb 2019, at 09:35, George Dunlap  wrote:
> 
>>> 
>>> As use case goes, it would be a good start if you just submit something
>>> you care about.
>> 
>> I mentioned on the call that a good first start could be a kconfig that
>> allows to build an hypervisor binary with only support for PVH and only
>> support for recent Intel machines, with the goal of minimizing the code
>> base to less than 100K LOC.
> 
> I think one thing that might be helpful is a sort of “feature document” for 
> each defconfig we’re looking at creating.  This would include:
> 
> * What the “target use case” for each defconfig would be
> * The end goal in terms of functionality / LoC / whatever
> * The current state, work items yet to do
> * What potential variations there are (i.e., how to enable shadow if you 
> want, or switch from Intel-only to AMD-only)
> 
> I’ve sort of been using docs/design/qemu-deprivilege.md in this way: Saying 
> where we want to go, and moving things from “to do” to “done” as they get 
> implemented.  That would make it easier to have in-progress things in the 
> tree, make it easier for people to collaborate / enhance defconfigs, and also 
> be a starting point for talking about testing and support status.

I think this is a great idea
Regards
Lars


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

Re: [Xen-devel] Enhancing Xen's Kconfig infrastructure to support tailored solutions

[Lars Kurth]

> On 14 Feb 2019, at 18:32, Stefano Stabellini  wrote:
> 
> On Thu, 14 Feb 2019, Jan Beulich wrote:
> On 13.02.19 at 20:11,  wrote:
>>> On Wed, 13 Feb 2019, Wei Liu wrote:
 On Tue, Feb 12, 2019 at 09:34:25PM -0500, Daniel P. Smith wrote:
> Greetings,
> 
> On the 11/14/18 Xen x86 community call a discussion was initiated about
> using Kconfig to build minimized versions of Xen for security, safety
> and other certification requirements. After some offline discussions
> with Xen contributors I realized that a variety of efforts each with
> their own respective goals are underway,
> 
> - nested virtualization
> - mixed criticality architectures
> - reducing trusted componentary
> - combining hardware protection of virtualization with performance and
> ease-of-use of containers
> 
> These efforts use hypervisors in different roles, all which Xen is
> capable of meeting. Today Xen's utility comes at the expense of carrying
> features necessary for one role to be present in another role where it
> is not required, e.g. PV interfaces that may not be essential in an ARM
> mixed criticality deployment.
> 
> The initial focus will be to explore and document the range of possible
> use cases that are of interest to the Xen community. This will be the
> input to a design document that is crafted in conjunction with the Xen
> maintainers, to identify possible approaches to extend the existing
> Kconfig infrastructure to produce tailored instances of Xen.
> 
> If you are interested in participating in this effort, please reply to
> this thread to outline possible use cases, design constraints and other
> considerations for improving Xen's Kconfig infrastructure to support
> tailoring for specific use cases.
> 
 
 My impression from the community call is that you want to provide
 smallish configurations for different use cases.
 
 The Kconfig infrastructure is already able to do what you want as far as
 I can tell.  You can easily feed it a base config file -- see files
 under automation/configs/x86/.  What sort of extension is needed in your
 opinion?
 
 As use case goes, it would be a good start if you just submit something
 you care about.
>>> 
>>> I mentioned on the call that a good first start could be a kconfig that
>>> allows to build an hypervisor binary with only support for PVH and only
>>> support for recent Intel machines, with the goal of minimizing the code
>>> base to less than 100K LOC.
>> 
>> "With only support for PVH" (which really means HVM) we already have.
>> "With only support for recent Intel machines" would require adding new
>> Kconfig options first, to control Intel, AMD, etc separately, and to then
>> further somehow separate "old" from "new" (which may turn out not
>> very easy to do without a lot of #ifdef-ary or other code churn). I'm
>> not aware of something like this existing on Linux either - all I'm aware
>> of there is a means to control what -m option might be passed
>> to the compiler, but without disabling any source code from getting
>> compiled.
> 
> I was thinking along the lines of having options to disable drivers for
> older timers and older interrupt controllers that are not needed on
> recent machines.
> 
> 
>> And then "with only support for recent Intel machines" could also imply
>> HAP-only; disabling shadow code (which also is already possible) will
>> alone save almost 10k LOC (counting .c files only).
> 
> I have just run `make cloc' on x86 with the smallest possible
> configuration (HVM only):
> 
> 
> http://cloc.sourceforge.net  v 1.60  T=0.87 s 
> (370.3 files/s, 255808.4 lines/s)
> ---
> Language files  blankcomment   
> code
> ---
> C  309  33238  29432 
> 157001
> Assembly14466531   
> 2435
> ---
> SUM:   323  33704  29963 
> 159436
> ---
> 
> This is great! The last time I did the count it was above 220K LOC.  We
> should make more noise about this -- it is a major.

@Wei: the binary size data is not that impressive. Would it be possible to do 
the make cloc on HVM, PV and mixed?
I can include this into the PR for 4.12. Sorry for slightly hi-jacking the 
thread.
Lars___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen (both x86 and Arm) Community Call: Feb 13 - 16:00 - 17:00 UTC - Call for Agenda Items

[Lars Kurth]

Apologies: it is 16:00--17:00 as in the URL, etc. - I had forgotten to update 
the UTC time

I would like to add an agenda item about the timing of the meeting under AOB
* Originally the meeting was held 15:00 - 16:00 and Stefano requested it to be 
moved
* However, it turns out that normally key people such as Andrew Cooper can't 
attend. 
* To solve this, we may have to pick another day

Also, I came across Daniel's thread called "Enhancing Xen's Kconfig 
infrastructure to support tailored solutions", which I think would be 
worthwhile discussing at this meeting (or maybe the next). The overall proposal 
makes a lot of sense to me

Best Regards
Lars

> On 13 Feb 2019, at 06:22, Julien Grall  wrote:
> 
> Hi Lars,
> 
> The title says "16:00 - 17:00 UTC" but the text below says "15:00 - 16:00 
> UTC". Can you confirm what time is the meeting?
> 
> Cheers,
> 
> 
> On Mon, 11 Feb 2019, 11:07 Lars Kurth,  <mailto:lars.kurth@gmail.com>> wrote:
> Hi all, 
> 
> we have the community call for February coming up this Wednesday. My sincere 
> apologies, that I have not asked for agenda items last week. A current agenda 
> (primarily a skeleton) is available at  
> https://docs.google.com/document/d/15ZLzQcH794jufDZW1oNYVY2D12CnVqxQ-klFAqkd2bU/edit#heading=h.mz1wjb9vekjn
>  
> <https://docs.google.com/document/d/15ZLzQcH794jufDZW1oNYVY2D12CnVqxQ-klFAqkd2bU/edit#heading=h.mz1wjb9vekjn>
> 
> Please propose topics by either editing the running agenda document at 
> https://docs.google.com/document/d/1Ufv9XcQO0zIAVeFbFCAHAeEIB9Ap4Y4srAm4vI8I01I/edit#
>  
> <https://docs.google.com/document/d/1Ufv9XcQO0zIAVeFbFCAHAeEIB9Ap4Y4srAm4vI8I01I/edit#>
>  or by replying to the mail. Ideally by a few hours before the meeting!
> 
> Best Regards
> Lars
>  
> 
> == Dial-in Information ==
> 
>   ## Future Community Call schedule
>   Feb 13, Mar 12
> 
>   ## Meeting time
>   16:00 - 17:00 UTC
>8:00 -  9:00 EDT (San Francisco)
>   11:00 - 12:00 EDT (New York)
>   16:00 - 17:00 BST (London)
>   17:00 - 18:00 CEST (Berlin)
>   00:00 - 01:00 CST (Beijing)
>   Further International meeting times: 
>   
> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019=2=13=16=0=0=224=24=179=136=37=33
>  
> <https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019=2=13=16=0=0=224=24=179=136=37=33>
>  
> 
>   ## Dial in details
>   Web: https://www.gotomeet.me/larskurth <https://www.gotomeet.me/larskurth>
> 
>   You can also dial in using your phone.
>   Access Code: 906-886-965
> 
>   China (Toll Free): 4008 811084
>   Germany: +49 692 5736 7317
>   Poland (Toll Free): 00 800 1124759
>   United Kingdom: +44 330 221 0088
>   United States: +1 (571) 317-3129
> 
>   More phone numbers
>   Australia: +61 2 9087 3604
>   Austria: +43 7 2081 5427
>   Argentina (Toll Free): 0 800 444 3375
>   Bahrain (Toll Free): 800 81 111
>   Belarus (Toll Free): 8 820 0011 0400
>   Belgium: +32 28 93 7018
>   Brazil (Toll Free): 0 800 047 4906
>   Bulgaria (Toll Free): 00800 120 4417
>   Canada: +1 (647) 497-9391
>   Chile (Toll Free): 800 395 150
>   Colombia (Toll Free): 01 800 518 4483
>Czech Republic (Toll Free): 800 500448
>   Denmark: +45 32 72 03 82
>   Finland: +358 923 17 0568
>   France: +33 170 950 594
>   Greece (Toll Free): 00 800 4414 3838
>   Hong Kong (Toll Free): 30713169
>   Hungary (Toll Free): (06) 80 986 255
>   Iceland (Toll Free): 800 7204
>   India (Toll Free): 18002669272
>   Indonesia (Toll Free): 007 803 020 5375
>   Ireland: +353 15 360 728
>   Israel (Toll Free): 1 809 454 830
>   Italy: +39 0 247 92 13 01
>   Japan (Toll Free): 0 120 663 800
>   Korea, Republic of (Toll Free): 00798 14 207 4914
>   Luxembourg (Toll Free): 800 85158
>   Malaysia (Toll Free): 1 800 81 6854
>   Mexico (Toll Free): 01 800 522 1133
>   Netherlands: +31 207 941 377
>   New Zealand: +64 9 280 6302
>   Norway: +47 21 93 37 51
>   Panama (Toll Free): 00 800 226 7928
>   Peru (Toll Free): 0 800 77023
>   Philippines (Toll Free): 1 800 1110 1661
>   Portugal (Toll Free): 800 819 575
>   Romania (Toll Free): 0 800 410 029
>   Russian Federation (Toll Free): 8 800 100 6203
>   Saudi Arabia (Toll Free): 800 844 3633
>   Singapore (Toll Free): 18007231323
>   South Africa (Toll Free): 0 800 555 447
>   Spain: +34 932 75 2004
>   Sweden: +46 853 527 827
>   Switzerland: +41 225 4599 78
>   Taiwan (Toll Free): 0 800 666 854
>   Thailand (Toll Free): 001 800 011 023
>   Turkey (Toll Free): 00 800 4488 23683
>   Ukraine (Toll Free): 0 800 50 1733
>   United Arab Emirates (Toll Free): 800 044 40439
>   Uruguay (Toll Free): 0004 019 1018

[Xen-devel] Xen (both x86 and Arm) Community Call: Feb 13 - 16:00 - 17:00 UTC - Call for Agenda Items

[Lars Kurth]

Hi all, 

we have the community call for February coming up this Wednesday. My sincere 
apologies, that I have not asked for agenda items last week. A current agenda 
(primarily a skeleton) is available at  
https://docs.google.com/document/d/15ZLzQcH794jufDZW1oNYVY2D12CnVqxQ-klFAqkd2bU/edit#heading=h.mz1wjb9vekjn

Please propose topics by either editing the running agenda document at 
https://docs.google.com/document/d/1Ufv9XcQO0zIAVeFbFCAHAeEIB9Ap4Y4srAm4vI8I01I/edit#
 or by replying to the mail. Ideally by a few hours before the meeting!

Best Regards
Lars
 

== Dial-in Information ==

  ## Future Community Call schedule
  Feb 13, Mar 12

  ## Meeting time
  15:00 - 16:00 UTC
   8:00 -  9:00 EDT (San Francisco)
  11:00 - 12:00 EDT (New York)
  16:00 - 17:00 BST (London)
  17:00 - 18:00 CEST (Berlin)
  00:00 - 01:00 CST (Beijing)
  Further International meeting times: 
  
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019=2=13=16=0=0=224=24=179=136=37=33
 

 

  ## Dial in details
  Web: https://www.gotomeet.me/larskurth 

  You can also dial in using your phone.
  Access Code: 906-886-965

  China (Toll Free): 4008 811084
  Germany: +49 692 5736 7317
  Poland (Toll Free): 00 800 1124759
  United Kingdom: +44 330 221 0088
  United States: +1 (571) 317-3129

  More phone numbers
  Australia: +61 2 9087 3604
  Austria: +43 7 2081 5427
  Argentina (Toll Free): 0 800 444 3375
  Bahrain (Toll Free): 800 81 111
  Belarus (Toll Free): 8 820 0011 0400
  Belgium: +32 28 93 7018
  Brazil (Toll Free): 0 800 047 4906
  Bulgaria (Toll Free): 00800 120 4417
  Canada: +1 (647) 497-9391
  Chile (Toll Free): 800 395 150
  Colombia (Toll Free): 01 800 518 4483
   Czech Republic (Toll Free): 800 500448
  Denmark: +45 32 72 03 82
  Finland: +358 923 17 0568
  France: +33 170 950 594
  Greece (Toll Free): 00 800 4414 3838
  Hong Kong (Toll Free): 30713169
  Hungary (Toll Free): (06) 80 986 255
  Iceland (Toll Free): 800 7204
  India (Toll Free): 18002669272
  Indonesia (Toll Free): 007 803 020 5375
  Ireland: +353 15 360 728
  Israel (Toll Free): 1 809 454 830
  Italy: +39 0 247 92 13 01
  Japan (Toll Free): 0 120 663 800
  Korea, Republic of (Toll Free): 00798 14 207 4914
  Luxembourg (Toll Free): 800 85158
  Malaysia (Toll Free): 1 800 81 6854
  Mexico (Toll Free): 01 800 522 1133
  Netherlands: +31 207 941 377
  New Zealand: +64 9 280 6302
  Norway: +47 21 93 37 51
  Panama (Toll Free): 00 800 226 7928
  Peru (Toll Free): 0 800 77023
  Philippines (Toll Free): 1 800 1110 1661
  Portugal (Toll Free): 800 819 575
  Romania (Toll Free): 0 800 410 029
  Russian Federation (Toll Free): 8 800 100 6203
  Saudi Arabia (Toll Free): 800 844 3633
  Singapore (Toll Free): 18007231323
  South Africa (Toll Free): 0 800 555 447
  Spain: +34 932 75 2004
  Sweden: +46 853 527 827
  Switzerland: +41 225 4599 78
  Taiwan (Toll Free): 0 800 666 854
  Thailand (Toll Free): 001 800 011 023
  Turkey (Toll Free): 00 800 4488 23683
  Ukraine (Toll Free): 0 800 50 1733
  United Arab Emirates (Toll Free): 800 044 40439
  Uruguay (Toll Free): 0004 019 1018
  Viet Nam (Toll Free): 122 80 481

  First GoToMeeting? Let's do a quick system check:
  https://link.gotomeeting.com/system-check 
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Organising a workshop to solve safety certification related questions (March 25/26, Cambridge, UK, Citrix)

[Lars Kurth]

Hi all,

from my perspective we have enough momentum to move forward, albeit some 
prospective attendees are still confirming their travel plans. I can 
accommodate a maximum if 15, but possibly, a few more. With this in Mind, 
please start booking flights.

Location:
The Citrix office in Milton, just outside of Cambridge
Citrix Systems:
101 Cambridge Science Park Rd, Milton
Cambridge CB4 0FY
UK

Timing
The event will be held on Monday March 25, and ends on the 26th. I expect days 
to go from 9:00 to 17:00 and some beverages and food will be provided
EPAM will host an evening event on the 25th

Agenda
With regards the agenda, I will work selected community members on it.
The agenda is yours, so please prepare and be specific about the technical, 
community, process and maybe financial problems we have to solve.

Remote Participation
I will still need to test this and provide more feedback

Registration
I will set up an ad-hoc google doc

Getting To Cambridge/Accommodation
London Stansted is the easiest airport to fly to: there is a direct train that 
goes frequently and take 30-40 minutes
You may have to use London Heathrow you come from the US, China or Japan. In 
that case, you can take a fixed rate taxi: see 
http://www.expressairporttransport.co.uk/Taxi-Cambridge-To-Heathrow-Airport 
<http://www.expressairporttransport.co.uk/Taxi-Cambridge-To-Heathrow-Airport>

The key question you will have to decide upon is whether you stay in the town 
centre, which is stunning, but it may take 30 mins to the Citrix office, or 
whether you stay close tp the office. I will provide more info in due time

Regards
Lars 

> On 23 Jan 2019, at 10:16, Lars Kurth  wrote:
> 
> Hi all,
> 
> it looks as if March 25/26 in Frankfurt or Cambridge is the best option. For 
> Matt, this would mean that he can only attend the first day, but I believe 
> this would be OK. Maybe Robin can attend the second day, instead of Matt. 
> Before we finalise the dates, I will need to secure the meeting space. I will 
> be able to do this in the next few days and will send an update as soon as 
> this is done.
> 
> Note that we had a few people on this list which have replied to me 
> privately. Please let me know privately or publicly whether March 25/26 would 
> be suitable for you. We can in parallel work on the agenda.
>  
> Best Regards
> Lars
> 
>> On 16 Jan 2019, at 13:09, Lars Kurth > <mailto:lars.kurth@gmail.com>> wrote:
>> 
>> 
>> 
>>> On 16 Jan 2019, at 12:16, George Dunlap >> <mailto:george.dun...@citrix.com>> wrote:
>>> 
>>> On 1/8/19 5:59 PM, Lars Kurth wrote:
>>>> What I need is 
>>>> - Raise your hands if you are interested 
>>>> - Let me know of date / location restrictions
>>>> - We could try and so some of this via video conference: would you be able 
>>>> to attend if we did open the meeting up to some remote participation
>>> 
>>> I'm interested.  All the dates mentioned should work for me.
>>> 
>>> -George
>> 
>> Hi all,
>> 
>> to summarise!
>> 
>> We have a good number of people and organisations interested from pretty one 
>> everyone on the list, but it seems the dates won't work for most people. 
>> Location wise: Germany (Frankfurt) and/or UK (Cambridge) work for most, 
>> except for representatives from Dornerworks and Starlab, who would dial in 
>> for some of the meetings 
>> There seems to be a slight bias for Cambridge, as we have most of our 
>> maintainers there. 
>> 
>> Automotive vendors would be happy to align with automotive meetings/events 
>> (even in Japan), but that won't work for the committers as they won't 
>> normally be able to travel. 
>> I also have two organisations which could potentially host in Cambridge and 
>> one in Germany (Frankfurt). But the venue depends partly on the dates. This 
>> tells me, that we should choose either Frankfurt or Cambridge for the event.
>> 
>> In terms of numbers we are roughly looking at 10-12 who could attend 
>> physically, but it could be more
>> 
>> To move forward, I thought I would expend the time horizon a little bit via 
>> the following doodle poll: https://doodle.com/poll/anvfr2hk2t8gy9a8 
>> <https://doodle.com/poll/anvfr2hk2t8gy9a8>
>> Note that you can specify suboptimal dates by clicking twice: also, if you 
>> have any constraints on location, etc. feel free to make use of the 
>> commenting feature.
>> 
>> I will be in the US mid-March and thus excluded these dates. I also excluded 
>> March 28/29: because of Brexit, it is possible that there would be some 
>> travel chaos at least in the UK. 
>> 
>> Regards
>> Lars
>> 
>> 
>> 
> 

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

[Xen-devel] Xen Project Developer and Design Summit 2019: Cfp and Registration Open Now

[Lars Kurth]

Dear Community Members,

starting today, registration officially opens for The Xen Project Developer & 
Design Summit. This year’s Summit, taking place from July 9 through 11 in 
Chicago, will bring together the Xen Project community of developers and power 
users to share ideas, latest developments, and experiences, as well as offer 
opportunities to plan and collaborate on all things Xen Project. You can find 
more information at https://events.linuxfoundation.org/events/xensummit-2019/

If you’d like to present at the Summit and have a topic that you’d like to 
submit, the Call For Proposals is open now and will close April 12, 2019.

Last but not least, we have many opportunities to support the Summit via 
sponsorships. For information regarding registration, speaking opportunities 
and sponsorships, head over the event website and learn more!

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

Re: [Xen-devel] Organising a workshop to solve safety certification related questions

[Lars Kurth]

Hi all,

it looks as if March 25/26 in Frankfurt or Cambridge is the best option. For 
Matt, this would mean that he can only attend the first day, but I believe this 
would be OK. Maybe Robin can attend the second day, instead of Matt. Before we 
finalise the dates, I will need to secure the meeting space. I will be able to 
do this in the next few days and will send an update as soon as this is done.

Note that we had a few people on this list which have replied to me privately. 
Please let me know privately or publicly whether March 25/26 would be suitable 
for you. We can in parallel work on the agenda.
 
Best Regards
Lars

> On 16 Jan 2019, at 13:09, Lars Kurth  wrote:
> 
> 
> 
>> On 16 Jan 2019, at 12:16, George Dunlap > <mailto:george.dun...@citrix.com>> wrote:
>> 
>> On 1/8/19 5:59 PM, Lars Kurth wrote:
>>> What I need is 
>>> - Raise your hands if you are interested 
>>> - Let me know of date / location restrictions
>>> - We could try and so some of this via video conference: would you be able 
>>> to attend if we did open the meeting up to some remote participation
>> 
>> I'm interested.  All the dates mentioned should work for me.
>> 
>> -George
> 
> Hi all,
> 
> to summarise!
> 
> We have a good number of people and organisations interested from pretty one 
> everyone on the list, but it seems the dates won't work for most people. 
> Location wise: Germany (Frankfurt) and/or UK (Cambridge) work for most, 
> except for representatives from Dornerworks and Starlab, who would dial in 
> for some of the meetings 
> There seems to be a slight bias for Cambridge, as we have most of our 
> maintainers there. 
> 
> Automotive vendors would be happy to align with automotive meetings/events 
> (even in Japan), but that won't work for the committers as they won't 
> normally be able to travel. 
> I also have two organisations which could potentially host in Cambridge and 
> one in Germany (Frankfurt). But the venue depends partly on the dates. This 
> tells me, that we should choose either Frankfurt or Cambridge for the event.
> 
> In terms of numbers we are roughly looking at 10-12 who could attend 
> physically, but it could be more
> 
> To move forward, I thought I would expend the time horizon a little bit via 
> the following doodle poll: https://doodle.com/poll/anvfr2hk2t8gy9a8 
> <https://doodle.com/poll/anvfr2hk2t8gy9a8>
> Note that you can specify suboptimal dates by clicking twice: also, if you 
> have any constraints on location, etc. feel free to make use of the 
> commenting feature.
> 
> I will be in the US mid-March and thus excluded these dates. I also excluded 
> March 28/29: because of Brexit, it is possible that there would be some 
> travel chaos at least in the UK. 
> 
> Regards
> Lars
> 
> 
> 

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

Re: [Xen-devel] Preparing for Xen Project GSoC applications : Deadline Feb 6

[Lars Kurth]

Thank you Felipe
I went through and updated the Verified dates and also changed the date of 
insert for "New Platform Support" and "Go Language Support" as these were 
different enough from what was there before
Regards
Lars

> On 16 Jan 2019, at 13:10, Felipe Huici  wrote:
> 
> Hi Lars,
> 
> We've updated the description of the projects related to Unikraft, please let 
> us know if you need anything else from us.
> 
> Thanks,
> 
> -- Felipe
> 
> 
> Dr. Felipe Huici
> Chief Researcher, Systems and Machine Learning Group
> NEC Laboratories Europe GmbH
> Kurfuerstenanlage 36, D-69115 Heidelberg
> Tel.  +49
> (0)6221 4342-241
> Fax:  +49
> (0)6221 4342-155
> 
> e-mail:
> felipe.hu...@neclab.eu
> ====
> Registered at Amtsgericht Mannheim, Germany, HRB728558
> 
> On 15.01.19, 14:33, "Lars Kurth"  wrote:
> 
>Hi all, 
> 
>I will be applying as a mentoring organisation for GSoC again this year: 
> the application deadline is Feb 6 and by then we need to have 
> https://wiki.xenproject.org/wiki/Outreach_Program_Projects in order. Given 
> that we didn't get in last year, there is a 50/50 chance we get in this year.
> 
>Everyone on the CC list has projects listed on 
> https://wiki.xenproject.org/wiki/Outreach_Program_Projects
> 
>Our project list is a little old and stale and that shows: we do need to 
> bring this up-to-date and freshen it up with new projects. I believe that the 
> Mini-OS and Unikraft projects need looking at. And we may have some new 
> sensible projects in the Hypervisor itself. Mindy already agreed to go over 
> the Mirage OS list.
> 
>If you want to withdraw your project: please let me know and I delete it: 
> but let me know WHY you want to withdraw. E.g. is it complete
> 
>@Doug, @Comitters
>Re 
> https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Code_Standards_Checking_using_clang-format
>Given that there has been some work on clang-format by EPAM, which no-one 
> has looked at I am tempted to throw this out or re-do the project. Aka, die a 
> next phase which includes integrating the tool into our workflow. But that 
> may be too hard
>Any views?
> 
>Regards
>Lars
> 


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

Re: [Xen-devel] Organising a workshop to solve safety certification related questions

[Lars Kurth]

> On 16 Jan 2019, at 12:16, George Dunlap  wrote:
> 
> On 1/8/19 5:59 PM, Lars Kurth wrote:
>> What I need is 
>> - Raise your hands if you are interested 
>> - Let me know of date / location restrictions
>> - We could try and so some of this via video conference: would you be able 
>> to attend if we did open the meeting up to some remote participation
> 
> I'm interested.  All the dates mentioned should work for me.
> 
> -George

Hi all,

to summarise!

We have a good number of people and organisations interested from pretty one 
everyone on the list, but it seems the dates won't work for most people. 
Location wise: Germany (Frankfurt) and/or UK (Cambridge) work for most, except 
for representatives from Dornerworks and Starlab, who would dial in for some of 
the meetings 
There seems to be a slight bias for Cambridge, as we have most of our 
maintainers there. 

Automotive vendors would be happy to align with automotive meetings/events 
(even in Japan), but that won't work for the committers as they won't normally 
be able to travel. 
I also have two organisations which could potentially host in Cambridge and one 
in Germany (Frankfurt). But the venue depends partly on the dates. This tells 
me, that we should choose either Frankfurt or Cambridge for the event.

In terms of numbers we are roughly looking at 10-12 who could attend 
physically, but it could be more

To move forward, I thought I would expend the time horizon a little bit via the 
following doodle poll: https://doodle.com/poll/anvfr2hk2t8gy9a8 
<https://doodle.com/poll/anvfr2hk2t8gy9a8>
Note that you can specify suboptimal dates by clicking twice: also, if you have 
any constraints on location, etc. feel free to make use of the commenting 
feature.

I will be in the US mid-March and thus excluded these dates. I also excluded 
March 28/29: because of Brexit, it is possible that there would be some travel 
chaos at least in the UK. 

Regards
Lars



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

Re: [Xen-devel] [PATCH 2/2] docs: Fix links in html generation of man pages

[Lars Kurth]

> On 15 Jan 2019, at 17:07, Ian Jackson  wrote:
> 
> Anthony PERARD writes ("Re: [PATCH 2/2] docs: Fix links in html generation of 
> man pages"):

snip

> Anyway, this patch of yours is a big improvement, so:
> 
> Acked-by: Ian Jackson 
> 
> I think linkifying that one missing link is a `nice to have' and can
> be done now or later as yo like.
> 
> Ian.


Indeed it is. Thank you for fixing this
Regards
Lars


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

[Xen-devel] Preparing for Xen Project GSoC applications : Deadline Feb 6

[Lars Kurth]

Hi all, 

I will be applying as a mentoring organisation for GSoC again this year: the 
application deadline is Feb 6 and by then we need to have 
https://wiki.xenproject.org/wiki/Outreach_Program_Projects in order. Given that 
we didn't get in last year, there is a 50/50 chance we get in this year.

Everyone on the CC list has projects listed on 
https://wiki.xenproject.org/wiki/Outreach_Program_Projects

Our project list is a little old and stale and that shows: we do need to bring 
this up-to-date and freshen it up with new projects. I believe that the Mini-OS 
and Unikraft projects need looking at. And we may have some new sensible 
projects in the Hypervisor itself. Mindy already agreed to go over the Mirage 
OS list.

If you want to withdraw your project: please let me know and I delete it: but 
let me know WHY you want to withdraw. E.g. is it complete

@Doug, @Comitters
Re 
https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Code_Standards_Checking_using_clang-format
Given that there has been some work on clang-format by EPAM, which no-one has 
looked at I am tempted to throw this out or re-do the project. Aka, die a next 
phase which includes integrating the tool into our workflow. But that may be 
too hard
Any views?

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

Re: [Xen-devel] [PATCH v3 04/15] argo: init, destroy and soft-reset, with enable command line opt

[Lars Kurth]

Adding Juergen,

to make sure he is aware of the discussion, as this is an excellent summary of 
the status of this series.

> On 14 Jan 2019, at 14:46, Wei Liu  wrote:
> 
> Hi all
> 
> The locking scheme seems to be remaining sticking point. The rest are
> mostly cosmetic issues (FAOD, they still need to be addressed).  Frankly
> I don't think there is enough time to address all the technical details,
> but let me sum up each side's position and see if we can reach an
> amicable solution.

snip

> To unblock this, how about we make Christopher maintainer of Argo? He
> and OpenXT will be on the hook for further improvement. And I believe it
> would be in their best interest to keep Argo bug-free and eventually
> make it become supported.
> 
> So:
> 
> 1. Make sure Argo is self-contained -- this requires careful review for
>   interaction between Argo and other parts of the hypervisor.
> 2. Argo is going to be experimental and off-by-default -- this is the
>   default status for new feature anyway.
> 3. Make Christopher maintainer of Argo -- this would be a natural thing
>   to do anyway.
> 
> Does this work for everyone?

I think this is a good way forward. Thank you Wei for putting this mail 
together.

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

Re: [Xen-devel] Xen 4.12 Development Update

[Lars Kurth]

Hi Juergen,

> On 14 Jan 2019, at 10:13, Juergen Gross  wrote:
> 
> This email only tracks big items for xen.git tree. Please reply for items you
> would like to see in 4.12 so that people have an idea what is going on and
> prioritise accordingly.
> 
> You're welcome to provide description and use cases of the feature you're
> working on.
> 
> = Timeline =
> 
> We now adopt a fixed cut-off date scheme. We will release about every 8 
> months.
> The upcoming 4.12 timeline are as followed:
> 
> * Last posting date: December 14th, 2018
>  Last posting date for patches touching ARM code: December 1st, 2018
> * Hard code freeze: January 11th, 2019
>  Hard code freeze for patches touching ARM code: December 21st, 2018
> --> we are here
> * RC1: TBD
> * Release: March 7th, 2019
> 
> Note that we don't have freeze exception scheme anymore. All patches
> that wish to go into 4.12 must be posted initially no later than the
> last posting date and finally no later than the hard code freeze. All
> patches posted after that date will be automatically queued into next
> release.
> 
> RCs will be arranged immediately after freeze.

We should start planning on a Test Day schedule.

> We recently introduced a jira instance to track all the tasks (not only big)
> for the project. See: https://xenproject.atlassian.net/projects/XEN/issues.
> 
> Some of the tasks tracked by this e-mail also have a corresponding jira task
> referred by XEN-N.
> 
> I have started to include the version number of series associated to each
> feature. Can each owner send an update on the version number if the series
> was posted upstream?
> 
> = Projects =
> 
> == Hypervisor == 
> 
> *  Improvements to domain creation (v2)
>  -  Andrew Cooper
> 
> *  Argo (inter-VM communication) (v3)
>  -  Christopher Clark
> 
> *  Core aware scheduling (RFC v1)
>  -  Dario Faggioli
> 
> *  Core aware scheduling for credit2 (RFC v1)
>  -  Dario Faggioli
> 
> === x86 === 
> 
> *  hypervisor x86 instruction emulator additions for AVX512 (v7)
>  -  Jan Beulich
> 
> *  qemu deprivilege (v4)
>  -  George Dunlap
> 
> *  Fixes to #DB injection
>  -  Andrew Cooper
> 
> *  CPUID/MSR Xen/toolstack improvements
>  -  Andrew Cooper
> 
> *  Improvements to domain_crash()
>  -  Andrew Cooper
> 
> === ARM === 
> 
> == Completed == 
> 
> *  guest resource mapping
>  -  Paul Durrant
> 
> *  PV-only hypervisor
>  -  Wei Liu
> 
> *  HVM-only hypervisor
>  -  Wei Liu
> 
> *  Make credit2 scheduler the default
>  -  George Dunlap
> 
> *  Grub2: Support PVH guest boot
>  -  Juergen Gross
> 
> *  Fix VGA logdirty related display freezes with altp2m
>  -  Razvan Cojocaru
> 
> *  dom0less (boot multiple domains from device tree)
>  -  Stefano Stabellini
> 
> *  Implement Set/Way operations
>  -  Julien Grall

@Stefano:
Didn't the ARM KCONFIG stuff go in *after* 4.11? If so, this should probably be 
added. 
Can't recall the series name

Also, I think the Aggios changes went in after 4.11 was released also.
The series was "xen/arm64: Suspend preconditions and CPU hotplug fixes"

@ALL: also, for any major new features and/or enablers, we should look at the 
docs and make sure they are in place and up-to-date, that SUPPORT.md is updated 
and that any worthy/big enough features are listed. Also, if you contributed a 
larger series/feature and it is not on this list, please let us know.  

Thank you to everyone contributing to the project

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

Re: [Xen-devel] [BUG] docs: our man page generation uses http://man.he.net/ by default which causes broken links. It should be changed to point to a relative path

[Lars Kurth]

Ping!
Adding Ian Jackson specifically - we should really fix this for 4.12
Regards
Lars

> On 2 Aug 2018, at 12:24, Lars Kurth  wrote:
> 
> Hi all,
> 
> most of our man pages on pretty much all releases from 4.2 contain broken 
> links. 
> 
> For example:
> In https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html the source 
> contains:
> 
> "For more details, see L." 
> Maps onto http://man.he.net/man7/xl-numa-placement  (does not exist)
> 
> “See L<http://man.he.net/man5/xl-disk-configuration> for more details.” 
> Maps onto http://man.he.net/man5/xl-disk-configuration (does not exist)
> 
> Etc.
> 
> There seem to be two issues:
> * The root path http://man.he.net, which is incorrect
> * The resolution of filenames to man/: should be man/..html
> 
> Probably we need to feed some arguments to probably we need to feed some 
> arguments 
> to pod2html in order to generate the correct urls. See  
> https://perldoc.perl.org/pod2html.html 
> (maybe we need we need –htmldir). For our docs build, this should probably go 
> to 
> https://xenbits.xen.org/docs/unstable/man/ while for local installs to 
> ${prefix}/share/doc/xen/html/man or something like it.
> 
> I had a look to see whether I can fix this, but that seems a little too 
> complex for me
> 
> Regards
> Lars
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel


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

[Xen-devel] Save the dates: Xen Project Developer Summit 2019 - July 9 -11, Chicago, IL, USA

[Lars Kurth]

Hi all,
just a quick note to let you know that the next developer summit will be held 
in the US (in Chicago) from July 9-11. The event website including the CfP 
should be up in the next 2-3 weeks
Best Regards
Lars 
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen (both x86 and Arm) Community Call: Jan 9 - 16:00 - 17:00 UTC - Call for Agenda Items

[Lars Kurth]

Quick note: the meeting is in 15 minutes - the agenda is at 
https://docs.google.com/document/d/1Ufv9XcQO0zIAVeFbFCAHAeEIB9Ap4Y4srAm4vI8I01I/edit
 
<https://docs.google.com/document/d/1Ufv9XcQO0zIAVeFbFCAHAeEIB9Ap4Y4srAm4vI8I01I/edit>
 

> On 8 Jan 2019, at 14:34, Lars Kurth  wrote:
> 
> Hi all,
> 
> I noticed that I hadn't updated all the times in the meeting invite block.
> 
>> 
>> == Dial-in Information ==
>> 
>>   ## Future Community Call schedule
>>   Jan 9, Feb 13, Mar 12
>> 
>>   ## Meeting time
>>   15:00 - 16:00 UTC
> 
> This is wrong and should read 16:00 - 17:00
> 
>>8:00 -  9:00 EDT (San Francisco)
>>   11:00 - 12:00 EDT (New York)
>>   16:00 - 17:00 BST (London)
>>   17:00 - 18:00 CEST (Berlin)
>>   00:00 - 01:00 CST (Beijing)
>>   Further International meeting times: 
>>   
>> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019=1=7=16=0=0=224=24=179=136=37=33
>>  
>> <https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019=1=7=16=0=0=224=24=179=136=37=33>
> 
> Regards
> Lars
> 

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

[Xen-devel] Organising a workshop to solve safety certification related questions

[Lars Kurth]

Hi all,

just before XMas Stefano (Xilinx), Alex (EPAM), Artem (EPAM), Matt (Arm), 
Guilio (Xilinx) and Munakata San (Renesas) and me had a quick call see whether 
from a Xen Project community perspective, it would be possible to make 
significant progress towards making more easily Xen Safety certifiable in 2019. 
From a technical viewpoint, I believe we are at a stage where it should be 
possible for a vendor to take a snapshot of upstream Xen and build a safety 
certifiable product on top of it (e.g. taking route 3S to achieve 26262 ASIL 
B). However, the cost of doing so today, would make it likely that vendors who 
tried to do this not share the effort and essentially lead to safety certified 
productized forks of Xen. This is undesirable for both the Xen Project and also 
for the vendors who were in the room, which is a good starting point. There are 
also a number of unresolved technical, business and process issues to make this 
happen.

To make progress on this questions, we discussed the possibility to get a few 
key people from the embedded/automotive Xen community into a room with some 
long established maintainers/committers and agree what is possible. The idea 
was for EPAM (with my help) to organise a 1-2 day workshop alongside an 
automotive event. 

Candidates discussed were
* Embedded World; Nuremberg 26-28 of Feb in Nuremberg, Germany 
* AGL all member meeting; March 5-6 in Tokyo 
* Autoshow in Detroit in April

For this to work, we would need at least 2-3 of our committers to participate 
and at least someone who is maintaining common Hypervisor code. This in my view 
disqualifies holding such a meeting outside of Europe, as most of the Xen 
maintainers are not likely to get the travel approved. We could also try and 
open some of the meetings on-line, but having a core of people in a room would 
be much more productive.

However, if we were to hold the meetings in Europe that may be easier. Options 
on the table would be:
* 28 Feb / 1 March in Frankfurt
* 21/22 Feb in Frankfurt
* Citrix could also host meetings on March 1 and Feb 22nd in Cambridge, but 
there is not enough space on both Thursday's
* Are there any other vendors who would be willing to host the meeting?

Cambridge has the advantage that most of our active committers are local (with 
the exception of Jan and Stefano). For both locations, we would have to 
restrict the meeting to 12 people.

With this in mind, I was wondering who on the committers@ list could 
participate for at least some of the meeting and if so, in which location. 
Secondly, I would like to know who else would be interesting in attending. We 
would also invite a specialist from TUV or another test institute.

What I need is 
- Raise your hands if you are interested 
- Let me know of date / location restrictions
- We could try and so some of this via video conference: would you be able to 
attend if we did open the meeting up to some remote participation

Do this either privately by replying to this mail or publicly by replying to 
the thread

In terms of agenda, we would need to discuss
1) Big picture - get everyone on one page
2) MISRA (as a placeholder for coding standard compliance)
There has not been enough progress on this in my view in 2018 and questions 
that were raised at the summit remain unresolved
3) Process and Technical implications
This would cover topics such as creating and maintaining certification artefacts
Who does this interact with the contribution workflow - aka are there any 
potential issues
Does the current master/staging approach work - if not, would we be open for a 
group of vendors to maintain official base branches for certifiable Xen based 
products
Etc.
4) Business Model
Probably a little too early for that, but I will leave this as an option
If we do get a specialist from a test institute to attend, that may be a 
worthwhile discussion to have
5) We should also discuss related issues which have been stalling, such as 
testing

Best Regards
Lars






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

Re: [Xen-devel] Xen (both x86 and Arm) Community Call: Jan 9 - 16:00 - 17:00 UTC - Call for Agenda Items

[Lars Kurth]

Hi all,

I noticed that I hadn't updated all the times in the meeting invite block.

> 
> == Dial-in Information ==
> 
>   ## Future Community Call schedule
>   Jan 9, Feb 13, Mar 12
> 
>   ## Meeting time
>   15:00 - 16:00 UTC

This is wrong and should read 16:00 - 17:00

>8:00 -  9:00 EDT (San Francisco)
>   11:00 - 12:00 EDT (New York)
>   16:00 - 17:00 BST (London)
>   17:00 - 18:00 CEST (Berlin)
>   00:00 - 01:00 CST (Beijing)
>   Further International meeting times: 
>   
> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019=1=7=16=0=0=224=24=179=136=37=33
>  
> 

Regards
Lars

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

Re: [Xen-devel] Xen (both x86 and Arm) Community Call: Jan 9 - 16:00 - 17:00 UTC - Call for Agenda Items

[Lars Kurth]

Did anyone have any agenda items *NOT* related to 4.12? 
As an aside: I added the following to the agenda
* 4.12 what headline features made it
* Face 2 face to discuss a plan and implications for safety certification 
(separate e-mail will follow today)

Regards
Lars

> On 7 Jan 2019, at 18:33, Stefano Stabellini  wrote:
> 
> On Mon, 7 Jan 2019, Juergen Gross wrote:
>> On 03/01/2019 15:28, Lars Kurth wrote:
>>> Hi all,
>>> 
>>> based on Stefano's and Julien's suggestion that it may make sense to merge 
>>> the x86 and arm calls, I am willing to try. It also makes sense this time 
>>> in particular because we are approaching freeze time.
>>> 
>>> 
>>> As per request the meeting is 1 hour later than normal. Also, because there 
>>> were NO attendees from China on the last 3 calls. For Chinese attendees: if 
>>> you plan to attend, please confirm you are attending and we can discuss 
>>> moving the meeting to earlier.
>>> 
>>> @Juergen, @Jan: we can discuss the timing of future meetings going forward 
>>> if 17:00-18:00 is a problem for you.
>>> 
>>> Please propose topics by either editing the running agenda document at 
>>> https://docs.google.com/document/d/1Ufv9XcQO0zIAVeFbFCAHAeEIB9Ap4Y4srAm4vI8I01I/edit#
>>>  or by replying to the mail. Ideally by next Tuesday!
>> 
>> I'd like to discuss status of the current pending patch series:
>> 
>> Series   Author Status
>> Per-cpu tasklet  Konrad Rzeszutek Wilk  ->4.13?
>> Improvements to domain creation (v2) Andrew Cooper  ?
>> Argo (inter-VM communication) (v3)   Christopher Clark  ?
>> Core aware sched (RFC v1)Dario Faggioli ->4.13?
>> Core aware sched credit2 (RFC v1)Dario Faggioli ->4.13?
>> x86 instr emulator add AVX512 (v7)   Jan Beulichfinished?
>> HVM guest CPU topology support (RFC) Chao Gao   ->4.13?
>> Intel Trace virt. enabling (v1)  Luwei Kang ->4.13?
>> Linux stub domains (RFC v2)  Marek Marczykowski-G.  ->4.13?
>> qemu deprivilege (v4)George Dunlap  finished?
>> Improve late microcode loading (v4)  Chao Gao   ?
>> Fixes to #DB injection   Andrew Cooper  ->4.13?
>> CPUID/MSR Xen/toolstack improvements Andrew Cooper  ->4.13?
>> Improvements to domain_crash()   Andrew Cooper  ->4.13?
>> Fix VGA logdirty with altp2m (v11)   Razvan Cojocaru?
>> dom0less (v4)Stefano Stabellini ?
> 
> Dom0less is already in. "Dom0less device assignment" missed the window
> by only a couple of days (I forgot to send it in time -- too bad.)
> 
> I have another outstanding series for 4.12: "misc safety certification
> fixes".
> 
> 
>> Implement Set/Way operations (RFC)   Julien Grall   ?
> 
> Also already committed
> 
> 
>> TEE mediator support in XEN (v2) Volodymyr Babchuk  ?

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

Re: [Xen-devel] Xen (both x86 and Arm) Community Call: Jan 9 - 16:00 - 17:00 UTC - Call for Agenda Items

[Lars Kurth]

Hi all,

as we are close to the 4.11 release, I think this means we would focus on 
release related stuff primarily. Moving the meeting a week later is probably 
not going to help re release related items.

I think it is OK if some people cannot attend the Jan meeting: We could move 
forward the Feb meeting by a week (e.g. to say the 1st Wed of Feb) and reset 
the meeting cadence. That way we can start discussing more forward looking 
items again a little earlier.

Regards
Lars

> On 3 Jan 2019, at 17:41, Artem Mygaiev  wrote:
> 
> Both myself and Alex will be at CES at this time so we won't be able to join.
> 
>  -- Artem
> From: Stefano Stabellini  <mailto:sstabell...@kernel.org>>
> Sent: Thursday, January 3, 2019 7:17:02 PM
> To: Lars Kurth
> Cc: xen-devel; committ...@xenproject.org <mailto:committ...@xenproject.org>; 
> Tamas K Lengyel; intel-...@intel.com <mailto:intel-...@intel.com>; 
> daniel.ki...@oracle.com <mailto:daniel.ki...@oracle.com>; Roger Pau Monne; 
> Christopher Clark; Rich Persaud; Brian Woods; Stefano Stabellini; Julien 
> Grall; Juergen Gross; Paul Durrant; Ji, John; Natarajan, Janakarajan; 
> dpsm...@apertussolutions.com <mailto:dpsm...@apertussolutions.com>; 
> edgar.igles...@xilinx.com <mailto:edgar.igles...@xilinx.com>; 
> davorin.mi...@aggios.com <mailto:davorin.mi...@aggios.com>; 
> robin.randh...@arm.com <mailto:robin.randh...@arm.com>; Artem Mygaiev; 
> mirela.simono...@aggios.com <mailto:mirela.simono...@aggios.com>; Stewart 
> Hildebrand; anastassios.na...@onapp.com <mailto:anastassios.na...@onapp.com>; 
> vfac...@de.adit-jv.com <mailto:vfac...@de.adit-jv.com>; Volodymyr Babchuk; 
> Matt Spencer; Jarvis Roach
> Subject: Re: Xen (both x86 and Arm) Community Call: Jan 9 - 16:00 - 17:00 UTC 
> - Call for Agenda Items
>  
> For all the folks used to attending the ARM community calls, I'll be on
> this call. Julien, won't be able to join this time, but he will join in
> the future.
> 
> On Thu, 3 Jan 2019, Lars Kurth wrote:
> > Hi all,
> > 
> > based on Stefano's and Julien's suggestion that it may make sense to merge 
> > the x86 and arm calls, I am willing to try. It also makes sense this time 
> > in particular because we are approaching freeze time.
> > 
> > 
> > As per request the meeting is 1 hour later than normal. Also, because there 
> > were NO attendees from China on the last 3 calls. For Chinese attendees: if 
> > you plan to attend, please confirm you are attending and we can discuss 
> > moving the meeting to earlier.
> > 
> > @Juergen, @Jan: we can discuss the timing of future meetings going forward 
> > if 17:00-18:00 is a problem for you.
> > 
> > Please propose topics by either editing the running agenda document at 
> > https://docs.google.com/document/d/1Ufv9XcQO0zIAVeFbFCAHAeEIB9Ap4Y4srAm4vI8I01I/edit#
> >  
> > <https://docs.google.com/document/d/1Ufv9XcQO0zIAVeFbFCAHAeEIB9Ap4Y4srAm4vI8I01I/edit#>
> >  or by replying to the mail. Ideally by next Tuesday!
> > 
> > 
> > == AOB ==
> > 
> > == Dial-in Information ==
> > 
> >## Future Community Call schedule
> >Jan 9, Feb 13, Mar 12
> > 
> >## Meeting time
> >15:00 - 16:00 UTC
> > 8:00 -  9:00 EDT (San Francisco)
> >11:00 - 12:00 EDT (New York)
> >16:00 - 17:00 BST (London)
> >17:00 - 18:00 CEST (Berlin)
> >00:00 - 01:00 CST (Beijing)
> >Further International meeting times: 
> >
> > https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019=1=7=16=0=0=224=24=179=136=37=33
> >  
> > <https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019=1=7=16=0=0=224=24=179=136=37=33>
> > 
> >## Dial in details
> >Web: https://www.gotomeet.me/larskurth 
> > <https://www.gotomeet.me/larskurth>
> > 
> >You can also dial in using your phone.
> >Access Code: 906-886-965
> > 
> >China (Toll Free): 4008 811084
> >Germany: +49 692 5736 7317
> >Poland (Toll Free): 00 800 1124759
> >United Kingdom: +44 330 221 0088
> >United States: +1 (571) 317-3129
> > 
> >More phone numbers
> >Australia: +61 2 9087 3604
> >Austria: +43 7 2081 5427
> >Argentina (Toll Free): 0 800 444 3375
> >Bahrain (Toll Free): 800 81 111
> >Belarus (Toll Free): 8 820 0011 0400
> >Belgium: +32 28 93 7018
> >Brazil (Toll Free): 0 800 047 4906
> >Bulgaria (Toll Free): 00800 120 4417
> >Canada: +1 (647) 497-9391
> >Chile (Toll Free): 800 395 150
> >   

[Xen-devel] Xen (both x86 and Arm) Community Call: Jan 9 - 16:00 - 17:00 UTC - Call for Agenda Items

[Lars Kurth]

Hi all,

based on Stefano's and Julien's suggestion that it may make sense to merge the 
x86 and arm calls, I am willing to try. It also makes sense this time in 
particular because we are approaching freeze time.


As per request the meeting is 1 hour later than normal. Also, because there 
were NO attendees from China on the last 3 calls. For Chinese attendees: if you 
plan to attend, please confirm you are attending and we can discuss moving the 
meeting to earlier.

@Juergen, @Jan: we can discuss the timing of future meetings going forward if 
17:00-18:00 is a problem for you.

Please propose topics by either editing the running agenda document at 
https://docs.google.com/document/d/1Ufv9XcQO0zIAVeFbFCAHAeEIB9Ap4Y4srAm4vI8I01I/edit#
 or by replying to the mail. Ideally by next Tuesday!


== AOB ==

== Dial-in Information ==

   ## Future Community Call schedule
   Jan 9, Feb 13, Mar 12

   ## Meeting time
   15:00 - 16:00 UTC
8:00 -  9:00 EDT (San Francisco)
   11:00 - 12:00 EDT (New York)
   16:00 - 17:00 BST (London)
   17:00 - 18:00 CEST (Berlin)
   00:00 - 01:00 CST (Beijing)
   Further International meeting times: 
   
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019=1=7=16=0=0=224=24=179=136=37=33

   ## Dial in details
   Web: https://www.gotomeet.me/larskurth

   You can also dial in using your phone.
   Access Code: 906-886-965

   China (Toll Free): 4008 811084
   Germany: +49 692 5736 7317
   Poland (Toll Free): 00 800 1124759
   United Kingdom: +44 330 221 0088
   United States: +1 (571) 317-3129

   More phone numbers
   Australia: +61 2 9087 3604
   Austria: +43 7 2081 5427
   Argentina (Toll Free): 0 800 444 3375
   Bahrain (Toll Free): 800 81 111
   Belarus (Toll Free): 8 820 0011 0400
   Belgium: +32 28 93 7018
   Brazil (Toll Free): 0 800 047 4906
   Bulgaria (Toll Free): 00800 120 4417
   Canada: +1 (647) 497-9391
   Chile (Toll Free): 800 395 150
   Colombia (Toll Free): 01 800 518 4483
Czech Republic (Toll Free): 800 500448
   Denmark: +45 32 72 03 82
   Finland: +358 923 17 0568
   France: +33 170 950 594
   Greece (Toll Free): 00 800 4414 3838
   Hong Kong (Toll Free): 30713169
   Hungary (Toll Free): (06) 80 986 255
   Iceland (Toll Free): 800 7204
   India (Toll Free): 18002669272
   Indonesia (Toll Free): 007 803 020 5375
   Ireland: +353 15 360 728
   Israel (Toll Free): 1 809 454 830
   Italy: +39 0 247 92 13 01
   Japan (Toll Free): 0 120 663 800
   Korea, Republic of (Toll Free): 00798 14 207 4914
   Luxembourg (Toll Free): 800 85158
   Malaysia (Toll Free): 1 800 81 6854
   Mexico (Toll Free): 01 800 522 1133
   Netherlands: +31 207 941 377
   New Zealand: +64 9 280 6302
   Norway: +47 21 93 37 51
   Panama (Toll Free): 00 800 226 7928
   Peru (Toll Free): 0 800 77023
   Philippines (Toll Free): 1 800 1110 1661
   Portugal (Toll Free): 800 819 575
   Romania (Toll Free): 0 800 410 029
   Russian Federation (Toll Free): 8 800 100 6203
   Saudi Arabia (Toll Free): 800 844 3633
   Singapore (Toll Free): 18007231323
   South Africa (Toll Free): 0 800 555 447
   Spain: +34 932 75 2004
   Sweden: +46 853 527 827
   Switzerland: +41 225 4599 78
   Taiwan (Toll Free): 0 800 666 854
   Thailand (Toll Free): 001 800 011 023
   Turkey (Toll Free): 00 800 4488 23683
   Ukraine (Toll Free): 0 800 50 1733
   United Arab Emirates (Toll Free): 800 044 40439
   Uruguay (Toll Free): 0004 019 1018
   Viet Nam (Toll Free): 122 80 481

   First GoToMeeting? Let's do a quick system check:
   https://link.gotomeeting.com/system-check

Best Regards
Lars

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

Re: [Xen-devel] [PATCH v2 04/18] argo: init, destroy and soft-reset, with enable command line opt

[Lars Kurth]

On 20/12/2018, 06:39, "Christopher Clark"  
wrote:

The software license on the public header is the BSD license, standard
procedure for the public Xen headers.

Thank you for posting the patch. I think it is important to note that these 
headers were originally posted under a GPL license at 
[1] https://lists.xenproject.org/archives/html/xen-devel/2013-05/msg02710.html 

The following ACK is to confirm that only people being employees of Citrix 
contributed to the header files in the series posted 
at [1] and that thus the copyright of the files in question is fully owned by 
Citrix. The ACK also confirms that Citrix is happy for 
the header files to be published under a BSD license in this series (which is 
based on [1]).

Acked-by: Lars Kurth 

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

Re: [Xen-devel] [PATCH] CONTRIBUTING: Clarifications on how to handle license deviations

[Lars Kurth]

Thank you Wei,

On 06/12/2018, 14:09, "Wei Liu"  wrote:

On Mon, Nov 19, 2018 at 06:05:10PM +0000, Lars Kurth wrote:
> This patch makes a few clarifications which were discussed on
> IRC recently. 
> 
> Specifically: 
> - Highlight the principle that license deviations
>   should be brought to the attention of maintainers 
> - Add a requirement for GPLv2 compatibility 
> - Restructure the document toghlight  use-cases for  

to highlight

>   "New components" and "Importing code" clearer 
> - Add conventions and instructions for "New files"
> 
> Signed-off-by: Lars Kurth 
> ---
>  CONTRIBUTING | 27 +++
>  1 file changed, 23 insertions(+), 4 deletions(-)
> 
> diff --git a/CONTRIBUTING b/CONTRIBUTING
> index cfee8f1567..63050e9141 100644
> --- a/CONTRIBUTING
> +++ b/CONTRIBUTING
> @@ -19,6 +19,19 @@ Most notably:
>   - tools/xl   : LGPL v2.1
>   - xen/include/public : MIT license
>  
> +The COMMON COPYRIGHT NOTICES section of this document contains
> +sample copyright notices for the most common licenses used within
> +this repository.
> +
> +When creating new components, new files, or importing code please follow
> +the conventions outlined below. As a general rule, whenever code using a
> +license other than GPLv2 is introduced, attention must be drawn to the
> +difference, such that maibtainers can make an informed decision about the

maintainers

Overall this patch looks good to me.

Anyone else any views, before I re-roll the patch
Lars

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

Re: [Xen-devel] [Minios-devel] FOSDEM Devrooms (CfP deadlines for relevant DevRooms from Dec 1-10) and Xen Project Stand

[Lars Kurth]

FYI: no Xen Project booth at FOSDEM this year

> Begin forwarded message:
> 
> From: Alasdair G Kergon 
> Subject: FOSDEM 2019 stand applications
> Date: 22 November 2018 at 14:58:21 GMT-6
> To: FOSDEM 2019 Stands Team 
> 
> You are receiving this message (bcc) because your email address was
> listed on an application for a stand at FOSDEM 2019.
> 
> Thank you all for your patience, but on behalf of the FOSDEM Stands
> Team I regret to inform you that your application has not been
> successful.
> 
> I hope you are not too disappointed and will still join us at FOSDEM
> 2019 in another capacity.  As an alternative, there is just still time
> to apply for a lightning talk about your project(s).
> 
> Alasdair



> On 21 Nov 2018, at 08:11, Lars Kurth  wrote:
> 
> Just a quick reminder that the CfP deadline is coming up
> Note that FOSDEM has not yet announced the stands
> Lars
>  
> From: Lars Kurth 
> Date: Monday, 29 October 2018 at 17:01
> To: xen-devel , 
> "mirageos-de...@lists.xenproject.org" , 
> "minios-de...@lists.xenproject.org" , 
> "mirageos-de...@lists.xenproject.org" 
> Cc: Zibby Keaton , Olivier Lambert 
> , "daniel.ki...@oracle.com" 
> , "committ...@xenproject.org" 
> 
> Subject: FOSDEM Devrooms (CfP deadlines for relevant DevRooms from Dec 1-10) 
> and Xen Project Stand
>  
> Hi all,
>  
> I just submitted a Xen Project stand submission and if everything goes ok, we 
> will be having a booth again like the last 5 years
> Accepted stands should be announced by November 11
>  
> If you already know you are going, please add yourself to 
> https://docs.google.com/spreadsheets/d/1uk79a_iEeSosTWG7OgZvhW2nZMO-cJHiDz0BNb0dN60/edit?usp=sharing
>  
> <https://docs.google.com/spreadsheets/d/1uk79a_iEeSosTWG7OgZvhW2nZMO-cJHiDz0BNb0dN60/edit?usp=sharing>
>  and let me know if you are willing to help out. Also, if you want to give 
> swag out, give demos, etc. please let me know by adding what you want to in 
> the last column
>  
> Also, a number of CfP’s may be relevant: see table below
>  
> Devroom
> CfP Deadline
> CfP
> BSD @ Sat, Feb 2nd
> 2018-12-10
> https://lists.fosdem.org/pipermail/fosdem/2018q4/002741.html 
> <https://lists.fosdem.org/pipermail/fosdem/2018q4/002741.html>
> Virtualization and IaaS @ Sat, Feb 2nd
> 2018-12-01
> https://lists.fosdem.org/pipermail/fosdem/2018q4/002757.html 
> <https://lists.fosdem.org/pipermail/fosdem/2018q4/002757.html>
> Containers @ Sun, Feb 3rd
> TBA
> TBA
> Microkernels and Component-based OS @ Sun, Feb 3rd
> 2018-12-01
> https://lists.fosdem.org/pipermail/fosdem/2018q4/002742.html 
> <https://lists.fosdem.org/pipermail/fosdem/2018q4/002742.html>
>  
> The complete list of accepted DevRooms is at 
> https://www.fosdem.org/2019/news/2018-10-14-accepted-developer-rooms/ 
> <https://www.fosdem.org/2019/news/2018-10-14-accepted-developer-rooms/>
> Some will have earlier CfP’s
>  
> Note that I am not volunteering for the Virtualization and IaaS DevRoom this 
> year: if anyone wants to volunteer, please contact  
> Brian Proffitt (bproffit at redhat)
>  
> Best Regards
> Lars
> ___
> Minios-devel mailing list
> minios-de...@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/minios-devel

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

Re: [Xen-devel] FOSDEM Devrooms (CfP deadlines for relevant DevRooms from Dec 1-10) and Xen Project Stand

[Lars Kurth]

Just a quick reminder that the CfP deadline is coming up
Note that FOSDEM has not yet announced the stands
Lars

From: Lars Kurth 
Date: Monday, 29 October 2018 at 17:01
To: xen-devel , 
"mirageos-de...@lists.xenproject.org" , 
"minios-de...@lists.xenproject.org" , 
"mirageos-de...@lists.xenproject.org" 
Cc: Zibby Keaton , Olivier Lambert 
, "daniel.ki...@oracle.com" 
, "committ...@xenproject.org" 

Subject: FOSDEM Devrooms (CfP deadlines for relevant DevRooms from Dec 1-10) 
and Xen Project Stand

Hi all,

I just submitted a Xen Project stand submission and if everything goes ok, we 
will be having a booth again like the last 5 years
Accepted stands should be announced by November 11

If you already know you are going, please add yourself to 
https://docs.google.com/spreadsheets/d/1uk79a_iEeSosTWG7OgZvhW2nZMO-cJHiDz0BNb0dN60/edit?usp=sharing
 and let me know if you are willing to help out. Also, if you want to give swag 
out, give demos, etc. please let me know by adding what you want to in the last 
column

Also, a number of CfP’s may be relevant: see table below

Devroom

CfP Deadline

CfP

BSD @ Sat, Feb 2nd

2018-12-10

https://lists.fosdem.org/pipermail/fosdem/2018q4/002741.html

Virtualization and IaaS @ Sat, Feb 2nd

2018-12-01

https://lists.fosdem.org/pipermail/fosdem/2018q4/002757.html

Containers @ Sun, Feb 3rd

TBA

TBA

Microkernels and Component-based OS @ Sun, Feb 3rd

2018-12-01

https://lists.fosdem.org/pipermail/fosdem/2018q4/002742.html


The complete list of accepted DevRooms is at 
https://www.fosdem.org/2019/news/2018-10-14-accepted-developer-rooms/
Some will have earlier CfP’s

Note that I am not volunteering for the Virtualization and IaaS DevRoom this 
year: if anyone wants to volunteer, please contact

Brian Proffitt (bproffit at redhat)

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

[Xen-devel] [PATCH] CONTRIBUTING: Clarifications on how to handle license deviations

[Lars Kurth]

This patch makes a few clarifications which were discussed on
IRC recently. 

Specifically: 
- Highlight the principle that license deviations
  should be brought to the attention of maintainers 
- Add a requirement for GPLv2 compatibility 
- Restructure the document toghlight  use-cases for  
  "New components" and "Importing code" clearer 
- Add conventions and instructions for "New files"

Signed-off-by: Lars Kurth 
---
 CONTRIBUTING | 27 +++
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/CONTRIBUTING b/CONTRIBUTING
index cfee8f1567..63050e9141 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -19,6 +19,19 @@ Most notably:
  - tools/xl   : LGPL v2.1
  - xen/include/public : MIT license
 
+The COMMON COPYRIGHT NOTICES section of this document contains
+sample copyright notices for the most common licenses used within
+this repository.
+
+When creating new components, new files, or importing code please follow
+the conventions outlined below. As a general rule, whenever code using a
+license other than GPLv2 is introduced, attention must be drawn to the
+difference, such that maibtainers can make an informed decision about the
+deviation. Any new code must be GPLv2 compatible.
+
+New components
+--
+
 When creating new components and directories that contain a
 significant amount of files that are licensed under licenses other
 than GPLv2 or the license specified in the COPYING file, please
@@ -27,15 +40,21 @@ license text and a rationale for using a different license. 
This helps
 ensure that the license of this new component/directory is maintained
 consistently with the original intention.
 
+New files
+-
+
+If specific files that differ from the license in a directory are introduced,
+exceptions should be highlighted and discussed in the commit message or cover
+letter introducing the file.
+
+Importing code
+--
+
 When importing code from other upstream projects into this repository,
 please create a README.source file in the directory the code is imported
 to, listing the original source of the code. An example can be found at
 m4/README.source
 
-The COMMON COPYRIGHT NOTICES section of this document contains
-sample copyright notices for the most common licenses used within
-this repository.
-
 Developer's Certificate of Origin
 -
 
-- 
2.13.0


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

Re: [Xen-devel] x86 Community Call: Nov 14 - 15:00 - 16:00 UTC - Call reminder

[Lars Kurth]

I am having trouble starting the call: hang on

On 14/11/2018, 14:45, "Lars Kurth"  wrote:

I think that is fine: added it to the agenda
The discussion may benefit from Stefano, but it is probably too early for 
him
Lars

On 14/11/2018, 14:36, "Rich Persaud"  wrote:

> On Nov 14, 2018, at 04:56, Lars Kurth  wrote:
> 
> Hi all,
> 
> the agenda is as follows: 
https://docs.google.com/document/d/1RxW-iwcFFuKzNjjEqLEtiwFVHgAUlk35c0EtTkRE1k4/edit
> * Follow up on previous actions
> * PVH resource Mapping: Rian Quinn (AIS)
> * TMEM (Jan)

If there is time on today's call, I would like to add an agenda item to 
discuss requirements collection for two Kconfig-defined subsets of Xen:

- minimal Xen hypervisor optimized for hardware support, 
isolation/partitioning, secrets-free, safety certification, reduced attack 
surface and performant nesting of Xen and other hypervisors, including Hyper-V, 
KVM, ESX, Bromium uXen, bhyve

- full-featured Xen hypervisor optimized for guest operating systems, 
unikernels, application-specific workloads and performant nesting on Xen and 
other hypervisors

Related topics for discussion, possibly on a future call:

- which hypervisor has priority for inter-VM communication policy 
enforcement
- scheduler interactions across bare-metal Xen, nested hypervisor and 
guest OS

Daniel Smith (Apertus) will introduce the topic.

Rich



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

Re: [Xen-devel] x86 Community Call: Nov 14 - 15:00 - 16:00 UTC - Call reminder

[Lars Kurth]

I think that is fine: added it to the agenda
The discussion may benefit from Stefano, but it is probably too early for him
Lars

On 14/11/2018, 14:36, "Rich Persaud"  wrote:

> On Nov 14, 2018, at 04:56, Lars Kurth  wrote:
> 
> Hi all,
> 
> the agenda is as follows: 
https://docs.google.com/document/d/1RxW-iwcFFuKzNjjEqLEtiwFVHgAUlk35c0EtTkRE1k4/edit
> * Follow up on previous actions
> * PVH resource Mapping: Rian Quinn (AIS)
> * TMEM (Jan)

If there is time on today's call, I would like to add an agenda item to 
discuss requirements collection for two Kconfig-defined subsets of Xen:

- minimal Xen hypervisor optimized for hardware support, 
isolation/partitioning, secrets-free, safety certification, reduced attack 
surface and performant nesting of Xen and other hypervisors, including Hyper-V, 
KVM, ESX, Bromium uXen, bhyve

- full-featured Xen hypervisor optimized for guest operating systems, 
unikernels, application-specific workloads and performant nesting on Xen and 
other hypervisors

Related topics for discussion, possibly on a future call:

- which hypervisor has priority for inter-VM communication policy 
enforcement
- scheduler interactions across bare-metal Xen, nested hypervisor and guest 
OS

Daniel Smith (Apertus) will introduce the topic.

Rich

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

Re: [Xen-devel] x86 Community Call: Nov 14 - 15:00 - 16:00 UTC - Call reminder

[Lars Kurth]

Hi all,

the agenda is as follows: 
https://docs.google.com/document/d/1RxW-iwcFFuKzNjjEqLEtiwFVHgAUlk35c0EtTkRE1k4/edit
* Follow up on previous actions
* PVH resource Mapping: Rian Quinn (AIS)
* TMEM (Jan)

## Dial in details
Web: https://www.gotomeet.me/larskurth

You can also dial in using your phone.
Access Code: 906-886-965

China (Toll Free): 4008 811084
Germany: +49 692 5736 7317
Poland (Toll Free): 00 800 1124759
United Kingdom: +44 330 221 0088
United States: +1 (571) 317-3129

More phone numbers
Australia: +61 2 9087 3604
Austria: +43 7 2081 5427
Argentina (Toll Free): 0 800 444 3375
Bahrain (Toll Free): 800 81 111
Belarus (Toll Free): 8 820 0011 0400
Belgium: +32 28 93 7018
Brazil (Toll Free): 0 800 047 4906
Bulgaria (Toll Free): 00800 120 4417
Canada: +1 (647) 497-9391
Chile (Toll Free): 800 395 150
Colombia (Toll Free): 01 800 518 4483
Czech Republic (Toll Free): 800 500448
Denmark: +45 32 72 03 82
Finland: +358 923 17 0568
France: +33 170 950 594
Greece (Toll Free): 00 800 4414 3838
Hong Kong (Toll Free): 30713169
Hungary (Toll Free): (06) 80 986 255
Iceland (Toll Free): 800 7204
India (Toll Free): 18002669272
Indonesia (Toll Free): 007 803 020 5375
Ireland: +353 15 360 728
Israel (Toll Free): 1 809 454 830
Italy: +39 0 247 92 13 01
Japan (Toll Free): 0 120 663 800
Korea, Republic of (Toll Free): 00798 14 207 4914
Luxembourg (Toll Free): 800 85158
Malaysia (Toll Free): 1 800 81 6854
Mexico (Toll Free): 01 800 522 1133
Netherlands: +31 207 941 377
New Zealand: +64 9 280 6302
Norway: +47 21 93 37 51
Panama (Toll Free): 00 800 226 7928
Peru (Toll Free): 0 800 77023
Philippines (Toll Free): 1 800 1110 1661
Portugal (Toll Free): 800 819 575
Romania (Toll Free): 0 800 410 029
Russian Federation (Toll Free): 8 800 100 6203
Saudi Arabia (Toll Free): 800 844 3633
Singapore (Toll Free): 18007231323
South Africa (Toll Free): 0 800 555 447
Spain: +34 932 75 2004
Sweden: +46 853 527 827
Switzerland: +41 225 4599 78
Taiwan (Toll Free): 0 800 666 854
Thailand (Toll Free): 001 800 011 023
Turkey (Toll Free): 00 800 4488 23683
Ukraine (Toll Free): 0 800 50 1733
United Arab Emirates (Toll Free): 800 044 40439
Uruguay (Toll Free): 0004 019 1018
Viet Nam (Toll Free): 122 80 481

First GoToMeeting? Let's do a quick system check:
https://link.gotomeeting.com/system-check

Best Regards
Lars

On 02/11/2018, 17:59, "Lars Kurth"  wrote:

Hi all, 

It’s time again for the x86 community call: for the agenda see 
https://docs.google.com/document/d/1RxW-iwcFFuKzNjjEqLEtiwFVHgAUlk35c0EtTkRE1k4/edit#

Please propose new agenda items by next Friday (feel free to just add them 
to the document or reply to this mail)

I listed open Actions below: open actions are on Andy, Janakarajan, George 
and Doug
There is still a week and a bit to close open actions.

Note that the meeting is at a different UTC time, but at the same local 
times except for China

Regards
Lars

Open / Closed Actions from Previous calls

Jan: blocked series
x86: more power-efficient CPU parking
Blocked on HW vendors (aka Intel and AMD) - not in HW manual. That only 
applies to the last patch (aka 5). Andy says he has reviewed it, Jan disagrees.

ACTION: Andy will double check whether he reviewed patch 4
ACTION: Janakarajan will take a look and ask relevant people in AMD
ACTION: Lars to escalate Intel part to Susie Li / John Ji (done)

Jan: blocked series
x86emul: fixes, improvements, and beginnings of AVX512 support
Andy points out that a series like this takes almost a day to review, 
because of complexity and size (also of the manual). Issues with 
cross-correlating manual vs. emulator code, because code uses different names 
than manual. Renaming helpers helped a little a bit. Would be disappointing if 
we missed 4.12

ACTION: George and Andy: Need a separate discussion to come up with a 
workable approach and no-one has a good solution. George and Andy to bring back 
to xen-devel

Nist Security Paper
ACTION: Lars set up wiki page and add to the minutes and respond to the 
call for feedback
See 
https://wiki.xenproject.org/wiki/Characterizing_Vulnerabilities_in_Platform_Security
  (done)

AOB
* Lars was wondering who will be at KVM forum. Maybe we can get a Xen group 
together (although this is not strictly x86 related)
Christopher Clark, Rich Persaud, Daniel Smith and Citrix folks attending => 
Lars to start a thread to coordinate a face-2-face meeting (done)
* AMD Ryzen/EPYC machines for the Xen Project test lab: any recommendations 
as per specific CPU SKU or will any do
ACTION: Lars to email Brian & Jon Grimm (done)
* Bug tracking (Doug)
ACTION: Set up cross functional call - waiting for mail by Doug



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

Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages]

[Lars Kurth]

Hi all, 

adding Wei because of  ...

User facing part: https://gitlab.com/xen-project/xen/pipelines
Back-end: https://gitlab.com/xen-project/xen-gitlab-ci
There are also some scripts in 
http://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=automation;hb=HEAD related to 
this

On 01/11/2018, 18:12, "Stefano Stabellini"  wrote:

Hi Ian,

Thank you for the detailed answer and the willingness to see OSSTest
changed in this respect.

Let me premise that as much as I would like this to be done, I had a
look at my schedule, and, realistically, I can only volunteer very
little time on this. In regards to the two Xilinx boards, it looks like
we'll just have to wait for Debian.

For the sake of this discussion and brainstorming solutions, I have a
couple of questions and answers on how to support different kernels with
Debian below.


On Thu, 1 Nov 2018, Ian Jackson wrote:
> > Yes, we should discuss the technical details on how to use our own
> > quasi-vanilla Linux branch together with the Debian installer. That's
> > all we need AFAICT.
> 
> OK.  So:
> 
> 
> I see two possible approaches:
> 
> Firstly, chicken-and-egg: Use osstest's `anointed job' mechanism to
> chain one Xen ARM kernel build from the next.  (The anointed job
> feature in osstest allows a certain build to be declared generally
> good for use by other jobs.  The anointment typically takes place at
> the end of a push gate flight, when the build job that is being
> anointed has been shown to work properly.)
> 
> Secondly, cross-compilation on x86.
> 
> I think cross-compilation on x86 is probably going to be easier
> because it is conceptually simpler.  It also avoids difficulties if
> the anointed build should turn out to be broken on some hosts (this
> ought to be detected by the push gate system, but...).  And, frankly,
> our x86 hardware is a lot faster.
> 
> So, assuming the plan is to do cross-compilation on x86.
> 
> The prerequisite is obviously an appropriate cross-compiler.  Will the
> Debian cross-compilers do ?

Probably it would work, but I don't know for sure. Most people use the
Linaro compiler and toolchain:


https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/
https://releases.linaro.org/components/toolchain/gcc-linaro/latest-7/

Testing the Debian cross-compiler would be very easy.

I was wondering whether we could use images in 
https://gitlab.com/xen-project/xen/container_registry as baseline for OSSTESTIN 
in these instances
We may be close to solving the build issues (via a WorksOnArm) via the GitLab CI
And it should be possible to create some infrastructure to build some custom 
images and put them into https://gitlab.com/xen-project/xen/container_registry 
and pull them from there. 

I don’t know whether that solves the full problem and how easy it would be: 
e.g. would we still need the cross-compiler for Xen
But we could separate the Dom0 kernel / distro build from OSSTEST 

> If not then maybe this is not the best
> approach because otherwise it's not clear where we'll get a suitable
> compiler.
> 
> If the Debian cross compilers are OK, then I think the necessary
> changes to osstest are:
> 
> 1. Introduce a distinction between the host (GCC terminology: build)
>and target (GCC terminology: host) architectures, in ts-xen-build.
>This includes adding a call to target_install_packages to install
>the cross compiler, and appropriately amending the configure and
>make runes.  Perhaps some of this will want to be in
>Osstest/BuildSupport.pm.  The runvars for build jobs will need to
>be reviewed to decide whether a new runvar is needed or whether
>cross-compilation can be inferred from a currently-unsupported
>combination of runvars (particularly, arch vs., hostflags).
> 
> 2. Maybe change ts-kernel-build to be able to additionally produce a
>.deb, or cpio full of modules, for use by step 5.  (This should be
>optional, controlled by a runvar, since it probably doubles the
>size of the build output...)
> 
> 3. Change make*flight and mfi-* to, on ARM, run the existing kernel
>build job on x86 by setting the job runvars appropriately.
> 
> 4a. Teach the debian-installer driver in Debian.pm how to pick up a
>kernel image from another job.  It would look at a runvar
>dikernelbuildjob or something I guess.
> 
> 4b. Teach it to pick up a kernel modules from another job and stuff
>them into its installer cpio before use.
> 
> 4c. Teach it to put the kernel and modules onto the being-installed
>system.
> 
>This would be a variant of, or amendment to, or alternative to,
>

[Xen-devel] FOSDEM Devrooms (CfP deadlines for relevant DevRooms from Dec 1-10) and Xen Project Stand

[Lars Kurth]

Hi all,

I just submitted a Xen Project stand submission and if everything goes ok, we 
will be having a booth again like the last 5 years
Accepted stands should be announced by November 11

If you already know you are going, please add yourself to 
https://docs.google.com/spreadsheets/d/1uk79a_iEeSosTWG7OgZvhW2nZMO-cJHiDz0BNb0dN60/edit?usp=sharing
 and let me know if you are willing to help out. Also, if you want to give swag 
out, give demos, etc. please let me know by adding what you want to in the last 
column

Also, a number of CfP’s may be relevant: see table below

Devroom

CfP Deadline

CfP

BSD @ Sat, Feb 2nd

2018-12-10

https://lists.fosdem.org/pipermail/fosdem/2018q4/002741.html

Virtualization and IaaS @ Sat, Feb 2nd

2018-12-01

https://lists.fosdem.org/pipermail/fosdem/2018q4/002757.html

Containers @ Sun, Feb 3rd

TBA

TBA

Microkernels and Component-based OS @ Sun, Feb 3rd

2018-12-01

https://lists.fosdem.org/pipermail/fosdem/2018q4/002742.html


The complete list of accepted DevRooms is at 
https://www.fosdem.org/2019/news/2018-10-14-accepted-developer-rooms/
Some will have earlier CfP’s

Note that I am not volunteering for the Virtualization and IaaS DevRoom this 
year: if anyone wants to volunteer, please contact

Brian Proffitt (bproffit at redhat)

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

Re: [Xen-devel] [PATCH v4 03/23] xen/arm: document dom0less

[Lars Kurth]

Hi Stefano,

> On 9 Oct 2018, at 12:52, Julien Grall  wrote:
> 
> Hi Stefano,
> 
> On 05/10/2018 19:47, Stefano Stabellini wrote:
>> Add a new document to provide information on how to use dom0less related
>> features and their current limitations.
>> Signed-off-by: Stefano Stabellini 
>> ---
>> Changes in v4:
>> - rename to .txt
>> - improve wording
>> Changes in v3:
>> - add patch
>> ---
>>  docs/misc/arm/dom0less.txt | 47 
>> ++
> 
> As said on the previous version, you likely need to add an entry in 
> docs/INDEX.

Agreed. Also, it may be worthwhile encoding the doc in markdown (it's not that 
much text) and using the .markdown extension
Also, it seems to me that docs/features is maybe a better place for this 
document. Not sure whether docs in this folder get picked up automatically 
though

Lars


signature.asc
Description: Message signed with OpenPGP
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] x86 Community Call: Wed Oct 10 - Minutes

[Lars Kurth]

Hi all,
thank you to those joining the call. The minutes are attached and at 
https://docs.google.com/document/d/1ZfZ1SJRauLrISiTLXzM0DPxQL8beNkAQS5MwLLNtRKc/edit
 
Feel free to make corrections. Also, I created 
https://wiki.xenproject.org/wiki/Characterizing_Vulnerabilities_in_Platform_Security
 regarding the NIST paper. Feel free to add to it. I have not responded yet and 
I will wait until Friday
Regards
Lars



Agenda and Minutes_ x86 Community Call October 2018.pdf
Description: Agenda and Minutes_ x86 Community Call October 2018.pdf
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] x86 Community Call: Wed Oct 10, 14:00 - 15:00 UTC - Call for agenda items

[Lars Kurth]

> If the Xen community wishes to provide feedback on this NISTIR draft, I 
> suggest compiling a single document, including:
I hope so: we may as well use the relevant section in 
https://docs.google.com/document/d/1ZfZ1SJRauLrISiTLXzM0DPxQL8beNkAQS5MwLLNtRKc/edi
 to collate the feedback
But I can create a separate doc
Let’s discuss in the meeting
Regards
Lars

From: Rich Persaud 
Date: Tuesday, 9 October 2018 at 21:33
To: Lars Kurth 
Cc: Andrew Cooper , Tamas K Lengyel 
, xen-devel , 
"committ...@xenproject.org" , "intel-...@intel.com" 
, "daniel.ki...@oracle.com" , 
Roger Monne , "christopher.w.cl...@gmail.com" 
, Brian Woods , 
"jgr...@suse.com" , Paul Durrant , 
John Ji , "jnata...@amd.com" , "Edgar E. 
Iglesias" , "davorin.mi...@aggios.com" 
, "robin.randh...@arm.com" , 
Artem Mygaiev , "matt.spen...@arm.com" 
, "anastassios.na...@onapp.com" 
, Julien Grall , 
"stewart.hildebr...@dornerworks.com" , 
"vfac...@de.adit-jv.com" , Volodymyr Babchuk 
, "mirela.simono...@aggios.com" 
, "jarvis.ro...@dornerworks.com" 
, Stefano Stabellini 
Subject: Re: x86 Community Call: Wed Oct 10, 14:00 - 15:00 UTC - Call for 
agenda items

Lars,

This NIST document ("A Methodology for Determining Forensic Data Requirements 
for Detecting Hypervisor Attacks" [1]) appears to be focused on the application 
of LibVMI in some contexts.  It is a NIST Interagency or Internal Report 
(NISTIR) document with a narrower scope than other NIST publications, e.g. 
Special Publications (SP).  NISTIR documents are:

https://www.nist.gov/nist-research-library/nist-series-publications
"... Interim or final reports on work performed by NIST for outside sponsors 
(both government and non-government).  May also report results of NIST projects 
of transitory or limited interest, including those that will be published 
subsequently in more comprehensive form."


If the Xen community wishes to provide feedback on this NISTIR draft, I suggest 
compiling a single document, including:

 - any inaccuracies + supporting references
 - vulnerability scope boundaries, including Xen hypervisor, Linux kernel 
affecting KVM, KVM module for Linux kernel, QEMU and hypervisor toolstack(s)
 - additional sample attack(s) and evidence coverage for forensic analysis
 - additional references on hypervisor security / vulnerability analysis
 - missing perspectives (e.g. impact of features selected via KCONFIG, 
disaggregation)
 - other feedback

If a single list can be compiled, each item can be numbered and Xen community 
viewpoints can be aggregated for possible consensus in unified feedback, or 
individuals could submit their feedback separately.

Rich

[1] 
https://csrc.nist.gov/CSRC/media/Publications/nistir/8221/draft/documents/nistir-8221-draft.pdf

On Oct 9, 2018, at 14:20, Lars Kurth 
mailto:lars.ku...@citrix.com>> wrote:
Hi all,
I added a NIST Security Paper to the agenda which is currently under review and 
is full of inaccuracies and could potentially become very problematic to the 
project and vendors using Xen if officially published by NIST without being 
corrected (it needs responses by the end of week). I will be struggling to do 
this alone and would like to enlist help, in particular from people with a 
security background. That would also be significantly more powerful than me 
providing the feedback.
Regards
Kars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] x86 Community Call: Wed Oct 10, 14:00 - 15:00 UTC - Call for agenda items

[Lars Kurth]

Hi all,
I added a NIST Security Paper to the agenda which is currently under review and 
is full of inaccuracies and could potentially become very problematic to the 
project and vendors using Xen if officially published by NIST without being 
corrected (it needs responses by the end of week). I will be struggling to do 
this alone and would like to enlist help, in particular from people with a 
security background. That would also be significantly more powerful than me 
providing the feedback.
Regards
Kars

On 09/10/2018, 16:13, "Andrew Cooper"  wrote:

On 09/10/18 15:53, Tamas K Lengyel wrote:
> On Tue, Oct 9, 2018 at 7:41 AM Lars Kurth  wrote:
>> Hi all,
>>
>> ## Agenda
>>   The agenda can be found at 
https://docs.google.com/document/d/1ZfZ1SJRauLrISiTLXzM0DPxQL8beNkAQS5MwLLNtRKc/edit?usp=sharing
>>   The document is R/W already
> I've added a last minute item I would like to discuss if possible
> regarding the state of nested virtualization.

Certainly can.  The tl;dr is that Nested Virt is my highest priority
work, short of security issues.

Curiously, it hasn't made much progress in the past year...

~Andrew


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

Re: [Xen-devel] x86 Community Call: Wed Oct 10, 14:00 - 15:00 UTC - Call for agenda items

[Lars Kurth]

Tamas: I saw it. Thank you

On 09/10/2018, 16:13, "Andrew Cooper"  wrote:

On 09/10/18 15:53, Tamas K Lengyel wrote:
> On Tue, Oct 9, 2018 at 7:41 AM Lars Kurth  wrote:
>> Hi all,
>>
>> ## Agenda
>>   The agenda can be found at 
https://docs.google.com/document/d/1ZfZ1SJRauLrISiTLXzM0DPxQL8beNkAQS5MwLLNtRKc/edit?usp=sharing
>>   The document is R/W already
> I've added a last minute item I would like to discuss if possible
> regarding the state of nested virtualization.

Certainly can.  The tl;dr is that Nested Virt is my highest priority
work, short of security issues.

Curiously, it hasn't made much progress in the past year...

~Andrew


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

Re: [Xen-devel] x86 Community Call: Wed Oct 10, 14:00 - 15:00 UTC - Call for agenda items

[Lars Kurth]

Hi all,

## Agenda 
  The agenda can be found at 
https://docs.google.com/document/d/1ZfZ1SJRauLrISiTLXzM0DPxQL8beNkAQS5MwLLNtRKc/edit?usp=sharing
  The document is R/W already

  But in a nutshell 
  * Admin Items: When to have winter meetings (DST effect)
  * Open / Closed Actions from Previous calls
  * New Series / Series that need attention - note that I don't have any right 
now. Feel free to add items to this section
  * Maintainer Responsiveness (Paul Durrant) 
  * AOB (none at this stage)

## Meeting time
  14:00 - 15:00 UTC
  10:00 - 11:00 EDT (New York)
  15:00 - 16:00 BST (London)
  16:00 - 17:00 CEST (Berlin)
  22:00 - 23:00 CST (Beijing)

Further International meeting times: 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2018=10=10=14=0=0=224=24=179=136=37=33
 

## Dial in details
Web: https://www.gotomeet.me/larskurth

You can also dial in using your phone.
Access Code: 906-886-965

China (Toll Free): 4008 811084
Germany: +49 692 5736 7317
Poland (Toll Free): 00 800 1124759
United Kingdom: +44 330 221 0088
United States: +1 (571) 317-3129

More phone numbers
Australia: +61 2 9087 3604
Austria: +43 7 2081 5427
Argentina (Toll Free): 0 800 444 3375
Bahrain (Toll Free): 800 81 111
Belarus (Toll Free): 8 820 0011 0400
Belgium: +32 28 93 7018
Brazil (Toll Free): 0 800 047 4906
Bulgaria (Toll Free): 00800 120 4417
Canada: +1 (647) 497-9391
Chile (Toll Free): 800 395 150
Colombia (Toll Free): 01 800 518 4483
Czech Republic (Toll Free): 800 500448
Denmark: +45 32 72 03 82
Finland: +358 923 17 0568
France: +33 170 950 594
Greece (Toll Free): 00 800 4414 3838
Hong Kong (Toll Free): 30713169
Hungary (Toll Free): (06) 80 986 255
Iceland (Toll Free): 800 7204
India (Toll Free): 18002669272
Indonesia (Toll Free): 007 803 020 5375
Ireland: +353 15 360 728
Israel (Toll Free): 1 809 454 830
Italy: +39 0 247 92 13 01
Japan (Toll Free): 0 120 663 800
Korea, Republic of (Toll Free): 00798 14 207 4914
Luxembourg (Toll Free): 800 85158
Malaysia (Toll Free): 1 800 81 6854
Mexico (Toll Free): 01 800 522 1133
Netherlands: +31 207 941 377
New Zealand: +64 9 280 6302
Norway: +47 21 93 37 51
Panama (Toll Free): 00 800 226 7928
Peru (Toll Free): 0 800 77023
Philippines (Toll Free): 1 800 1110 1661
Portugal (Toll Free): 800 819 575
Romania (Toll Free): 0 800 410 029
Russian Federation (Toll Free): 8 800 100 6203
Saudi Arabia (Toll Free): 800 844 3633
Singapore (Toll Free): 18007231323
South Africa (Toll Free): 0 800 555 447
Spain: +34 932 75 2004
Sweden: +46 853 527 827
Switzerland: +41 225 4599 78
Taiwan (Toll Free): 0 800 666 854
Thailand (Toll Free): 001 800 011 023
Turkey (Toll Free): 00 800 4488 23683
Ukraine (Toll Free): 0 800 50 1733
United Arab Emirates (Toll Free): 800 044 40439
Uruguay (Toll Free): 0004 019 1018
Viet Nam (Toll Free): 122 80 481

First GoToMeeting? Let's do a quick system check:
https://link.gotomeeting.com/system-check

Best Regards
Lars



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

[Xen-devel] x86 Community Call: Wed Oct 10, 14:00 - 15:00 UTC - Call for agenda items

[Lars Kurth]

Dear community members, 

please send me agenda items for next week’s community call by next Monday. If 
you are not on the TO list, and want to be, please let me know. 
Last month's minutes were at 
https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/edit#heading=h.mz1wjb9vekjn

One admin item we do need to discuss is
1) Non-DST meeting times: Note that from November Daylight Savings does not 
apply in the northern hemisphere.
Option 1: If we keep the meeting at 14:00 - 15:00 UTC, meetings in the US and 
Europe will be one hour earlier, while the China will be at the same time
Option 2: If we move the meeting to 15:00 - 14:00 UTC during winter time, 
meetings in the US and Europe will stay the same, while the China will be at 
23:00-24:00

2) Open / Recently closed ACTION items
* [Open] Lars to bring up x86 bottleneck at next AB call – due to the Aug 
holidays we didn’t have any of the relevant vendors on the call. On the Sept 
call, we had a similar issue for different reasons. I have done a little bit of 
Analysis, which I am willing to share. 
* [Open] Christopher will follow up on IRC/xen-devel@ re memory scrubbing
* [Open] Lars would be happy to start a discussion on IRC, then xen-devel and 
start tidying the JIRA instance up - discussed on IRC, but did not have time to 
play with Jira
* [Open] Juergen agreed to add Argo to the work tracking list for the 4.12 
release, communicated in the “Xen 4.12 Development Update” mail series. Latest 
update, see 
https://lists.xenproject.org/archives/html/xen-devel/2018-09/threads.html#01069 

* [Done] Lars to give Christopher write access to JIRA 
* [Done] Christopher to create a JIRA ticket for the Argo work, see 
https://xenproject.atlassian.net/browse/XEN-118

Meeting time
14:00 - 15:00 UTC
10:00 - 11:00 EDT (New York)
15:00 - 16:00 BST (London)
16:00 - 17:00 CEST (Berlin)
22:00 - 23:00 CST (Beijing)
Further International meeting times: 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2018=10=10=14=0=0=224=24=179=136=37=33
 

Best Regards
Lars

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

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

[Lars Kurth]

Adding a few people who have recently been working on PV drivers, as well as 
Julien
Lars

> On 27 Sep 2018, at 06:44, Omkar Bolla  wrote:
> 
> Hi,
> 
> I am using Debian as Domain-0 and Debian as Domain-U on Hikey960 
> platform(ARMv8) and using Xen-4.8 stable release. Here I want to create a PV 
> frontend and backend to share memory between Domain-0 and Domain-U. 
> 
> 
> 
> I used below link to create frontend and backend,
> https://fnordig.de/2016/12/02/xen-a-backend-frontend-driver-example/ 
> 
> 
> But I am facing below errors while adding device vdevb to xenstore. 
> Below errors I am getting from xenbus_switch_state().
> vdevb vdevb-0: failed to write error node for device/vdevb/0 (13 writing new 
> state)
> 
> Please suggest me, How to create PV drivers.
> 
> Thanks,
> Omkar B
> 
> This message contains confidential information and is intended only for the 
> individual(s) named. If you are not the intended recipient, you are notified 
> that disclosing, copying, distributing or taking any action in reliance on 
> the contents of this mail and attached file/s is strictly prohibited. Please 
> notify the sender immediately and delete this e-mail from your system. E-mail 
> transmission cannot be guaranteed to be secured or error-free as information 
> could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, 
> or contain viruses. The sender therefore does not accept liability for any 
> errors or omissions in the contents of this message, which arise as a result 
> of e-mail transmission.
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

Re: [Xen-devel] Xen PPC64

[Lars Kurth]

Tamara,
Have a look at this thread: https://xen.markmail.org/thread/vuk7atnyqfq52epp 

That will answer some but not all of your questions: 
https://markmail.org/message/cizu54474lvuus6k 
 gives an indication of size and 
elapsed time required
Regards
Lars

> On 27 Sep 2018, at 08:07, Tamara B. Elizondo  wrote:
> 
> Hello,
> 
> I would like to fund a port of Xen to the PPC64 architecture, more specially 
> POWER9, in little endian and big endian mode.
> 
> Anyone with the required competence can provide me with an idea of the delay 
> and funds required for this?
> 
> I am pushing this forward to enable Qubes OS compatibility on the Talos II 
> Desktop POWER9 platform. (https://raptorcs.com)
> 
> Thank you
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

Re: [Xen-devel] x86 Community Call - Wed Sept 12, 14:00 - 15:00 UTC - Minutes

[Lars Kurth]

Hi all: I just noticed that the Minutes link at 
https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/edit?usp=sharing
 did not allow people to edit the page. Apologies. This is fixed now.

Feel free to make corrections. I will wait for a couple of days before sending 
out the official meeting minutes.

Lars

From: Lars Kurth 
Date: Thursday, 13 September 2018 at 13:05
To: xen-devel 
Subject: Re: x86 Community Call - Wed Sept 12, 14:00 - 15:00 UTC - Agenda

This email seems to not have gone through to xen-devel@ … resending and 
removing the CC list such that I can link to the slides

From: Daniel Smith 
Date: Wednesday, 12 September 2018 at 13:30
To: Lars Kurth 
Cc: xen-devel , "committ...@xenproject.org" 
, Tamas K Lengyel , 
"intel-...@intel.com" , "daniel.ki...@oracle.com" 
, Roger Monne , Christopher 
Clark , Rich Persaud , Brian 
Woods , Stefano Stabellini , 
Julien Grall , Juergen Gross , Paul 
Durrant , "Ji, John" , "Natarajan, 
Janakarajan" , "edgar.igles...@xilinx.com" 
, "davorin.mi...@aggios.com" 
, "robin.randh...@arm.com" , 
Artem Mygaiev , Matt Spencer , 
"anastassios.na...@onapp.com" , Stewart Hildebrand 
, "vfac...@de.adit-jv.com" 
, Volodymyr Babchuk , 
"mirela.simono...@aggios.com" , Jarvis Roach 

Subject: Re: x86 Community Call - Wed Sept 12, 14:00 - 15:00 UTC - Agenda

All,

I have attached slides for today's talk (Xen measured boot.pdf) as well as the 
slides from my Platform Security Summit talk (PSEC slides.pdf).

V/r,
Daniel P. Smith
Apertus Solutions, LLC






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

Re: [Xen-devel] x86 Community Call - Wed Sept 12, 14:00 - 15:00 UTC - Agenda

[Lars Kurth]

Dear community members,
 
The proposed agenda is at
https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/edit#

And below in text form:

== Open / Closed Actions from Previous calls ==
[Open] Lars to bring up x86 bottleneck at next AB call – due to the Aug 
holidays we didn’t have any of the 
relevant vendors on the call 
[Open] Christopher will follow up on IRC/xen-devel@ re memory scrubbing 
[Closed] Andrew was going to look at L1TF related issues and add this to Jira 
(unless I misunderstood) 
See https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg01160.html
[Closed] Juergen to send a mail related to 32PV support to xen-devel 
See https://lists.xenproject.org/archives/html/xen-devel/2018-08/msg01230.html

== Argo: Christopher Clark ==
"Argo" (formerly v4v) inter-VM communication mechanism for Xen 4.12, discussed 
at Xen Summit 2018 
design session and PSEC 2018, design doc forthcoming.  Variants of this 
technology have been used in 
OpenXT and uXen/Bromium for several years.
Video:  https://www.platformsecuritysummit.com/2018/speaker/clark/
Wiki: 
https://wiki.xen.org/wiki/Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen 


== Trenchboot: Daniel Smith ==
The presentation will provide a quick review of the concepts underlying 
integrity (trust) in the boot process 
used by SecureBoot and Measured Boot. From there, our focus will be on 
explaining the types of measured 
boot. Then we will touch on how TrenchBoot is working to make measured boot 
more accessible while still 
providing rich capabilities. Wrapping up we will discuss collaboration being 
sought with the Xen Project.

IMPORTANT: A subset of what Daniel will cover is explained in this 38 minute 
video: 
https://www.platformsecuritysummit.com/2018/speaker/smith/ if you can, please 
watch the video before 
the session. This will allow for more discussion time.

There were boot integrity talks on Xen and/or UEFI, from AIS, Dell, Intel, 
Oracle:
https://www.platformsecuritysummit.com/2018/topic/boot/


== AOB ==

== Dial-in Information ==

## Future Community Call schedule
Oct 10, Nov 14, Dec 12

## Meeting time
14:00 - 15:00 UTC
10:00 - 11:00 EDT (New York)
15:00 - 16:00 BST (London)
16:00 - 17:00 CEST (Berlin)
22:00 - 23:00 CST (Beijing)
Further International meeting times: 

https://www.timeanddate.com/worldclock/meetingdetails.html?year=2018=9=12=14=0=0=224=24=179=136=37=33
 
## Dial in details
Web: https://www.gotomeet.me/larskurth

You can also dial in using your phone.
Access Code: 906-886-965

China (Toll Free): 4008 811084
Germany: +49 692 5736 7317
Poland (Toll Free): 00 800 1124759
United Kingdom: +44 330 221 0088
United States: +1 (571) 317-3129

More phone numbers
Australia: +61 2 9087 3604
Austria: +43 7 2081 5427
Argentina (Toll Free): 0 800 444 3375
Bahrain (Toll Free): 800 81 111
Belarus (Toll Free): 8 820 0011 0400
Belgium: +32 28 93 7018
Brazil (Toll Free): 0 800 047 4906
Bulgaria (Toll Free): 00800 120 4417
Canada: +1 (647) 497-9391
Chile (Toll Free): 800 395 150
Colombia (Toll Free): 01 800 518 4483
    Czech Republic (Toll Free): 800 500448
Denmark: +45 32 72 03 82
Finland: +358 923 17 0568
France: +33 170 950 594
Greece (Toll Free): 00 800 4414 3838
Hong Kong (Toll Free): 30713169
Hungary (Toll Free): (06) 80 986 255
Iceland (Toll Free): 800 7204
India (Toll Free): 18002669272
Indonesia (Toll Free): 007 803 020 5375
Ireland: +353 15 360 728
Israel (Toll Free): 1 809 454 830
Italy: +39 0 247 92 13 01
Japan (Toll Free): 0 120 663 800
Korea, Republic of (Toll Free): 00798 14 207 4914
Luxembourg (Toll Free): 800 85158
Malaysia (Toll Free): 1 800 81 6854
Mexico (Toll Free): 01 800 522 1133
Netherlands: +31 207 941 377
New Zealand: +64 9 280 6302
Norway: +47 21 93 37 51
Panama (Toll Free): 00 800 226 7928
Peru (Toll Free): 0 800 77023
Philippines (Toll Free): 1 800 1110 1661
Portugal (Toll Free): 800 819 575
Romania (Toll Free): 0 800 410 029
Russian Federation (Toll Free): 8 800 100 6203
Saudi Arabia (Toll Free): 800 844 3633
Singapore (Toll Free): 18007231323
South Africa (Toll Free): 0 800 555 447
Spain: +34 932 75 2004
Sweden: +46 853 527 827
Switzerland: +41 225 4599 78
Taiwan (Toll Free): 0 800 666 854
Thailand (Toll Free): 001 800 011 023
Turkey (Toll Free): 00 800 4488 23683
Ukraine (Toll Free): 0 800 50 1733
United Arab Emirates (Toll Free): 800 044 40439
Uruguay (Toll Free): 0004 019 1018
Viet Nam (Toll Free): 122 80 481

First GoToMeeting? Let's do a quick system check:
https://link.gotomeeting.com/system-check

Best Regards
Lars

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