On Thu, Oct 24, 2019 at 5:12 AM David Hildenbrand wrote:
>
> Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
> change that.
>
> KVM has this weird use case that you can map anything from /dev/mem
> into the guest. pfn_valid() is not a reliable check whether the memmap
> was
On 07.11.2019 16:46, Roger Pau Monné wrote:
> On Thu, Nov 07, 2019 at 04:28:56PM +0100, Jan Beulich wrote:
>> On 07.11.2019 16:06, Roger Pau Monne wrote:
>>> @@ -530,9 +530,9 @@ static void clear_IO_APIC_pin(unsigned int apic,
>>> unsigned int pin)
>>> */
>>> memset(, 0,
flight 143841 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143841/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 142932
On Thu, Nov 07, 2019 at 10:22:23AM -0800, Stefano Stabellini wrote:
> On Thu, 7 Nov 2019, Wei Liu wrote:
> > On Wed, Nov 06, 2019 at 08:10:47AM -0800, Stefano Stabellini wrote:
> > > On Wed, 6 Nov 2019, Wei Liu wrote:
> > > > On Tue, Nov 05, 2019 at 03:51:13PM -0800, Stefano Stabellini wrote:
> >
Jürgen Groß writes ("OSStest priorities"):
> in the Xen community call we agreed to try to speed up OSStest for
> xen-unstable in order to make better progress with the 4.13 release.
>
> Could you please suspend testing for Xen 4.10 and older (Jan agreed on
> that), and disable the Linux kernel
On Thu, 7 Nov 2019, Wei Liu wrote:
> On Wed, Nov 06, 2019 at 08:10:47AM -0800, Stefano Stabellini wrote:
> > On Wed, 6 Nov 2019, Wei Liu wrote:
> > > On Tue, Nov 05, 2019 at 03:51:13PM -0800, Stefano Stabellini wrote:
> > > > Actually, pygrub cross-compiles without issues. The cross-compilation
>
Hi Ian,
in the Xen community call we agreed to try to speed up OSStest for
xen-unstable in order to make better progress with the 4.13 release.
Could you please suspend testing for Xen 4.10 and older (Jan agreed on
that), and disable the Linux kernel tests which are currently failing
(including
On 07/11/2019 17:44, Jürgen Groß wrote:
> Hi Ian,
>
> in the Xen community call we agreed to try to speed up OSStest for
> xen-unstable in order to make better progress with the 4.13 release.
>
> Could you please suspend testing for Xen 4.10 and older (Jan agreed on
> that), and disable the
On Thu, Nov 07, 2019 at 04:58:14PM +, p...@xen.org wrote:
> From: Paul Durrant
>
> The vif-route script should only call 'ip route' when 'ipcmd' has been
> set, otherwise it will fail due to an incorrect command string.
>
> This patch also adds routes for 'tap' (i.e. emulated) devices as
flight 143753 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143753/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail REGR. vs. 142915
flight 143825 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143825/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 142947
On 07.11.19 18:52, Ian Jackson wrote:
These are failing and have been for some time and it does not appear
that anyone has the capability to fix them. Running them in these
circumstances seems wasteful.
Effect is to drop test-*-win10-* jobs (checked with
From: Paul Durrant
The vif-route script should only call 'ip route' when 'ipcmd' has been
set, otherwise it will fail due to an incorrect command string.
This patch also adds routes for 'tap' (i.e. emulated) devices as well as
'vif' (i.e. PV) devices by making use of the route metric. Emulated
These are failing and have been for some time and it does not appear
that anyone has the capability to fix them. Running them in these
circumstances seems wasteful.
Effect is to drop test-*-win10-* jobs (checked with
standalone-generate-dump-flight-runvars).
CC: Sander Eikelenboom
CC: Jürgen
On 06.11.2019 18:12, Andrew Cooper wrote:
> On 06/11/2019 15:18, Jan Beulich wrote:
>> Unmapping a page which has never been mapped should be a no-op (note how
>> it already is in case there was no root page table allocated).
>
> Which function are you talking about here? iommu_pde_from_dfn()
Hello,
The latest upstream fails to boot on AMD Rome with this:
(XEN) [ 10.082154] ENABLING IO-APIC IRQs
(XEN) [ 10.087789] -> Using new ACK method
(XEN) [ 10.093738] Assertion 'get_rte_index(rte) == offset' failed at
iommu_intr.c:328
Full log is available at
On 11/7/19 7:20 AM, Jan Beulich wrote:
> On 24.10.2019 15:31, Jan Beulich wrote:
>> The .file assembler directives generated by the compiler do not include
>> any path components (gcc) or just the ones specified on the command line
>> (clang, at least version 5), and hence multiple identically
On 28.10.19 21:10, Jason Gunthorpe wrote:
From: Jason Gunthorpe
DMA_SHARED_BUFFER can not be enabled by the user (it represents a library
set in the kernel). The kconfig convention is to use select for such
symbols so they are turned on implicitly when the user enables a kconfig
that needs
On 01.10.2019 00:38, Roman Shaposhnik wrote:
> Btw, forgot to attach the patch with maxcpus=2 -- interestingly enough
> Xen seems to hang much further down than before (basically after
> attempting to build out Dom0)
Have you meanwhile had a chance to retry with latest microcode?
Jan
On 29.10.19 18:57, Ian Jackson wrote:
The pvshim can only be built 64-bit because the hypervisor is only
64-bit nowadays. The hypervisor build supports XEN_COMPILE_ARCH and
XEN_TARGET_ARCH which override the information from uname. The pvshim
build runs out of the tools/ directory but calls
On 30.10.19 19:06, Anthony PERARD wrote:
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.fix-ev_qmp-multi-connect-v2
Hi,
QEMU's QMP socket doesn't allow multiple concurrent connection. Also, it
listen() on the socket with a
On 04.11.19 16:30, Anthony PERARD wrote:
Before 93dcc22, error from setting the vnc password to an empty
string, when QEMU wasn't expected a password, never prevented the creation
of a guest, and only logged an error message.
Reported-by: Roger Pau Monné
Fixes:
On 06.11.19 16:58, Dario Faggioli wrote:
In a dom0less configuration, if the null scheduler is used, the system
may fail to boot, because the loop in null_unit_wake() never exits.
Bisection showed that this behavior occurs since commit d545f1d6 ("xen:
sched: deal with vCPUs being or becoming
The assertions in csched2_free_pdata() are wrong as in case it is
called by schedule_cpu_add() after a failure of sched_alloc_udata()
the init pdata function won't have been called.
So just remove the (wrong) comment and ASSERT() statements.
While at it remove the wrong comment in
On 01.11.19 20:13, Andrew Cooper wrote:
c-indent-level isn't considered a safe variable, and "solaris" isn't a
recognised C style. Both cause prompts when opening the files.
Fix all blocks up per CODING_STYLE
Signed-off-by: Andrew Cooper
Release-acked-by: Juergen Gross
Juergen
On Thu, Nov 07, 2019 at 08:06:08PM +, Jason Gunthorpe wrote:
> >
> > enum mmu_range_notifier_event {
> > MMU_NOTIFY_RELEASE,
> > };
> >
> > ...assuming that we stay with "mmu_range_notifier" as a core name for this
> > whole thing.
> >
> > Also, it is best moved down to be next to the
cpupool_online_cpumask() is used by credit and rt scheduler. It returns
all the cpus of a cpupool or all online cpus in case no cpupool is
specified.
The "no cpupool" case can be dropped, as no scheduler other than the
init scheduler will ever work on cpus not associated with any cpupool.
As the
On 08.11.19 06:09, Dan Williams wrote:
On Thu, Nov 7, 2019 at 2:07 PM David Hildenbrand wrote:
On 07.11.19 19:22, David Hildenbrand wrote:
Am 07.11.2019 um 16:40 schrieb Dan Williams :
On Thu, Oct 24, 2019 at 5:12 AM David Hildenbrand wrote:
Right now, ZONE_DEVICE memory is always
On Wed, 6 Nov 2019 at 15:20, Jan Beulich wrote:
>
> Unmapping a page which has never been mapped should be a no-op (note how
> it already is in case there was no root page table allocated). There's
> in particular no need to grow the number of page table levels in use,
> and there's also no need
flight 143839 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143839/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1bcc65b9a1408cf445b7b3f9499b27d9c235db71
baseline version:
ovmf
On 01.11.2019 19:28, Igor Druzhinin wrote:
> This patch instead acquires the lock once for assignment (or test assign)
> operations directly in iommu_do_pci_domctl() and thus can remove the
> duplicate domain ownership check in assign_device(). Whilst in the
> neighbourhood, the patch also removes
On 07.11.2019 16:06, Roger Pau Monne wrote:
> clear_IO_APIC_pin can be called after the iommu has been enabled, and
> using raw entry reads and writes will result in a misconfiguration of
> the entries already setup to use the interrupt remapping table.
I'm afraid I don't understand this: Raw
On 31.10.19 13:17, Anthony PERARD wrote:
After sending the 'device_del' command for a PCI passthrough device,
we wait until QEMU has effectively deleted the device, this involves
executing more QMP commands. While waiting, libxl hold the connection.
It isn't necessary to hold the connection and
flight 143854 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143854/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 139091
Today there is a global limit of pages mapped via /dev/xen/gntdev set
to 1 million pages per default. There is no reason why that limit is
existing, as total number of grant mappings is limited by the
hypervisor anyway and preferring kernel mappings over userspace ones
doesn't make sense. It
With sufficient many pages to map gntdev can reach order 9 allocation
sizes. As there is no need to have physically contiguous buffers switch
to kvcalloc() in order to avoid failing allocations.
Signed-off-by: Juergen Gross
Reviewed-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev.c | 31
The Xen gntdev driver's checking of the number of allowed mapped pages
is in need of some sanitizing work.
Changes in V2:
- enhanced commit message of patch 1 (Andrew Cooper)
Juergen Gross (2):
xen/gntdev: replace global limit of mapped pages by limit per call
xen/gntdev: switch from
On 07.11.2019 13:49, Andrew Cooper wrote:
> On 07/11/2019 07:36, Jan Beulich wrote:
>> On 06.11.2019 18:31, Andrew Cooper wrote:
>>> On 06/11/2019 15:16, Jan Beulich wrote:
update_paging_mode() in the AMD IOMMU code expects to be invoked with
the PCI devices lock held. The check
On 07/11/2019 15:06, Roger Pau Monne wrote:
> And instead use proper booleans. No functional change intended.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Juergen Gross
> ---
Urgh. Can we purge with prejudice all of this TRUE and FALSE nonsense?
There are only a few users more than this
On 07.11.2019 16:06, Roger Pau Monne wrote:
> And instead use proper booleans. No functional change intended.
>
> Signed-off-by: Roger Pau Monné
Other than Andrew I think this is fine without further extension,
i.e.
Acked-by: Jan Beulich
Of course this isn't to say that I wouldn't welcome a
On Wed, Nov 06, 2019 at 09:56:48AM -0800, h...@zytor.com wrote:
> On November 6, 2019 9:03:33 AM PST, Borislav Petkov wrote:
> >On Mon, Nov 04, 2019 at 04:13:51PM +0100, Daniel Kiper wrote:
> >> Hi,
> >>
> >> Due to very limited space in the setup_header this patch series introduces
> >> new
>
On 07.11.2019 12:35, George Dunlap wrote:
> On 11/6/19 3:19 PM, Jan Beulich wrote:
>> In order for individual IOMMU drivers (and from an abstract pov also
>> architectures) to be able to adjust their data structures ahead of time
>> when they might cover only a sub-range of all possible GFNs,
On 07.11.2019 13:10, George Dunlap wrote:
> On 11/7/19 11:47 AM, Jan Beulich wrote:
>> On 07.11.2019 12:35, George Dunlap wrote:
>>> On 11/6/19 3:19 PM, Jan Beulich wrote:
In order for individual IOMMU drivers (and from an abstract pov also
architectures) to be able to adjust their data
Hello,
Current code in clear_IO_APIC_pin doesn't properly deal with IO-APIC
entries already configured to point to entries in the iommu interrupt
remapping table, fix this.
Roger Pau Monne (2):
x86/ioapic: remove usage of TRUE and FALSE in clear_IO_APIC_pin
x86/ioapic: don't use raw entry
clear_IO_APIC_pin can be called after the iommu has been enabled, and
using raw entry reads and writes will result in a misconfiguration of
the entries already setup to use the interrupt remapping table. This
fixes the following panic seen on AMD Rome boxes:
(XEN) [ 10.082154] ENABLING IO-APIC
And instead use proper booleans. No functional change intended.
Signed-off-by: Roger Pau Monné
---
Cc: Juergen Gross
---
xen/arch/x86/io_apic.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c
index
On Thu, Nov 07, 2019 at 04:28:56PM +0100, Jan Beulich wrote:
> On 07.11.2019 16:06, Roger Pau Monne wrote:
> > clear_IO_APIC_pin can be called after the iommu has been enabled, and
> > using raw entry reads and writes will result in a misconfiguration of
> > the entries already setup to use the
On Wed, Nov 06, 2019 at 08:10:47AM -0800, Stefano Stabellini wrote:
> On Wed, 6 Nov 2019, Wei Liu wrote:
> > On Tue, Nov 05, 2019 at 03:51:13PM -0800, Stefano Stabellini wrote:
> > > Actually, pygrub cross-compiles without issues. The cross-compilation
> > > work-around goes back to 2005 and it
flight 143701 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143701/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-examine 11 examine-serial/bootloader fail in 143515 pass in
143701
test-armhf-armhf-xl-rtds
On Wed, Nov 6, 2019 at 11:46 PM Alexandru Stefan ISAILA
wrote:
>
>
>
> On 06.11.2019 23:06, Tamas K Lengyel wrote:
> > On Wed, Nov 6, 2019 at 7:35 AM Alexandru Stefan ISAILA
> > wrote:
> >>
> >> By default the sve bits are not set.
> >> This patch adds a new hypercall,
On 11/6/19 3:19 PM, Jan Beulich wrote:
> In order for individual IOMMU drivers (and from an abstract pov also
> architectures) to be able to adjust their data structures ahead of time
> when they might cover only a sub-range of all possible GFNs, introduce
> a notification call used by various
On Thu, Nov 07, 2019 at 04:46:32PM +0100, Roger Pau Monné wrote:
> On Thu, Nov 07, 2019 at 04:28:56PM +0100, Jan Beulich wrote:
> > On 07.11.2019 16:06, Roger Pau Monne wrote:
> > > clear_IO_APIC_pin can be called after the iommu has been enabled, and
> > > using raw entry reads and writes will
On 07.11.2019 12:03, George Dunlap wrote:
> On 11/7/19 7:20 AM, Jan Beulich wrote:
>> On 24.10.2019 15:31, Jan Beulich wrote:
>>> The .file assembler directives generated by the compiler do not include
>>> any path components (gcc) or just the ones specified on the command line
>>> (clang, at
On 07/11/2019 07:36, Jan Beulich wrote:
> On 06.11.2019 18:31, Andrew Cooper wrote:
>> On 06/11/2019 15:16, Jan Beulich wrote:
>>> update_paging_mode() in the AMD IOMMU code expects to be invoked with
>>> the PCI devices lock held. The check occurring only when the mode
>>> actually needs
Hi all,
quick reminder re agenda items. What I have so far is at
https://cryptpad.fr/pad/#/2/pad/edit/SkeU+Z5J9WIIU9ZsXlojiXcQ/
C.1) Any more 4.13 coordination (Juergen)
C.2) Volunteers/suggestions for Release Managers for 4.13 (Lars / Juergen)
C.3) 4.13 Release Notes / Blog Post / Feature
flight 143789 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143789/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail
REGR. vs. 143023
Hi all,
I tripped over the fact that
https://www.timeanddate.com/worldclock/meetingdetails.htm uses UTC as fixed
point whereas my calendar uses the local time as fixed point, so the meeting
mistakenly got pushed an hour earlier when DST finished. The correct time
(which should correspond to
On 11/7/19 11:47 AM, Jan Beulich wrote:
> On 07.11.2019 12:35, George Dunlap wrote:
>> On 11/6/19 3:19 PM, Jan Beulich wrote:
>>> In order for individual IOMMU drivers (and from an abstract pov also
>>> architectures) to be able to adjust their data structures ahead of time
>>> when they might
flight 143778 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143778/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 143158
flight 143834 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143834/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 142849
On Tue, Nov 05, 2019 at 10:16:46AM -0500, Boris Ostrovsky wrote:
> > So, I suppose it can be relaxed to a null test and a WARN_ON that it
> > hasn't changed?
>
> You mean
>
> if (use_ptemod) {
> WARN_ON(map->vma != vma);
> ...
>
>
> Yes, that sounds good.
I amended my copy of
On 11/7/19 12:06 PM, Jason Gunthorpe wrote:
...
Also, it is best moved down to be next to the new MNR structs, so that all the
MNR stuff is in one group.
I agree with Jerome, this enum is part of the 'struct
mmu_notifier_range' (ie the description of the invalidation) and it
doesn't really
On 07.11.19 19:22, David Hildenbrand wrote:
Am 07.11.2019 um 16:40 schrieb Dan Williams :
On Thu, Oct 24, 2019 at 5:12 AM David Hildenbrand wrote:
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
KVM has this weird use case that you can map anything from
flight 143846 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143846/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail REGR. vs. 139698
Dear Community Members,
Juergen will be stepping down as Release Manager after Xen 4.13 has been
delivered, following the 4.11 and 4.12 release. Release managers prior to
Juergen were Julien Grall, Konrad Wilk, Wei Liu and George Dunlap. We are
looking for active community members to follow
On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote:
> >
> > Extra credit: IMHO, this clearly deserves to all be in a new
> > mmu_range_notifier.h
> > header file, but I know that's extra work. Maybe later as a follow-up patch,
> > if anyone has the time.
>
> The range notifier
On Thu, Nov 07, 2019 at 08:11:06PM +, Jason Gunthorpe wrote:
> On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote:
>
> > >
> > > Extra credit: IMHO, this clearly deserves to all be in a new
> > > mmu_range_notifier.h
> > > header file, but I know that's extra work. Maybe later as
flight 143848 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143848/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs.
133580
flight 143851 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143851/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-raw 19 guest-start/debian.repeat fail REGR. vs. 143190
On Thu, Nov 7, 2019 at 2:07 PM David Hildenbrand wrote:
>
> On 07.11.19 19:22, David Hildenbrand wrote:
> >
> >
> >> Am 07.11.2019 um 16:40 schrieb Dan Williams :
> >>
> >> On Thu, Oct 24, 2019 at 5:12 AM David Hildenbrand
> >> wrote:
> >>>
> >>> Right now, ZONE_DEVICE memory is always set
> Am 07.11.2019 um 16:40 schrieb Dan Williams :
>
> On Thu, Oct 24, 2019 at 5:12 AM David Hildenbrand wrote:
>>
>> Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
>> change that.
>>
>> KVM has this weird use case that you can map anything from /dev/mem
>> into the guest.
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Monday, November 4, 2019 5:47 PM
>
> On Sat, Nov 02, 2019 at 07:48:06AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monné [mailto:roger@citrix.com]
> > > Sent: Thursday, October 31, 2019 11:23 PM
> > >
> > > On Thu, Oct 31,
On 11/7/19 3:36 PM, Jason Gunthorpe wrote:
> On Tue, Nov 05, 2019 at 10:16:46AM -0500, Boris Ostrovsky wrote:
>
>>> So, I suppose it can be relaxed to a null test and a WARN_ON that it
>>> hasn't changed?
>> You mean
>>
>> if (use_ptemod) {
>> WARN_ON(map->vma != vma);
>> ...
>>
>>
On Wed, 6 Nov 2019 at 02:24, Julian Tuminaro wrote:
>
> From: "julian.tumin...@gmail.com"
>
>
> Current implementation of find_os is based on the hard-coded values for
> different Windows version. It uses the value for get the address to
> start looking for DOS header in the given specified
Hi all,
minutes are attached or at
https://cryptpad.fr/pad/#/2/pad/view/7l3a4mhZTU4xs0GE415OXiAj0ScKl39xdQ9wm0cwASs/embed/present/
Regards
Lars
On 07/11/2019, 07:24, "Lars Kurth" wrote:
Hi all,
quick reminder re agenda items. What I have so far is at
On Fri, Nov 08, 2019 at 12:32:25AM +, Jason Gunthorpe wrote:
> On Thu, Nov 07, 2019 at 04:04:08PM -0500, Jerome Glisse wrote:
> > On Thu, Nov 07, 2019 at 08:11:06PM +, Jason Gunthorpe wrote:
> > > On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote:
> > >
> > > > >
> > > > >
On Thu, Nov 07, 2019 at 04:04:08PM -0500, Jerome Glisse wrote:
> On Thu, Nov 07, 2019 at 08:11:06PM +, Jason Gunthorpe wrote:
> > On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote:
> >
> > > >
> > > > Extra credit: IMHO, this clearly deserves to all be in a new
> > > >
Hi all,
I have received informal advice
On 21/10/2019, 06:54, "Artem Mygaiev" wrote:
> Before we ask Xen FuSA contributors to invest in documentation to
> be presented as legally-valid evidence for certification, we should
> ask a certified lawyer for their formal opinion on the
On Wed, Nov 06, 2019 at 04:23:21PM -0800, John Hubbard wrote:
> Nice design, I love the seq foundation! So far, I'm not able to spot anything
> actually wrong with the implementation, sorry about that.
Alas :( I feel there must be a bug in here still, but onwards!
One of the main sad points
79 matches
Mail list logo
