date:20150909

On Wed, Sep 09, 2015 at 04:23:02PM +0100, Ian Jackson wrote:
> Set debug ?= n, in preperation for late RCs and eventual release.
> 
> Signed-off-by: Ian Jackson 
> CC: Wei Liu 

Release-acked-by: Wei Liu 

> ---
>  Config.mk |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Config.mk b/Config.mk
> index 51bcf5f..403d0fd 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -17,7 +17,7 @@ or   = $(if $(strip $(1)),$(1),$(if $(strip 
> $(2)),$(2),$(if $(strip $(3)),$(
>  -include $(XEN_ROOT)/.config
>  
>  # A debug build of Xen and tools?
> -debug ?= y
> +debug ?= n
>  debug_symbols ?= $(debug)
>  
>  # Test coverage support
> -- 
> 1.7.10.4

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [OSSTEST PATCH] production-config: Update TftpDiVersion

2015-09-09 Thread Ian Jackson

I have already run mg-debian-installer-update-all

Signed-off-by: Ian Jackson 
---
 production-config |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/production-config b/production-config
index 052314d..3c5bc8d 100644
--- a/production-config
+++ b/production-config
@@ -87,7 +87,7 @@ TftpPxeTemplatesReal pxelinux.cfg/%ipaddrhex%
 
 TftpPxeGroup osstest
 # Update with ./mg-debian-installer-update(-all)
-TftpDiVersion 2015-06-23
+TftpDiVersion 2015-09-07
 
 # These should normally be the same.
 # Update with ./mg-cpu-microcode-update
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 09/31] xen/arm: ITS: Add APIs to add and assign device

On Wed, 2015-09-09 at 14:44 +0100, Julien Grall wrote:
> On 09/09/15 14:28, Ian Campbell wrote:
> > On Thu, 2015-09-03 at 18:34 +0100, Julien Grall wrote:
> > > @@ -522,6 +535,205 @@ static void its_lpi_free(struct its_device
> > > *dev)
> > > >  xfree(dev->event_map.lpi_map);
> > > >  }
> > > >  
> > > > +static void its_discard_lpis(struct its_device *dev, u32 ids)
> > > > +{
> > > > +int i;
> > > > +
> > > 
> > > I would have expected a function more complex than that. If you
> > > discard
> > > the LPIs, you also need to free the MSI desc and potentially reset
> > > the
> > > IRQ desc.
> > > 
> > > Otherwise you will left the irq_desc in an unknown state for the next
> > > one.
> > 
> > But discard != free? (or at least "discard" has a specific meaning in
> > its).
> 
> In the ITS, discard means removing the mapping from the MSI (eventID) to
> the LPI.

Table 6-6 in the gic arch spec (ARM IHI 0069A (ID060315)) says about the
discard ITS command "Translates the event defined by EventID and DeviceID
and instructs the appropriate Redistributor to remove the pending state of
the interrupt. It also ensures that any caching in the Redistributors
associated with a specific EventID is consistent with the configuration
held in memory."

And section 6.3.4 seems to agree _except_ for the pseudo code which does
indeed seem to include setting the corresponding ITE entry to invalid.

Given that the pseudocode for CLEAR appears to match how DISCARD is
decribed (infact the descrpitions of CLEAR and DISCARD look functionally
identical to me) I'm inclined to believe the pseudo code for DISCARD, i.e.
the docs are misleading and you are correct that DISCARD is more than just
clearing the pending state.

The older PRD03-GENC-010745 24.0 looks to be more correct.

So sorry for the noise, that'll teach me to believe docs.

> > > > +xfree(dev->event_map.col_map);
> > > > +xfree(dev);
> > > > +}
> > > > +
> > > > +static struct its_device *its_alloc_device(u32 devid, u32 nr_ites,
> > > > +   struct dt_device_node
> > > > *dt_its)
> > > > +{
> > > > +struct its_device *dev;
> > > > +paddr_t *itt;
> > > 
> > > Why paddr_t? You only allocate it and pass directly to the hardware.
> > 
> > paddr_t seems correct, it the fact that it is a paddr_t * (i.e. a
> > pointer)
> > which seems odd to me. I think you commented the same thing on dev
> > ->itt_addr which is where this ends up assigned.
> 
> With the current usage, we store the result of xmalloc in the itt
> variable. So it's a pointer to a virtual address not a paddr_t.

Ah, in that case it should indeed have some other type.

> If we decide to use paddr_t, then we should also update the code.
> Although, the Linux ITS code is using void * in order to store the
> pointer. So I'd like to keep the same in order to avoid differing too
> much for Linux (though with all this coding style it would be difficult
> to backport code).
> 
> Regards,
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [linux-3.10 bisection] complete test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm

branch xen-unstable
xen branch xen-unstable
job test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
test debian-hvm-install

Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
  Bug introduced:  292f53675e097ca807df744fb6fd39211a134bf7
  Bug not present: 3f2c206ae6f9e1005ac7f092e8d65c17307a0d59


  commit 292f53675e097ca807df744fb6fd39211a134bf7
  Author: Marek Marczykowski-GÃ³recki 
  Date:   Fri Jun 26 03:28:24 2015 +0200

  xen/gntdevt: Fix race condition in gntdev_release()

  commit 30b03d05e07467b8c6ec683ea96b5bffcbcd3931 upstream.

  While gntdev_release() is called the MMU notifier is still registered
  and can traverse priv->maps list even if no pages are mapped (which is
  the case -- gntdev_release() is called after all). But
  gntdev_release() will clear that list, so make sure that only one of
  those things happens at the same time.

  Signed-off-by: Marek Marczykowski-GÃ³recki 

  Signed-off-by: David Vrabel 
  Signed-off-by: Greg Kroah-Hartman 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-3.10/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-3.10/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm.debian-hvm-install
 --summary-out=tmp/61705.bisection-summary --basis-template=60670 
--blessings=real,real-bisect linux-3.10 
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm debian-hvm-install
Searching for failure / basis pass:
 61268 fail [host=italia0] / 60670 [host=huxelrebe1] 60656 [host=chardonnay1] 
60548 [host=rimava1] 59440 [host=godello1] 59395 [host=huxelrebe0] 59112 ok.
Failure / basis pass flights: 61268 / 59112
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 5a427ce18a14d6b85972c62196a8f10c3624d74a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
5cdde31eacdd288359746019ad05cac8ed5d9f70 
b05befcbea71a979509ce04f02929969a790c923 
801ab48e5556cb54f67e3cb57f077f47e8663ced
Basis pass c48465423908a8955cd6de09b871161324cf5205 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
3e2e51ecc1120bd59537ed19b6bc7066511c7e2e 
c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 
c40317f11b3f05e7c06a2213560c8471081f2662
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#c48465423908a8955cd6de09b871161324cf5205-5a427ce18a14d6b85972c62196a8f10c3624d74a
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/staging/qemu-xen-unstable.git#3e2e51ecc1120bd59537ed19b6bc7066511c7e2e-5cdde31eacdd288359746019ad05cac8ed5d9f70
 
git://xenbits.xen.org/staging/qemu-upstream-unstable.git#c4a962ec0c61aa9b860a3635c8424472e6c2cc2c-b05befcbea71a979509ce04f02929969a790c923
 
git://xenbits.xen.org/xen.git#c40317f11b3f05e7c06a2213560c8471081f2662-801ab48e5556cb54f67e3cb57f077f47e8663ced
>From git://cache:9419/git://xenbits.xen.org/xen
   fdb0a9e..fd5964a  staging-> origin/staging
   33ad644..cb5599f  staging-4.6 -> origin/staging-4.6
Loaded 17993 nodes in revision graph
Searching for test results:
 59067 [host=godello0]
 59051 [host=chardonnay1]
 59112 pass c48465423908a8955cd6de09b871161324cf5205 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
3e2e51ecc1120bd59537ed19b6bc7066511c7e2e 
c4a962ec0c61aa9b860a3635c8424472e6c2cc2c 
c40317f11b3f05e7c06a2213560c8471081f2662
 59395 [host=huxelrebe0]
 59440 [host=godello1]
 60548 [host=rimava1]
 60670 [host=huxelrebe1]
 60656 [host=chardonnay1]
 60827 fail irrelevant
 60790 fail irrelevant
 60748 fail irrelevant
 60950 fail 5a427ce18a14d6b85972c62196a8f10c3624d74a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
7f057440b31da38196e3398fd1b618fc36ad97d6 
b05befcbea71a979509ce04f02929969a790c923 
7b99717f62caeac08eea224a177cd28f047ac4b5
 60865 fail irrelevant
 60992 fail 5a427ce18a14d6b85972c62196a8f10c3624d74a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860

Re: [Xen-devel] [PATCH v6 24/31] xen/arm: ITS: Add GICR register emulation

2015-09-09 Thread Julien Grall

On 09/09/15 14:55, Ian Campbell wrote:
>>> Based on the spec, those 2 checks are wrong and make impossible to use
>>> LPIs. Please test this patch series before sending it on the ML.
>>
>> Why do you think so?.
> 
> Consider which LPI is the subject of the word at the address pointed to by
> GICR_PROPBASER. I think it is LPI==0 (== IRQ 8192), whereas this code
> suggests that you think the entry for LPI==0 is at offset 8192 in the prop
> table, which I don't think is correct.

For the spec section: 6.1.2 in ARM IHI 0069A.

Regards,

-- 
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [OSSTEST PATCH] production-config: Update TftpDiVersion

On Wed, 2015-09-09 at 16:46 +0100, Ian Jackson wrote:
> I have already run mg-debian-installer-update-all
> 
> Signed-off-by: Ian Jackson 

Acked + pushed to pretest.

I also copied */wheezy-2015-09-07 to the Cambridge instance and modified
that config too.

> ---
>  production-config |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/production-config b/production-config
> index 052314d..3c5bc8d 100644
> --- a/production-config
> +++ b/production-config
> @@ -87,7 +87,7 @@ TftpPxeTemplatesReal pxelinux.cfg/%ipaddrhex%
>  
>  TftpPxeGroup osstest
>  # Update with ./mg-debian-installer-update(-all)
> -TftpDiVersion 2015-06-23
> +TftpDiVersion 2015-09-07
>  
>  # These should normally be the same.
>  # Update with ./mg-cpu-microcode-update

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Patch V1 2/3] xen/usb: add capability for passing through isoc jobs to host devices

2015-09-09 Thread Gerd Hoffmann

> > Why multiple small iovecs instead of one big iovec?
> 
> The guest buffer might span multiple physical non contiguous pages.

Sure, thats why we have iovecs in the first place.

>  I
> don't want to copy data to a new buffer due to performance reasons
> (there is already at least one copy operation done by qemu).

We can walk the iovec and fill the libusb struct with the pointers and
lengths instead of using usb_copy_packet ...

> > usb_host_req_complete_iso_xen() returns a single status for the whole
> > USBPacket anyway ...
> 
> I need status per iso request, and libusb does deliver that.

So one usbpacket per iso request should make this work.  And of you
enable pipelining for the endpoint qemu allows multiple outstanding
async packages, so you can queue up a batch of requests ...

cheers,
  Gerd



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen/domctl: lower loglevel of XEN_DOMCTL_memory_mapping

2015-09-09 Thread Konrad Rzeszutek Wilk

On Wed, Sep 09, 2015 at 08:33:52AM -0600, Jan Beulich wrote:
> >>> On 09.09.15 at 16:20,  wrote:
> > Perhaps the solution is remove the first printk(s) and just have them
> > once the operation has completed? That may fix the outstanding tasklet
> > problem?
> 
> Considering that this is a tool stack based retry, how would the
> hypervisor know when the _whole_ operation is done?

I was merely thinking of moving the printk _after_ the map_mmio_regions
so there wouldn't be any outstanding preemption points in map_mmio_regions
(so it can at least do the 64 PFNs).

But going forward a couple of ideas:

 - The 64 limit was arbitrary. It could have been 42 or PFNs / 
num_online_cpus(),
   or actually finding out the size of the BAR and figuring the optimal
   case so that it will be done under 1ms. Or perhaps just provide an
   boot time parameter for those that really are struggling with this.

 - Perhaps add a new API to the P2M code so it can do the operations
   in batches. Our map_mmio_region iterates over every PFN which is
   surely not efficient. Some batching could help? Maybe? What other
   code could benefit from this? Would the boot-time creation of IOMMU
   page-tables also help with this (which takes 10 minutes on a 1TB box
   BTW)

 - This printk can be altogether removed in the hypervisor and moved
   in the toolstack. That is the libxl xc_domain_add_to_physmap
   could itself use the logging facility (xc_report?) the action.
   
> 
> Jan
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen-blkback: free requests on disconnection

2015-09-09 Thread Konrad Rzeszutek Wilk

On Tue, Sep 08, 2015 at 12:43:41PM +0200, Roger Pau Monné wrote:
> El 07/09/15 a les 13.35, Bob Liu ha escrit:
> > 
> > On 09/07/2015 07:10 PM, Julien Grall wrote:
> >> On 07/09/15 07:07, Bob Liu wrote:
> >>> Hi Julien,
> >>
> >> Hi Bob,
> >>
> >>> On 09/04/2015 09:51 PM, Julien Grall wrote:
>  Hi Roger,
> 
>  On 04/09/15 11:08, Roger Pau Monne wrote:
> > Request allocation has been moved to connect_ring, which is called every
> > time blkback connects to the frontend (this can happen multiple times 
> > during
> > a blkback instance life cycle). On the other hand, request freeing has 
> > not
> > been moved, so it's only called when destroying the backend instance. 
> > Due to
> > this mismatch, blkback can allocate the request pool multiple times, 
> > without
> > freeing it.
> >
> > In order to fix it, move the freeing of requests to 
> > xen_blkif_disconnect to
> > restore the symmetry between request allocation and freeing.
> >
> > Reported-by: Julien Grall 
> > Signed-off-by: Roger Pau Monné 
> > Cc: Julien Grall 
> > Cc: Konrad Rzeszutek Wilk 
> > Cc: Boris Ostrovsky 
> > Cc: David Vrabel 
> > Cc: xen-de...@lists.xenproject.org
> 
>  The patch is fixing my problem when using UEFI in the guest. Thank you!
> 
> >>>
> >>> Could you please explain the problem you met a bit more?
> >>> So that I can know back port this patch if met similar issue.
> >>
> >> This is related to commit 86839c56dee28c315a4c19b7bfee450ccd84cd25
> >> "xen/block: add multi-page ring support" (Roger, it may be worth to
> >> indicate the offending commit in you commit message).
> >>
> >> When starting a guest using UEFI. After the domain is destroyed I get
> >> the following warning from blkback:
> >>
> >>
> >> [ cut here ]
> >> WARNING: CPU: 2 PID: 95 at
> >> /home/julien/works/linux/drivers/block/xen-blkback/xenbus.c:274
> >> xen_blkif_deferred_free+0x1f4/0x1f8()
> >> Modules linked in:
> >> CPU: 2 PID: 95 Comm: kworker/2:1 Tainted: GW   4.2.0 #85
> >> Hardware name: APM X-Gene Mustang board (DT)
> >> Workqueue: events xen_blkif_deferred_free
> >> Call trace:
> >> [] dump_backtrace+0x0/0x124
> >> [] show_stack+0x10/0x1c
> >> [] dump_stack+0x78/0x98
> >> [] warn_slowpath_common+0x9c/0xd4
> >> [] warn_slowpath_null+0x14/0x20
> >> [] xen_blkif_deferred_free+0x1f0/0x1f8
> >> [] process_one_work+0x160/0x3b4
> >> [] worker_thread+0x140/0x494
> >> [] kthread+0xd8/0xf0
> >> ---[ end trace 6f859b7883c88cdd ]---
> >>
> >> This is because the allocation of the requests are done during the
> >> connection but the free is done when the domain is destroyed. Therefore
> >> if the domain is re-initializing the connection (because UEFI or PV Grub
> >> is used), the request won't be free and kept until the end.
> >>
> > 
> > Thank you!
> > Roger, I think it's better to have this information in your commit message 
> > too.
> 
> Konrad, would you like me to resend the patch with the modified commit
> message, or do you plan to amend it yourself while committing?

I will amend it. Thanks!
> 
> Roger.
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 10/11] x86/intel_pstate: support the use of intel_pstate in pmstat.c

2015-09-09 Thread Wang, Wei W

On 09/09/2015 21:12,  Jan Beulich wrote:
>>> On 09.09.15 at 14:56,  wrote:
> Can you please explain more why it doesn't scale? 
> From my point of view, any other future value representation can be 
> passed from the producer to the related consumer through this method.

> Did you read all of my earlier replies? I already said there "Just consider 
> what happens to the code when we end up gaining a few 
> more drivers providing percentage values, and perhaps another one providing a 
> third variant of output representation."

Yes, I have read that. I am not sure if I got your point, but my meaning was 
when we add new drivers to the code, e.g. xx_pstate driver, we can still have 
the name, "xx_pstate", assigned to "p_cpufreq->scaling_driver" to distinguish 
one another. If the driver uses a different variant of output representation, 
which cannot be held by " uint32_t scaling_max_perf" (it needs "uint64_t" for 
example, then that driver developer needs to add a new field here like  " 
uint64_t scaling_max_perf_xx").
What is the scaling problem? 

Best,
Wei

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen/domctl: lower loglevel of XEN_DOMCTL_memory_mapping

2015-09-09 Thread Malcolm Crossley

On 09/09/15 15:50, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 09, 2015 at 08:33:52AM -0600, Jan Beulich wrote:
> On 09.09.15 at 16:20,  wrote:
>>> Perhaps the solution is remove the first printk(s) and just have them
>>> once the operation has completed? That may fix the outstanding tasklet
>>> problem?
>>
>> Considering that this is a tool stack based retry, how would the
>> hypervisor know when the _whole_ operation is done?
> 
> I was merely thinking of moving the printk _after_ the map_mmio_regions
> so there wouldn't be any outstanding preemption points in map_mmio_regions
> (so it can at least do the 64 PFNs).
> 
> But going forward a couple of ideas:
> 
>  - The 64 limit was arbitrary. It could have been 42 or PFNs / 
> num_online_cpus(),
>or actually finding out the size of the BAR and figuring the optimal
>case so that it will be done under 1ms. Or perhaps just provide an
>boot time parameter for those that really are struggling with this.

The issue of it taking a long time to map a large BAR is caused by the 
unconditional
memory_type_changed call at the bottom of XEN_DOMCTL_memory_mapping function.

The memory_type_changed call results in a full data cache flush on VM with a 
PCI device
assigned.

We have seen this overhead cause a 1GB BAR to take 20 seconds to map it's MMIO.

If the 64 limit was arbitrary then I would suggest increasing it to at least 
1024 so that
at least 4M of BAR can be mapped in one go and it reduces the overhead by a 
factor of 16.

Currently the toolstack attempts lower and lower powers of 2 size's of the MMIO 
region to be mapped
until the hypercall succeeds.

Is it not clear to me why we have an unconditional call to memory_type_changed 
in the domctl.
Can somebody explain why it can't be made condition on errors?

Malcolm

> 
>  - Perhaps add a new API to the P2M code so it can do the operations
>in batches. Our map_mmio_region iterates over every PFN which is
>surely not efficient. Some batching could help? Maybe? What other
>code could benefit from this? Would the boot-time creation of IOMMU
>page-tables also help with this (which takes 10 minutes on a 1TB box
>BTW)
> 
>  - This printk can be altogether removed in the hypervisor and moved
>in the toolstack. That is the libxl xc_domain_add_to_physmap
>could itself use the logging facility (xc_report?) the action.
>
>>
>> Jan
>>
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] EDK II & GPL - Re: [edk2] OVMF BoF @ KVM Forum 2015

On 2015-09-09 01:57:51, Laszlo Ersek wrote:
> On 08/10/15 18:24, Laszlo Ersek wrote:
> > Hi.
> > 
> > Let's do an OVMF BoF at this year's KVM Forum too.
> 
> Here's a preliminary task list, after some off-list discussion (I tried
> to incorporate comments):
> 
> - create GPL'd fork called "ovmf" for expediting virt development
>   (OvmfPkg, ArmVirtPkg)
>   - maybe leverage the feature under
>  for
> setting up a separate "tianocore/edk2-gpl" repo, for GPL'd
> contributions [Jordan]
> - repo separation by license could make things harder for packagers
>   and QEMU bundling [Laszlo]

I would like OVMF to follow a plan for GPL that the whole EDK II
community decides on.

I would also like to see EDK II add a (permissively licensed; BSD,
MIT, etc) DriverPkg (DriversPkg?). We discussed this on the list
recently:

http://thread.gmane.org/gmane.comp.bios.tianocore.devel/17544/focus=676

So, related to this, I wonder how the community would feel about a
GplDriverPkg. Would the community allow it as a new package in EDK II
directly, or would a separate repo be required?

With regards to adding it directly into the EDK II tree, here are some
potential concerns that I might anticipate hearing from the community:

* It will make it easier for contributors to choose GPL compared to a
  permissive license, thereby limiting some users of the contribution

* GPL code will more easily be copied into the permissively licensed
  packages

* Some might refuse to look at EDK II entirely if it has a directory
  with GPL source code in it

Of these, I personally only sympathize with the first.

Regarding the separate OVMF repo, my hope is that it is more of a OVMF
specific working area, rather than a 'GPL OVMF'. For example, patches
or features that we've not yet figured out how to upstream, but we
hopefully plan to.

Additionally, it makes sense to use it as needed for OVMF specific
releases. (Ie, OVMF release tags)

-Jordan

> - document the rules / justification for "ovmf" (licensing
>   conflicts, non-technical blockage on edk2 etc).
> - No new mailing list needed
> - push RH's downstream-only patches to "ovmf", wherever that makes
>   sense
> - remove encumbered FAT driver
> - import Peter Batard's GPL r/o FAT driver port of GRUB's
> - secure OpenSSL linking exception for the former from the copyright
>   holders (Peter Batard, GRUB project)
> - "ovmf" should be periodically rebased / should fetch+merge edk2 as
>   master (arguments both for and against merging); distros should
>   then track "ovmf" as their upstream, not edk2
> - get OVMF into Fedora (as pkg) and QEMU (as bundled binary)
> - do OVMF releases, maybe in sync with QEMU's releases
>   - we can probably build from known good revisions from git [Alex]
> - revive Q35 SATA driver work / poke Reza
>   - Hannes and Gabriel have refreshed patches, but their versions differ
> 
> ___
> edk2-devel mailing list
> edk2-de...@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH for 4.6] configure: don't silently disable systemd support

Originally when user runs ./configure --enable-systemd and systemd
development library is not available the build system silently disables
systemd support. This is not in line with normal expectation.

Instead, configure should error out when user has asked for systemd
support but development libraries can't be found.

Reported-by: George Dunlap 
Signed-off-by: Wei Liu 
---
Please rerun ./autogen.sh.
---
 m4/systemd.m4 | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/m4/systemd.m4 b/m4/systemd.m4
index 8284993..84508a1 100644
--- a/m4/systemd.m4
+++ b/m4/systemd.m4
@@ -85,7 +85,11 @@ AC_DEFUN([AX_CHECK_SYSTEMD], [
AC_DEFINE([HAVE_SYSTEMD], [1], [Systemd available and enabled])
systemd=y
AX_CHECK_SYSTEMD_LIBS()
-   ],[systemd=n])
+   ],[
+   AS_IF([test "x$enable_systemd" != "x"],
+   [AC_MSG_ERROR([Unable to find systemd development 
library])],
+   [systemd=n])
+   ])
],[systemd=n])
 ])
 
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015


> On Sep 9, 2015, at 10:57 AM, Jordan Justen  wrote:
> 
> On 2015-09-09 10:04:50, Andrew Fish wrote:
>> 
>>> On Sep 9, 2015, at 9:17 AM, Jordan Justen  wrote:
>>> 
>>> So, related to this, I wonder how the community would feel about a
>>> GplDriverPkg. Would the community allow it as a new package in EDK II
>>> directly, or would a separate repo be required?
>>> 
>> 
>> I think we would need a separate repo, like the FAT driver. That is
>> the only way to deal with the license issues.
> 
> There doesn't seem to be any guiding rules here. For example, I think
> some people are not comfortable with the FatBinPkg being in the tree
> due to the license.

I don’t think it is fair to look backwards to make this comparison 

A long time ago your co-workers decided to check some binaries in to make folks 
life easier. 
1) Tools compiled by VC++ that only run on Windows
2) Shell binary
3) FAT binary

I think the goal was one svn pull and no extra tools needed to install, build, 
and run NT32 on Windows. 

The source code was BSD so other than the FAT driver it is all compatible with 
a GPL project that wanted to import the code. That was good enough when this 
decision was made. 

I personally have no issue removing the binaries from the tree, especially the 
FAT driver if it causes issues for folks. I think that would imply the website, 
and any getting started collateral would need to get updated. 

> Why is that okay?
> 

It was OK, at the time. 

The intellectual property around FAT is a mess, but at least it is permissible 
to use it in (U)EFI to boot a system. 

>>> With regards to adding it directly into the EDK II tree, here are some
>>> potential concerns that I might anticipate hearing from the community:
>>> 
>>> * It will make it easier for contributors to choose GPL compared to a
>>> permissive license, thereby limiting some users of the contribution
>>> 
>>> * GPL code will more easily be copied into the permissively licensed
>>> packages
>>> 
>>> * Some might refuse to look at EDK II entirely if it has a directory
>>> with GPL source code in it
>>> 
>> 
>> Or have their rights to contribute revoked since this is a
>> fundamental change, and would require employees to get reauthorized
>> by their legal departments to contribute.
> 
> We've recently expanded beyond just allowing BSD code into the tree,
> and that appeared to be no big deal. No one brought this up as a
> fundamental change.
> 
> Just to be clear, are you saying Apple probably won't be able to
> contribute to EDK II if there is any GPL licensed code in the tree?
> (Even if it is contained in a clearly indicated package.) I guess
> using dual-licensed BSD/GPL is okay though?
> (EmbeddedPkg/Library/FdtLib)
> 

BSD compatible is OK. 

Thanks,

Andrew Fish

> -Jordan
> ___
> edk2-devel mailing list
> edk2-de...@lists.01.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel=BQICAg=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=Kmc0BLQJkt9XKCJf_d8PrrQXQ9eNhkkTmN6cq2RzIzo=gmyUS4K6xDQ0QIZyAv_DkOp_G9rMBrDpvqa_VV_4RTo=
>  


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.3-testing test] 61620: regressions - FAIL

flight 61620 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61620/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
60700
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate.2 fail REGR. 
vs. 60700
 test-amd64-i386-xl-qemuu-debianhvm-amd64 18 guest-start.2 fail REGR. vs. 60700

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-raw9 debian-di-installfail   like 60700
 test-amd64-i386-libvirt  11 guest-start  fail   like 60700
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 60700

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 test-amd64-amd64-xl-raw   9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu92dae02ba02166cfcce020cb71021a73903ada2f
baseline version:
 qemuu20c1b1812de98ed789d55e22a43a4700fb765596

Last test of basis60700  2015-08-14 10:50:55 Z   26 days
Failing since 60903  2015-08-27 01:40:43 Z   13 days2 attempts
Testing same since61620  2015-09-08 12:11:41 Z1 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Peter Lieven 

jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 fail
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt pass
 test-amd64-i386-libvirt  fail
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-libvirt-qcow2   pass
 test-amd64-i386-libvirt-qcow2pass
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-qcow2 pass
 test-amd64-amd64-libvirt-raw pass
 test-amd64-i386-libvirt-raw  pass
 test-amd64-amd64-xl-raw  fail
 test-amd64-i386-xl-raw   fail
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail
 test-amd64-amd64-libvirt-vhd pass
 test-amd64-i386-libvirt-vhd

[Xen-devel] [qemu-upstream-4.2-testing test] 61619: regressions - FAIL

flight 61619 qemu-upstream-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61619/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-qemuu-winxpsp3 16 guest-localmigrate/x10 fail REGR. vs. 60611

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 60611

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 21 leak-check/checkfail never pass

version targeted for testing:
 qemuu2a5956801545ff4122dc9551bcc4c4e3053f30ba
baseline version:
 qemuu138906105dd47b9dc6b1e5010e81fc606983dd75

Last test of basis60611  2015-08-06 01:42:11 Z   34 days
Testing same since61619  2015-09-08 12:11:08 Z1 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Peter Lieven 

jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-i386-xend-qemuu-winxpsp3  fail
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-i386-i386-xl-qemuu-winxpsp3 fail



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

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

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

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


Not pushing.


commit 2a5956801545ff4122dc9551bcc4c4e3053f30ba
Author: Peter Lieven 
Date:   Mon Jun 30 10:07:54 2014 +0200

ui/vnc: limit client_cut_text msg payload size

currently a malicious client could define a payload
size of 2^32 - 1 bytes and send up to that size of
data to the vnc server. The server would allocated
that amount of memory which could easily create an
out of memory condition.

This patch limits the payload size to 1MB max.

Please note that client_cut_text messages are currently
silently ignored.

Signed-off-by: Peter Lieven 
Signed-off-by: Gerd Hoffmann 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

> On Sep 9, 2015, at 3:24 PM, Jordan Justen  wrote:
> 
> On 2015-09-09 12:11:26, El-Haj-Mahmoud, Samer wrote:
>> The recent expansions beyond BSD where all permissive licenses (BSD
>> like) as far as I can tell.
>> 
>> I agree with Andrew, opening the door for GPL licensed code in EDK2
>> will have severe consequences for products that are built using
>> EDK2.
> 
> I don't think simply having a GplDriverPkg in the tree would have any
> consequences for a platform that doesn't use any code in that package.
> Obviously we could not make any core packages rely on that package.
> 

So you have a legal degree and are speaking on behalf of your employer on this 
subject? 

> This would just be a sanctioned, clear landing place for people that
> cannot, or will not provide their driver under a permissive license.
> 
> This license will limit who can use drivers from this package. For
> that reason, I hope that we will always ask if a contribution can be
> permissively licensed instead.
> 
> Personally, I would prefer a 2-clause BSD only tree for simplicity,
> but unfortunately, that sort of restriction has its own drawbacks as
> well. (frustrated contributors and less contributions)
> 
> FWIW, I don't mind if the consensus is that GplDriverPkg must live in
> a separate repo. But, it would be nice to hear a good reason why it
> must live elsewhere.

Because GPL is not a permissive license. An accidental git grep and copying 
some code can change the license of the code that gets the GPL code pasted into 
it. Thus having GPL code in the same repository as BSD code can end up 
accidentally converting BSD code to GPL code over time. If GPL was OK with 
everyone we would have started with GPL. The good thing is the BDS code is GPL 
compatible so it can be used for GPL code and bug fixes in the BDS code can be 
merged into to GPL code, but this is a one way operation. 

If you don’t believe me please feel free to sit down and have a long 
conversation with Intel IP lawyers.

> (And, why that doesn't also apply to FatBinPkg.)
> 

There is no IP leakage from a binary. This FAT driver is licensed for use with 
EFI, and given this is a EFI code base that seemed like a good thing. 

I don’t pretent to understand the GPL FAT thing, I guess it is some kind of 
civil disobedience. it does not mater what license you strap on the code the 
the device makers still have to “pay the man”. 

Thanks,

Andrew Fish

PS As I stated before I’m fine removing all the binaries from the main repo, as 
you don’t really want binaries in your production repo, and source level 
debugging is a nice feature and all. 

> -Jordan
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Jordan Justen
>> Sent: Wednesday, September 09, 2015 12:58 PM
>> To: Andrew Fish 
>> Cc: Lenny Szubowicz ; Karen Noel ; Ard 
>> Biesheuvel ; edk2-devel-01 
>> ; Reza Jelveh ; Alexander Graf 
>> ; qemu devel list ; Hannes Reinecke 
>> ; Gabriel L. Somlo (GMail) ; Peter Jones 
>> ; Peter Batard ; Gerd Hoffmann 
>> ; Cole Robinson ; Paolo Bonzini 
>> ; xen-devel@lists.xen.org; Laszlo Ersek 
>> ; Ademar de Souza Reis Jr. 
>> Subject: Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015
>> 
>> On 2015-09-09 10:04:50, Andrew Fish wrote:
>>> 
 On Sep 9, 2015, at 9:17 AM, Jordan Justen  
 wrote:

 So, related to this, I wonder how the community would feel about a
 GplDriverPkg. Would the community allow it as a new package in EDK
 II directly, or would a separate repo be required?

>>> 
>>> I think we would need a separate repo, like the FAT driver. That is
>>> the only way to deal with the license issues.
>> 
>> There doesn't seem to be any guiding rules here. For example, I
>> think some people are not comfortable with the FatBinPkg being in
>> the tree due to the license. Why is that okay?
>> 
 With regards to adding it directly into the EDK II tree, here are
 some potential concerns that I might anticipate hearing from the community:

 * It will make it easier for contributors to choose GPL compared to
 a  permissive license, thereby limiting some users of the
 contribution

 * GPL code will more easily be copied into the permissively licensed
 packages

 * Some might refuse to look at EDK II entirely if it has a directory
 with GPL source code in it

>>> 
>>> Or have their rights to contribute revoked since this is a fundamental
>>> change, and would require employees to get reauthorized by their legal
>>> departments to contribute.
>> 
>> We've

Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

On 2015-09-09 12:11:26, El-Haj-Mahmoud, Samer wrote:
> The recent expansions beyond BSD where all permissive licenses (BSD
> like) as far as I can tell.
> 
> I agree with Andrew, opening the door for GPL licensed code in EDK2
> will have severe consequences for products that are built using
> EDK2.

I don't think simply having a GplDriverPkg in the tree would have any
consequences for a platform that doesn't use any code in that package.
Obviously we could not make any core packages rely on that package.

This would just be a sanctioned, clear landing place for people that
cannot, or will not provide their driver under a permissive license.

This license will limit who can use drivers from this package. For
that reason, I hope that we will always ask if a contribution can be
permissively licensed instead.

Personally, I would prefer a 2-clause BSD only tree for simplicity,
but unfortunately, that sort of restriction has its own drawbacks as
well. (frustrated contributors and less contributions)

FWIW, I don't mind if the consensus is that GplDriverPkg must live in
a separate repo. But, it would be nice to hear a good reason why it
must live elsewhere. (And, why that doesn't also apply to FatBinPkg.)

-Jordan

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan 
> Justen
> Sent: Wednesday, September 09, 2015 12:58 PM
> To: Andrew Fish 
> Cc: Lenny Szubowicz ; Karen Noel ; Ard 
> Biesheuvel ; edk2-devel-01 
> ; Reza Jelveh ; Alexander Graf 
> ; qemu devel list ; Hannes Reinecke 
> ; Gabriel L. Somlo (GMail) ; Peter Jones 
> ; Peter Batard ; Gerd Hoffmann 
> ; Cole Robinson ; Paolo Bonzini 
> ; xen-devel@lists.xen.org; Laszlo Ersek 
> ; Ademar de Souza Reis Jr. 
> Subject: Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015
> 
> On 2015-09-09 10:04:50, Andrew Fish wrote:
> >
> > > On Sep 9, 2015, at 9:17 AM, Jordan Justen  
> > > wrote:
> > >
> > > So, related to this, I wonder how the community would feel about a
> > > GplDriverPkg. Would the community allow it as a new package in EDK
> > > II directly, or would a separate repo be required?
> > >
> >
> > I think we would need a separate repo, like the FAT driver. That is
> > the only way to deal with the license issues.
> 
> There doesn't seem to be any guiding rules here. For example, I
> think some people are not comfortable with the FatBinPkg being in
> the tree due to the license. Why is that okay?
> 
> > > With regards to adding it directly into the EDK II tree, here are
> > > some potential concerns that I might anticipate hearing from the 
> > > community:
> > >
> > > * It will make it easier for contributors to choose GPL compared to
> > > a  permissive license, thereby limiting some users of the
> > > contribution
> > >
> > > * GPL code will more easily be copied into the permissively licensed
> > > packages
> > >
> > > * Some might refuse to look at EDK II entirely if it has a directory
> > > with GPL source code in it
> > >
> >
> > Or have their rights to contribute revoked since this is a fundamental
> > change, and would require employees to get reauthorized by their legal
> > departments to contribute.
> 
> We've recently expanded beyond just allowing BSD code into the tree,
> and that appeared to be no big deal. No one brought this up as a
> fundamental change.
> 
> Just to be clear, are you saying Apple probably won't be able to
> contribute to EDK II if there is any GPL licensed code in the tree?
> (Even if it is contained in a clearly indicated package.) I guess
> using dual-licensed BSD/GPL is okay though?
> (EmbeddedPkg/Library/FdtLib)
> 
> -Jordan
> ___
> edk2-devel mailing list
> edk2-de...@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] OVMF BoF @ KVM Forum 2015

2015-09-09 Thread Laszlo Ersek

On 09/09/15 18:34, Ian Campbell wrote:
> On Wed, 2015-09-09 at 10:57 +0200, Laszlo Ersek wrote:
>> On 08/10/15 18:24, Laszlo Ersek wrote:
>>> Hi.
>>>
>>> Let's do an OVMF BoF at this year's KVM Forum too.
>>
>> Here's a preliminary task list
> 
> Thanks for including xen-devel in this. Was anyone from the Xen community
> present at the BoF (so far as you know)? Are there any minutes or anything
> like that for those interested in the discussion and reasoning rather than
> just the resulting action items?

Okay, second attempt at an answer. I *have* forgotten a great deal of
the sentences that were uttered at the BoF, but I mostly remember why we
wanted these things. :)

So let me see if I can elaborate on these (after all you are interested
in the reasoning in general, not just the discussions that I fail to
recall in detail):

>> , after some off-list discussion (I tried
>> to incorporate comments):
>>
>> - create GPL'd fork called "ovmf" for expediting virt development
>>   (OvmfPkg, ArmVirtPkg)
>>   - maybe leverage the feature under
>>  for
>> setting up a separate "tianocore/edk2-gpl" repo, for GPL'd
>> contributions [Jordan]
>> - repo separation by license could make things harder for packagers
>>   and QEMU bundling [Laszlo]

So in this item (which, in the above form, is already obsolete) I
managed to mix up three separate things. (But Jordan then went on and
clarified those today.)

(1) One thing is a virt-oriented fork of edk2, without explicit
licensing-oriented goals. The main purpose of this fork would be to
expedite virt development (OvmfPkg, ArmVirtPkg, and central packages on
which the former two depend).

It has sometimes occurred that an OVMF feature got tied up in
inter-maintainer disagreement, or other non-technical reasons (lack of
review capacity etc). This holds back virt development, plus it has the
potential to force downstreams (let's be concrete: Red Hat at minimum)
to carry some patches in downstream only.

The fork would accelerate things here. We'd have a set of rules for
committing to the fork (and the divergence would have to be rebased
periodically, or alternatively edk2 patches would have to be merged into
the fork, periodically).

Considering this purpose (ie. expediting virt development) in isolation,
the fork should stick with the original edk2 licenses.

(2) The *ability* to provide the end user with free software (in the
FSF's definition) or open source software (in the OSI's definition),
which the current FAT driver is regrettably none of, is extremely important.

Currently the only alternative that appears feasible is Peter Batard's
UEFI port of GRUB's read-only FAT driver. That driver comes under the
GPL, and therefore it ties into topic (3) below.

However, note that if the in-tree FAT driver were liberated (= made Free
or Open Source Software, for example by dropping the "Additional Terms"
from its license, thereby rendering it 3-BSDL), then goal (2) would be
immediately achieved, and it wouldn't tie into goal (3) below.

(3) Accommodating drivers that contributors can (or are willing to)
submit only under the GPL would be nice. For example there has been such
a contribution from Ludovic Rousseau, a smart card reader protocol
implementation (a port from Linux).

Jordan's most recent suggestion was to actually keep GPL'd drivers
within edk2, under "GplDriverPkg". This is being discussed on
edk2-devel, so I'll move on.

>> - document the rules / justification for "ovmf" (licensing
>>   conflicts, non-technical blockage on edk2 etc).
>> - No new mailing list needed

Okay, so the rules. They would go like (obviously they are up for
discussion):

- submit your stuff to edk2-devel as always

- work with the reviewers / maintainers

- if you get demonstrably stuck, due to inter-maintainer deadlock (ie.
  you'd be fine implementing either maintainer's request, but their
  requirements *together* are unsatisfiable, because they conflict),
  the patches can be committed to the fork, subject to review *for* the
  fork

- same if there's just no feedback for a patchset

- same if the patches are blocked due to non-technical criticism

- maybe the same if the technical feedback would require
  *disproportionate* effort (ie. cross-package refactorings), esp.
  involving client (=platform) packages that are not related to virt.
  We have to be careful with this one (it's not a blanket excuse, and
  arguments are bound to be somewhat subjective here), but such
  unjustified / overarching / disproportionate requirements can block
  the upstreaming of a feature (developed under a deadline) for good.

  Example: consider a refactoring that straddles DuetPkg or EmulatorPkg
  *and* MdeModulePkg, so that you can use a feature in OvmfPkg. You
  just turned a two week development effort into 6-8 weeks.

  No. You might not even have the environment to test DuetPkg. Etc.

- Initial set of committers to this

Re: [Xen-devel] [PATCH v6 16/18] vmx: Add some scheduler hooks for VT-d posted interrupts

2015-09-09 Thread Wu, Feng



> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, September 09, 2015 6:27 PM
> To: Wu, Feng
> Cc: Andrew Cooper; Dario Faggioli; George Dunlap; Tian, Kevin;
> xen-devel@lists.xen.org; Keir Fraser
> Subject: RE: [PATCH v6 16/18] vmx: Add some scheduler hooks for VT-d posted
> interrupts
> 
> >>> On 09.09.15 at 10:56,  wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Monday, September 07, 2015 8:55 PM
> >> >>> On 25.08.15 at 03:57,  wrote:
> >> > +
> >> > +/*
> >> > + * Delete the vCPU from the related block list
> >> > + * if we are resuming from blocked state.
> >> > + */
> >> > +if ( v->arch.hvm_vmx.pi_block_cpu != -1 )
> >> > +{
> >> > +spin_lock_irqsave(_cpu(pi_blocked_vcpu_lock,
> >> > +  v->arch.hvm_vmx.pi_block_cpu),
> >> flags);
> >> > +list_del_init(>arch.hvm_vmx.pi_blocked_vcpu_list);
> >>
> >> Shouldn't you set .pi_block_cpu back to -1 along with removing
> >> the vCPU from the list? Which then ought to allow using just
> >> list_del() here?
> >
> > Here is the story about using list_del_init() instead of list_del(), (the
> > same reason for using list_del_init() in pi_wakeup_interrupt() ).
> > If we use list_del(), that means we need to set .pi_block_cpu to
> > -1 after removing the vCPU from the block list, there are two
> > places where the vCPU is removed from the list:
> > - arch_vcpu_wake_prepare()
> > - pi_wakeup_interrupt()
> >
> > That means we also need to set .pi_block_cpu to -1 in
> > pi_wakeup_interrupt(), which seems problematic to me, since
> > .pi_block_cpu is used to get the per-CPU spin lock, it is not safe
> > to change it in pi_wakeup_interrupt(), maybe someone is using
> > it at the same time.
> >
> > And the check "if ( v->arch.hvm_vmx.pi_block_cpu != -1 )" here
> > is only used when .pi_block_cpu is set to -1 at the initial time.
> >
> > If you have any good suggestions about this, I will be all ears.
> 
> Latching pi_block_cpu into a local variable would take care of that
> part of the problem. Of course you then may also need to check
> that while waiting to acquire the lock pi_block_cpu didn't change.

Thanks for the suggestion! But I think it is not easy to "check
"that while waiting to acquire the lock pi_block_cpu didn't change".
Let's take the following pseudo code as an example:

int local_pi_block_cpu = v->arch.hvm_vmx.pi_block_cpu;

..

spin_lock_irqsave(_cpu(pi_blocked_vcpu_lock,
   local_pi_block_cpu), flags);
list_del(>arch.hvm_vmx.pi_blocked_vcpu_list);
spin_unlock_irqrestore(_cpu(pi_blocked_vcpu_lock,
   local_pi_block_cpu), flags);

If .pi_block_cpu is changed to -1 by others during calling list_del()
above, that means the vCPU is removed by others, then calling
list_del() here again would be problematic. I think there might be
other corner cases for this. So I suggest adding some comments
for list_del_init() as you mentioned below.

> And if that absolutely can't be made work correctly, these
> apparently strange uses of list_del_init() would each need a
> justifying comment.
> 
> >> > +do {
> >> > +old.control = new.control = pi_desc->control;
> >> > +
> >> > +/* Should not block the vCPU if an interrupt was posted for
> it.
> >> */
> >> > +if ( pi_test_on() )
> >> > +{
> >> > +spin_unlock_irqrestore(>arch.hvm_vmx.pi_lock,
> >> gflags);
> >> > +vcpu_unblock(v);
> >>
> >> Calling vcpu_unblock() in the middle of context_switch()? Why? And
> >> is this safe?
> >
> > I cannot see anything unsafe so far, can some scheduler maintainer
> > help to confirm it? Dario? George?
> 
> But first and foremost you ought to answer the "why".

I think if you think this solution is unsafe, you need point out where it is, 
not
just ask "is this safe ?", I don't think this is an effective comments.

Anyway, I go through the main path of the code as below, I really don't find
anything unsafe here.

context_switch() -->
pi_ctxt_switch_from() -->
vmx_pre_ctx_switch_pi() -->
vcpu_unblock() -->
vcpu_wake() -->
SCHED_OP(VCPU2OP(v), wake, v) -->
csched_vcpu_wake() -->
__runq_insert()
__runq_tickle()

If you continue to think it is unsafe, pointing out the place will be welcome!

> 
> >> And if really needed to cover something not dealt with
> >> elsewhere, wouldn't this need to happen _after_ having switched
> >> the notification mechanism below?
> >
> > If ON is set, we don't need to block the vCPU hence no need to change the
> > notification vector to the wakeup one, which is used when vCPU is blocked.
> >
> >>
> >> > +return;
> 
> Oh, right, I somehow managed to ignore the "return" here.
> 
> >> > +static

Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

On 2015-09-09 16:05:20, Andrew Fish wrote:
> 
> > On Sep 9, 2015, at 3:24 PM, Jordan Justen  wrote:
> > 
> > On 2015-09-09 12:11:26, El-Haj-Mahmoud, Samer wrote:
> >> The recent expansions beyond BSD where all permissive licenses (BSD
> >> like) as far as I can tell.
> >> 
> >> I agree with Andrew, opening the door for GPL licensed code in EDK2
> >> will have severe consequences for products that are built using
> >> EDK2.
> > 
> > I don't think simply having a GplDriverPkg in the tree would have any
> > consequences for a platform that doesn't use any code in that package.
> > Obviously we could not make any core packages rely on that package.
> > 
> 
> So you have a legal degree and are speaking on behalf of your
> employer on this subject?

No and no. How about you? :)

Nevertheless, I have not heard the interpretation that just having GPL
in a source tree would impact your code, even if you do not include,
nor link to it. Is this Apple's interpretation of how GPL works?

> > FWIW, I don't mind if the consensus is that GplDriverPkg must live in
> > a separate repo. But, it would be nice to hear a good reason why it
> > must live elsewhere.
> 
> Because GPL is not a permissive license. An accidental git grep and
> copying some code can change the license of the code that gets the
> GPL code pasted into it.

I like this argument. It is slightly tempered by the fact that git
grep always shows the source path, and thus 'GplDriverPkg' would be
obviously visible.

> Thus having GPL code in the same repository as BSD code can end up
> accidentally converting BSD code to GPL code over time.

I would be more worried about the GPL based drivers becoming too
featureful over time, and the permissively licensed code not being
very useful. For example, I'm worried that the non-GPL OVMF may end up
missing a lot of features.

-Jordan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [v2][PATCH] xen/vtd/iommu: permit group devices to passthrough in relaxed mode


On 9/9/2015 2:54 PM, Jan Beulich wrote:

On 09.09.15 at 03:59,  wrote:

@@ -2310,12 +2312,16 @@ static int intel_iommu_assign_device(
  PCI_DEVFN2(bdf) == devfn &&
  rmrr->scope.devices_cnt > 1 )
 {
-printk(XENLOG_G_ERR VTDPREFIX
-   " cannot assign %04x:%02x:%02x.%u"
+bool_t relaxed = !!(flag & XEN_DOMCTL_DEV_RDM_RELAXED);
+
+printk(XENLOG_G_WARNING VTDPREFIX


Well, I can live with this always being a warning, but it's not what I
had asked for. The VT-d maintainers will have to judge.



Kevin,

Any comments?

Thanks
Tiejun

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PULL 0/19] xen-2015-09-08-tag

On 9/10/2015 12:10 AM, Stefano Stabellini wrote:

On Wed, 9 Sep 2015, Stefano Stabellini wrote:

On Tue, 8 Sep 2015, Peter Maydell wrote:
> On 8 September 2015 at 18:21, Stefano Stabellini
>  wrote:
> > The following changes since commit 8611280505119e296757a60711a881341603fa5a:
> >
> >   target-microblaze: Use setcond for pcmp* (2015-09-08 08:49:33 +0200)
> >
> > are available in the git repository at:
> >
> >   git://xenbits.xen.org/people/sstabellini/qemu-dm.git 
tags/xen-2015-09-08-tag
> >
> > for you to fetch changes up to ba2250ad148997b1352aba976aac66b55410e7e4:
> >
> >   xen/pt: Use XEN_PT_LOG properly to guard against compiler warnings. 
(2015-09-08 15:21:56 +)
> >
> > 
> > Xen branch xen-2015-09-08
> >
> > 
>
> Hi. I'm afraid this fails to build on OSX (and probably Windows too,
> though that build hasn't run yet):
>
>   CCi386-softmmu/hw/i386/pci-assign-load-rom.o
> /Users/pm215/src/qemu/hw/i386/pci-assign-load-rom.c:6:10: fatal error:
>   'sys/io.h' file not found
> #include 
>  ^
>   CCalpha-softmmu/hw/alpha/pci.o
> 1 error generated.

Tiejun,

this is caused by 33d33242b7d802e6c994f3d56ecba96a66465dc3,
"hw/pci-assign: split pci-assign.c". Could you please double-check
non-Linux builds?

I found another issue introduced by the gfx passthrough series on
Windows:

../hw/pci-host/piix.o: In function `host_pci_config_read':
/root/qemu/hw/pci-host/piix.c:778: undefined reference to `_pread'

It is introduced by:

commit fdb70721ba0496a767137e5505dd27627d19c4a8
Author: Tiejun Chen 
Date:   Wed Jul 15 13:37:43 2015 +0800

 piix: create host bridge to passthrough

You might have to replace the pread call with lseek and read.

This is also surprising to me. Just see xen_host_pci_config_() 
inside /hw/xen/xen-host-pci-device.c, there are so many this pread 
usage(). So I really don't understand what's difference between these 
two files.	

Thanks
Tiejun

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] PVGRUB2 works here and broken there...

2015-09-09 Thread Shaun Reitan

We are experiencing a odd issue after we built grub2 support.  The image 
we built works fine on some hosts and then just hangs on others.


I built grub2 as follows...
-
git clone http://git.savannah.gnu.org/cgit/grub.git
cd  grub
wget http://prgmr.com/~srn/grub2/xen-linux16.patch
patch -p1 < xen-linux16.patch
./autogen.sh
./configure --target=x86_64 --with-platform=xen --prefix=/opt/grub2
make
make install
export PATH=/opt/grub2/bin:/opt/grub2/sbin:$PATH

Next I built the image as follows...
---
cat > grub-bootstrap.cfg << EOF
normal (memdisk)/grub.cfg
EOF
cat > grub.cfg << EOF
for grubcfg in /boot/grub2/grub.cfg /boot/grub2/grub2.cfg 
/boot/grub/grub2.cfg /boot/grub/grub.cfg /grub2/grub2.cfg /grub/grub.cfg 
/etc/grub2.cfg /etc/grub.cfg ; do

   if search -s -f $grubcfg ; then
  echo "Reading (${root}$grubcfg"
  configfile $grubcfg
   fi
done
EOF
tar cf memdisk.tar grub.cfg
/opt/grub2/bin/grub-mkimage -O x86_64-xen -c grub-bootstrap.cfg -m 
memdisk.tar -o grub2-x86_64 /opt/grub2/lib/grub/x86_64-xen/*.mod


This works fine on some of our hosts, but then just seams to hang on 
others.  When starting the guest i see the following...


[root@devhostxxx ~]# xm create -c /home/username/vs.config
Using config file "/home/username/vs.config".
Started domain username (id=34)
 [root@devhostxxx ~]#

Then it just hangs from their.

These hosts are CentOS 6 using the CentOS-Xen RPMS. Hosts are running 
Xen version 4.4.1-8el6 and still using xend with xm commands



Any idea what may be going on here? Or how i should go about debugging 
this issue?


--
Shaun
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4

2015-09-09 Thread Julien Grall


Hi Manish,

On 13/08/2015 10:42, Manish Jaggi wrote:

  3.2.Mapping between streamID - deviceID - pci sbdf - requesterID
  -
  For a simpler case all should be equal to BDF. But there are some devices
  that use the wrong requester ID for DMA transactions. Linux kernel has
PCI
  quirks for these. How the same be implemented in Xen or a diffrent
approach
  has to be taken is TODO here.

  Till that time, for basic implementation it is assumed that all are equal
  to BDF.


Back to this streamID = DeviceID = requestID = SBDF again...

I've just found a patch for Linux send by one of your colleague about 
tweaking the requesterID for thunder-X board (See [1]). The most 
interesting bits are:


static u32 pci_requester_id_ecam(struct pci_dev *dev)
{
return (((pci_domain_nr(dev->bus) >> 2) << 19) |
((pci_domain_nr(dev->bus) % 4) << 16) |
(dev->bus->number << 8) | dev->devfn);
}

static u32 thunder_pci_requester_id(struct pci_dev *dev, u16 alias)
{
int ret;

ret = thunder_pem_requester_id(dev);
if (ret >= 0)
return (u32)ret;

return pci_requester_id_ecam(dev);
}

Which is then used to override the default function used by ITS to find 
the deviceID.


AFAICT, this means that you can't safely assume that DeviceID == sBDF 
even for your platform. Is that right?


If so, I'm afraid that you have to handle DeviceID != sBDF (and so on) 
in your design doc. I.e how do you plan to get the base requester ID.


I can see 2 different solutions:
1) Let DOM0 pass the first requester ID when registering the bus
   Pros:
* Less per-platform code in Xen
   Cons:
* Assume that the requester ID are contiguous. (Is it really a 
cons?)
* Still require quirk for buggy device (i.e requester ID not 
correct)
2) Do it in Xen
   Pros:
* We are not relying on DOM0 giving the requester ID
=> Not assuming contiguous requester ID
   Cons:
* Per PCI bridge code to handle the mapping

Regards,

[1] https://lkml.org/lkml/2015/7/15/703



--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PULL 0/19] xen-2015-09-08-tag

On 9/9/2015 9:06 PM, Stefano Stabellini wrote:

On Tue, 8 Sep 2015, Peter Maydell wrote:

On 8 September 2015 at 18:21, Stefano Stabellini
 wrote:
> The following changes since commit 8611280505119e296757a60711a881341603fa5a:
>
>   target-microblaze: Use setcond for pcmp* (2015-09-08 08:49:33 +0200)
>
> are available in the git repository at:
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-2015-09-08-tag
>
> for you to fetch changes up to ba2250ad148997b1352aba976aac66b55410e7e4:
>
>   xen/pt: Use XEN_PT_LOG properly to guard against compiler warnings. 
(2015-09-08 15:21:56 +)
>
> 
> Xen branch xen-2015-09-08
>
> 

Hi. I'm afraid this fails to build on OSX (and probably Windows too,
though that build hasn't run yet):

  CCi386-softmmu/hw/i386/pci-assign-load-rom.o
/Users/pm215/src/qemu/hw/i386/pci-assign-load-rom.c:6:10: fatal error:
  'sys/io.h' file not found
#include 
 ^
  CCalpha-softmmu/hw/alpha/pci.o
1 error generated.

Tiejun,

this is caused by 33d33242b7d802e6c994f3d56ecba96a66465dc3,
"hw/pci-assign: split pci-assign.c". Could you please double-check
non-Linux builds?

Its interesting.

As you see this short log, "hw/pci-assign: split pci-assign.c", so this 
means I just extract something from the original 
hw/i386/kvm/pci-assign.c, and here so I just keep those original head 
files residing hw/i386/kvm/pci-assign.c, and I didn't introduce anything 
new.

So its very probably that you still can't compile successfully even 
without my commit on OSX/Windows, right? I think Peter may be right,

"Will passthrough even work on Windows and OSX hosts?
Consider whether we should be building this code on those
hosts at all..."

I prefer this isn't what we did previously.

I suspect that the fix would be quite small, but I don't have an OSX or
a Windows build environment to try it.

I haven't a this build environment as well. But I think right now you 
can remove "#include " to fix this simply since looks this is 
redundant actually.

hw/i386/pci-assign: remove one head file

This is redundant actually but really break OS/Windows build.

Signed-off-by: Tiejun Chen 

diff --git a/hw/i386/pci-assign-load-rom.c b/hw/i386/pci-assign-load-rom.c
index bad53b7..1f0d4ef 100644
--- a/hw/i386/pci-assign-load-rom.c
+++ b/hw/i386/pci-assign-load-rom.c
@@ -3,7 +3,6 @@
  */
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 

At least I can build this under Linux,

./configure --target-list=x86_64-softmmu && make

Thanks
Tiejun

Speak about build environments, Peter, would you care to share your
scripts and setup so that I can run similar tests in the future on my
own?  I have no OSX machines so I tried to do a Windows
cross-compile, following http://wiki.qemu.org/Hosts/W32 on Debian 7, but
I failed very early with an "ERROR: zlib check failed".

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [xen-4.0-testing test] 61657: tolerable FAIL

flight 61657 xen-4.0-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61657/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-i386-rumpuserxen1 build-check(1)   blocked  n/a
 build-amd64-rumpuserxen   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-libvirt-raw   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-raw   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-i386-i386-xl-credit2 1 build-check(1)   blocked  n/a
 test-i386-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-i386-i386-libvirt-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-rhel6hvm-amd  1 build-check(1)   blocked  n/a
 test-i386-i386-xl-raw 1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-i386-i386-xl-winxpsp31 build-check(1)   blocked  n/a
 test-i386-i386-xl-qcow2   1 build-check(1)   blocked  n/a
 test-i386-i386-xl-vhd 1 build-check(1)   blocked  n/a
 test-i386-i386-xl 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-freebsd10-i386  1 build-check(1) blocked n/a
 test-i386-i386-libvirt-vhd1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-vhd1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-i386-i386-pv 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-i386-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-i386-i386-xl-multivcpu   1 build-check(1)   blocked  n/a
 test-i386-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-i386-i386-libvirt1 build-check(1)   blocked  n/a
 test-i386-i386-pair   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-rhel6hvm-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-freebsd10-amd64  1 build-check(1)

Re: [Xen-devel] [PATCH net v2 0/2] xen-net{front, back}: respect user provided max_queues

2015-09-09 Thread David Miller

From: Wei Liu 
Date: Wed, 9 Sep 2015 11:23:04 +0100

> Wei Liu (2):
>   xen-netback: respect user provided max_queues
>   xen-netfront: respect user provided max_queues

Both applied, thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH net v2 0/2] xen-net{front, back}: respect user provided max_queues

2015-09-09 Thread David Miller

From: David Miller 
Date: Wed, 09 Sep 2015 21:53:22 -0700 (PDT)

> From: Wei Liu 
> Date: Wed, 9 Sep 2015 11:23:04 +0100
> 
>> Wei Liu (2):
>>   xen-netback: respect user provided max_queues
>>   xen-netfront: respect user provided max_queues
> 
> Both applied, thanks.

Yo, this doesn't even compile!

drivers/net/xen-netfront.c: In function ‘netif_init’:
drivers/net/xen-netfront.c:2138:6: error: ‘xenvif_max_queues’ undeclared (first 
use in this function)
  if (xenvif_max_queues == 0)
  ^
drivers/net/xen-netfront.c:2138:6: note: each undeclared identifier is reported 
only once for each function it appears in

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [ovmf test] 61636: regressions - FAIL

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 60869
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 60869

version targeted for testing:
 ovmf 50e7d3d90d90ac261ef32e832968cd44df830542
baseline version:
 ovmf ba1806251ff8ff695175b92ab5732eadbcd2f72e

Last test of basis60869  2015-08-25 03:03:43 Z   16 days
Failing since 60904  2015-08-27 01:40:43 Z   14 days9 attempts
Testing same since61636  2015-09-08 17:42:07 Z1 days1 attempts


People who touched revisions under test:
  "Yao, Jiewen" 
  Ard Biesheuvel 
  Cecil Sheng 
  Cecil Sheng 
  Dandan Bi 
  eric Dong 
  Feng Tian 
  Fu Siyuan 
  Gary Ching-Pang Lin 
  Hao Wu 
  Heyi Guo 
  Jeff Fan 
  Jiaxin Wu 
  Jonathan Panozzo 
  Laszlo Ersek 
  Leif Lindholm 
  Liming Gao 
  Masamitsu MURASE 
  Qin Long 
  Qiu Shumin 
  Ruiyu Ni 
  Samer El-Haj-Mahmoud 
  Shifei Lu 
  Star Zeng 
  Sunny Wang 
  Yao, Jiewen 
  Yingke Liu 
  Zhang Lubo 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

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

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

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


Not pushing.

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

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [v2][PATCH] xen/vtd/iommu: permit group devices to passthrough in relaxed mode

2015-09-09 Thread Tian, Kevin

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, September 09, 2015 2:55 PM
> 
> >>> On 09.09.15 at 03:59,  wrote:
> > @@ -2310,12 +2312,16 @@ static int intel_iommu_assign_device(
> >   PCI_DEVFN2(bdf) == devfn &&
> >   rmrr->scope.devices_cnt > 1 )
> >  {
> > -printk(XENLOG_G_ERR VTDPREFIX
> > -   " cannot assign %04x:%02x:%02x.%u"
> > +bool_t relaxed = !!(flag & XEN_DOMCTL_DEV_RDM_RELAXED);
> > +
> > +printk(XENLOG_G_WARNING VTDPREFIX
> 
> Well, I can live with this always being a warning, but it's not what I
> had asked for. The VT-d maintainers will have to judge.
> 

Need to have separate warning/error level for relax/strict.

However I don't think this patch is a right fix. So far relax/strict policy
is per-domain. what about one VM specifies relax while another VM
specifies strict when each is assigned with a device sharing rmrr
with the other? In that case it becomes a system-wide security hole.

Once we add code to track group relationship cross domains, it'd be
close to the final fix to support group assignment which originally target 
4.7. It might be risky to add that in 4.6.

So my suggestion is to live with current limitation.

Thanks
Kevin

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.5-testing test] 61618: regressions - trouble: broken/fail/pass

flight 61618 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61618/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-vhd   3 host-install(3) broken REGR. vs. 60577
 test-amd64-i386-xl-vhd9 debian-di-install fail REGR. vs. 60577
 test-amd64-i386-xl-raw9 debian-di-install fail REGR. vs. 60577
 test-armhf-armhf-xl-multivcpu  7 host-ping-check-xen  fail REGR. vs. 60577
 test-amd64-amd64-xl-raw   9 debian-di-install fail REGR. vs. 60577

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-raw  9 debian-di-install fail REGR. vs. 60577
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail blocked in 60577
 test-amd64-i386-libvirt  11 guest-start  fail   like 60577
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 60577

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-xl-qcow2  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail   never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuuc6dc376c4b5292769582137867d1be6c3960b5c7
baseline version:
 qemuuf74d682ee4878af6a8e943f5f0b595af92b20084

Last test of basis60577  2015-08-04 12:45:54 Z   36 days
Failing since 60964  2015-08-28 09:10:02 Z   12 days2 attempts
Testing same since61618  2015-09-08 12:11:46 Z1 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Peter Lieven 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass

Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

> On Sep 9, 2015, at 5:41 PM, Jordan Justen  wrote:
> 
> On 2015-09-09 16:05:20, Andrew Fish wrote:
>> 
>>> On Sep 9, 2015, at 3:24 PM, Jordan Justen  wrote:
>>> 
>>> On 2015-09-09 12:11:26, El-Haj-Mahmoud, Samer wrote:
 The recent expansions beyond BSD where all permissive licenses (BSD
 like) as far as I can tell.

 I agree with Andrew, opening the door for GPL licensed code in EDK2
 will have severe consequences for products that are built using
 EDK2.
>>> 
>>> I don't think simply having a GplDriverPkg in the tree would have any
>>> consequences for a platform that doesn't use any code in that package.
>>> Obviously we could not make any core packages rely on that package.
>>> 
>> 
>> So you have a legal degree and are speaking on behalf of your
>> employer on this subject?
> 
> No and no. How about you? :)
> 

No but I have to review any code contributed to the open source project to make 
sure it follows the corporate polices. 

> Nevertheless, I have not heard the interpretation that just having GPL
> in a source tree would impact your code, even if you do not include,
> nor link to it. Is this Apple's interpretation of how GPL works?
> 

No but thanks for making my point for me. 1st off the rules are made by lawyers 
and managers so you trying to argue logic is kind of funny. What does logic 
have to do with it. Your company started this edk2 project as a BSD project, 
and I assume there was a reason for that. The reasons rules like this end up 
getting made is that developers like you are confused about the company policy 
regarding open source, closed source and protecting intellectual property 
rights. So your very smart and well versed and you are confused, so some more 
jr. engineer has no hope of getting it right and would copy the GPL code and be 
clueless to what he just did. As I always say a development process exists to 
slow down the best developer, at the price of preventing the most jr. 
developers from doing something stupid. 

>>> FWIW, I don't mind if the consensus is that GplDriverPkg must live in
>>> a separate repo. But, it would be nice to hear a good reason why it
>>> must live elsewhere.
>> 
>> Because GPL is not a permissive license. An accidental git grep and
>> copying some code can change the license of the code that gets the
>> GPL code pasted into it.
> 
> I like this argument. It is slightly tempered by the fact that git
> grep always shows the source path, and thus 'GplDriverPkg' would be
> obviously visible.
> 

If the developer is even paying attention, or using a tool that highlights path 
vs. filename. Or maybe the path is too long to display and gets shortened in a 
way that Gpl is not obvious. Not to mention if this was so easy why not include 
the source for the FAT driver with the GPL sources? We could add 
EvilNonGplCompatibleLicence to the path and that would solve everything. 

>> Thus having GPL code in the same repository as BSD code can end up
>> accidentally converting BSD code to GPL code over time.
> 
> I would be more worried about the GPL based drivers becoming too
> featureful over time, and the permissively licensed code not being
> very useful. For example, I'm worried that the non-GPL OVMF may end up
> missing a lot of features.
> 

Then logically you should just make OVMF a GPL project?

Thanks,

Andrew Fish

> -Jordan
> ___
> edk2-devel mailing list
> edk2-de...@lists.01.org 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel=BQICAg=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=QYa4zV8t1IKrqv8dzBT9QGeAY0RWiBcTz1WwIesvScU=nVrllStzjUOtvIbFx2GiI-npvnVHMREDrHQ1CcfBD2E=
>  
> 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [linux-3.14 bisection] complete test-amd64-i386-xl-vhd

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-vhd
test guest-saverestore

Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
  Bug introduced:  9e6c072a69d87100808d16279d60e9f857291340
  Bug not present: b60d3eee854b881b3f7a478c8b622cbef72d4c4e


  commit 9e6c072a69d87100808d16279d60e9f857291340
  Author: Marek Marczykowski-GÃ³recki 
  Date:   Fri Jun 26 03:28:24 2015 +0200

  xen/gntdevt: Fix race condition in gntdev_release()

  commit 30b03d05e07467b8c6ec683ea96b5bffcbcd3931 upstream.

  While gntdev_release() is called the MMU notifier is still registered
  and can traverse priv->maps list even if no pages are mapped (which is
  the case -- gntdev_release() is called after all). But
  gntdev_release() will clear that list, so make sure that only one of
  those things happens at the same time.

  Signed-off-by: Marek Marczykowski-GÃ³recki 

  Signed-off-by: David Vrabel 
  Signed-off-by: Greg Kroah-Hartman 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-3.14/test-amd64-i386-xl-vhd.guest-saverestore.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-3.14/test-amd64-i386-xl-vhd.guest-saverestore
 --summary-out=tmp/61732.bisection-summary --basis-template=60666 
--blessings=real,real-bisect linux-3.14 test-amd64-i386-xl-vhd guest-saverestore
Searching for failure / basis pass:
 61263 fail [host=huxelrebe1] / 60666 [host=fiano0] 60655 [host=chardonnay1] 
60549 [host=merlot0] template as basis? using template as basis.
Failure / basis pass flights: 61263 / 60666
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 318ff69ca4c275bae4b875b87df5bdbd7988486a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
5cdde31eacdd288359746019ad05cac8ed5d9f70 
b05befcbea71a979509ce04f02929969a790c923 
801ab48e5556cb54f67e3cb57f077f47e8663ced
Basis pass 9b8b905951bde404f20a7bd4b37a5134f3484569 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
7f057440b31da38196e3398fd1b618fc36ad97d6 
bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 
201eac83831d94ba2e9a63a7eed4c128633fafb1
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#9b8b905951bde404f20a7bd4b37a5134f3484569-318ff69ca4c275bae4b875b87df5bdbd7988486a
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/staging/qemu-xen-unstable.git#7f057440b31da38196e3398fd1b618fc36ad97d6-5cdde31eacdd288359746019ad05cac8ed5d9f70
 
git://xenbits.xen.org/staging/qemu-upstream-unstable.git#bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa-b05befcbea71a979509ce04f02929969a790c923
 
git://xenbits.xen.org/xen.git#201eac83831d94ba2e9a63a7eed4c128633fafb1-801ab48e5556cb54f67e3cb57f077f47e8663ced
Loaded 18027 nodes in revision graph
Searching for test results:
 60655 [host=chardonnay1]
 60666 [host=fiano0]
 60747 fail irrelevant
 60787 fail irrelevant
 60823 fail irrelevant
 60942 fail irrelevant
 60907 pass irrelevant
 60908 pass irrelevant
 60858 fail irrelevant
 60909 pass irrelevant
 60895 pass 9b8b905951bde404f20a7bd4b37a5134f3484569 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
7f057440b31da38196e3398fd1b618fc36ad97d6 
bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 
201eac83831d94ba2e9a63a7eed4c128633fafb1
 60897 fail irrelevant
 60899 pass 9b8b905951bde404f20a7bd4b37a5134f3484569 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
7f057440b31da38196e3398fd1b618fc36ad97d6 
bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 
201eac83831d94ba2e9a63a7eed4c128633fafb1
 60900 fail irrelevant
 60902 fail irrelevant
 60911 []
 60905 pass irrelevant
 60949 fail 318ff69ca4c275bae4b875b87df5bdbd7988486a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
7f057440b31da38196e3398fd1b618fc36ad97d6 
b05befcbea71a979509ce04f02929969a790c923 
7b99717f62caeac08eea224a177cd28f047ac4b5
 61086 pass 9b8b905951bde404f20a7bd4b37a5134f3484569 
c530a75c1e6a472b0eb9558310b518f0dfcd8860

Re: [Xen-devel] [PATCH] xen/domctl: lower loglevel of XEN_DOMCTL_memory_mapping


If the 64 limit was arbitrary then I would suggest increasing it to at least
1024 so that
at least 4M of BAR can be mapped in one go and it reduces the overhead by a
factor of 16.


1024 may be a little much, but 256 is certainly a possibility, plus
Konrad's suggestion to allow this limit to be controlled via command
line option.


Are you guys talking this way?

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 3946e4c..a9671bb 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -88,6 +88,10 @@ boolean_param("noapic", skip_ioapic_setup);
 s8 __read_mostly xen_cpuidle = -1;
 boolean_param("cpuidle", xen_cpuidle);

+/* once_mapping_mfns: memory mapping mfn bumbers once. */
+unsigned int xen_once_mapping_mfns;
+integer_param("once_mapping_mfns", xen_once_mapping_mfns);
+
 #ifndef NDEBUG
 unsigned long __initdata highmem_start;
 size_param("highmem-start", highmem_start);
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 3bf39f1..82c85e3 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -33,6 +33,8 @@
 #include 
 #include 

+extern unsigned int xen_once_mapping_mfns;
+
 static DEFINE_SPINLOCK(domctl_lock);
 DEFINE_SPINLOCK(vcpu_alloc_lock);

@@ -1035,7 +1037,7 @@ long 
do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)


 ret = -E2BIG;
 /* Must break hypercall up as this could take a while. */
-if ( nr_mfns > 64 )
+if ( nr_mfns > xen_once_mapping_mfns )
 break;

 ret = -EPERM;

Thanks
Tiejun

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

On 2015-09-09 20:26:54, Andrew Fish wrote:
> > On Sep 9, 2015, at 5:41 PM, Jordan Justen  wrote:
> > On 2015-09-09 16:05:20, Andrew Fish wrote:
> >> So you have a legal degree and are speaking on behalf of your
> >> employer on this subject?
> > 
> > No and no. How about you? :)
> 
> No but I have to review any code contributed to the open source
> project to make sure it follows the corporate polices.

Is Apple corporate policy that you could never contribute to a project
that has a GPL directory in the tree?

> > Nevertheless, I have not heard the interpretation that just having GPL
> > in a source tree would impact your code, even if you do not include,
> > nor link to it. Is this Apple's interpretation of how GPL works?
> 
> No but thanks for making my point for me. 1st off the rules are made
> by lawyers and managers so you trying to argue logic is kind of
> funny. What does logic have to do with it.

Whoa! What's next in this crazy world? Dogs and cats living together!
Mass hysteria! How can we be sure that the lawyers won't decide that
BSD means GPL and vice versa? ;)

> Your company started this edk2 project as a BSD project, and I
> assume there was a reason for that.

And then more licenses were added.

> The reasons rules like this end up getting made is that developers
> like you are confused about the company policy regarding open
> source, closed source and protecting intellectual property rights.
> So your very smart and well versed and you are confused, so

I don't think I'm confused (or smart :), but you are trying hard to
make it seem confusing and scary.

Anyway, you are correct. We do have rules. But, I don't think those
rules prevent us from discussing *possible* changes to those rules.

> some more jr. engineer has no hope of getting it right and would
> copy the GPL code and be clueless to what he just did. As I always
> say a development process exists to slow down the best developer, at
> the price of preventing the most jr. developers from doing something
> stupid.

If we have another repo with GplDriverPkg, then I guess the same jr.
developer might just go find the code over there and copy it.

> > I would be more worried about the GPL based drivers becoming too
> > featureful over time, and the permissively licensed code not being
> > very useful. For example, I'm worried that the non-GPL OVMF may end up
> > missing a lot of features.
> 
> Then logically you should just make OVMF a GPL project?

Not if you are someone that prefers permissive source licenses, such
as myself.

I'm basically trying to argue the other side of this to not let the
GPL FUD go by unimpeded.

Laszlo's email raised the GPL question, but I was not sure what the
EDK II community would accept with regards to GPL. Thus ... I asked. I
guess I'm getting a better idea with regards to Apple and HP. :)

In your opinion, would we be able to discuss patches for a *separate*
repo with GplDriverPkg on edk2-devel?

Thanks,

-Jordan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 10/11] x86/intel_pstate: support the use of intel_pstate in pmstat.c

2015-09-09 Thread Wang, Wei W

On 09/09/2015 23:55,  Jan Beulich wrote:
>>> On 09.09.15 at 17:16,  wrote:
> On 09/09/2015 21:12,  Jan Beulich wrote:
 On 09.09.15 at 14:56,  wrote:
>> Can you please explain more why it doesn't scale? 
>> From my point of view, any other future value representation can be 
>> passed from the producer to the related consumer through this method.
> 
>> Did you read all of my earlier replies? I already said there "Just 
>> consider
> what happens to the code when we end up gaining a few
>> more drivers providing percentage values, and perhaps another one 
>> providing
> a third variant of output representation."
> 
> Yes, I have read that. I am not sure if I got your point, but my 
> meaning was when we add new drivers to the code, e.g. xx_pstate 
> driver, we can still have the name, "xx_pstate", assigned to 
> "p_cpufreq->scaling_driver" to distinguish one another. If the driver 
> uses a different variant of output representation, which cannot be 
> held by " uint32_t scaling_max_perf" (it needs "uint64_t" for example, then 
> that driver developer needs to add a new field here like  "
> uint64_t scaling_max_perf_xx").
> What is the scaling problem? 

>   if (strcmp() == 0 ||
>   strcmp() == 0 ||
>   strcmp() == 0) {
>   ...
>   } else if (strcmp() == 0) {
>   ...
>   } else {
>   ...
>   }

> is just ugly, and gets all the uglier the more strcmp()s get added.
> Have a boolean or enumeration indicating what kind of data there is, and the 
> above changes to

>   switch (kind) {
>   case absolute: ...
>   case percentage: ...
>   }

Ok. I will replace the default "scaling_driver[CPUFREQ_NAME_LEN]" with an enum 
type, like this following
...
- char scaling_driver[CPUFREQ_NAME_LEN];
+ enum scaling_driver_flag scaling_driver;
...

We cannot keep both of the above two there, because there is a 128Byte size 
limit. Then somewhere, we need to translate the character-represented 
scaling_driver to our new enum-represented scaling_driver. For example, in 
pmstat.c, the following:

if ( cpufreq_driver->name[0] )
strlcpy(op->u.get_para.scaling_driver,
cpufreq_driver->name, CPUFREQ_NAME_LEN);
else
strlcpy(op->u.get_para.scaling_driver, "Unknown", CPUFREQ_NAME_LEN);

needs to be changed to:
if ( strncmp(cpufreq_driver->name[0], "intel_pstate", CPUFREQ_NAME_LEN) == 0 )
op->u.get_para.scaling_driver = INTEL_PSTATE;
else if ( strncmp(cpufreq_driver->name[0], "acpi_cpufreq", CPUFREQ_NAME_LEN) == 
0 )
op->u.get_para.scaling_driver = ACPI_CPUFREQ;
...

Seems we still cannot get rid of these strncmp()s. Is this acceptable, or 
should we change "struct cpufreq_driver" to use enum represented driver name as 
well, or do you have a better suggestion?

Best,
Wei



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

2015-09-09 Thread Zeng, Star


On 2015/9/9 18:48, Laszlo Ersek wrote:

me neither :)


but if this (executable code on stack) is
happening in grub is there something which is explicitly forbidden to UEFI
apps by the UEFI spec?


Yes, there is. This small OvmfPkg patch only enables the edk2 feature
added by Star Zeng in
 for OVMF. That patch
(also referenced in my commit message by SVN rev) says,

 This feature is added for UEFI spec that says
 "Stack may be marked as non-executable in identity mapped page
 tables".
 A PCD PcdSetNxForStack is added to turn on/off this feature, and it
 is FALSE by default.

A UEFI app runs (well, *starts*, anyway) before ExitBootServices() /
SetVirtualAddressMap(), so it's bound by the above.

The spec passage above is quoted from "2.3.2 IA-32 Platforms", and
"2.3.4 x64 Platforms", in chapter "2.3 Calling Conventions", where the
boot services time environment is specified.

This is new in UEFI-2.5, and it comes from Mantis ticket 1224: "Adding
support for No executable data areas".

... The question could be then if grub (in Wheezy) should be adapted to
UEFI-2.5 (if that's possible) or if OVMF should be built without this
feature.

Hmmm. Actually, I'm torn about the default for PcdSetNxForStack.

Namely, Mantis ticket 1224 has come up before. There's another edk2
sub-feature related to this UEFI spec feature / Mantis ticket; the
properties table (controlled by "PcdPropertiesTableEnable"), and the
effects it has on the UEFI memory map, and the requirements it presents
for UEFI OSes.

*That* sub-feature is extremely intrusive.
"MdeModulePkg/MdeModulePkg.dec" sets "PcdPropertiesTableEnable" TRUE by
default, and OvmfPkg inherits it. I have not overridden that default
just yet in OvmfPkg because the properties table feature depends on
something *else* too: sections in runtime DXE driver binaries must be
aligned at 4KB, and that is not ensured for OvmfPkg (yet?). Therefore,
the properties table feature is not active in OVMF at the moment due to
a "random build tools circumstance" -- and not because the feature flag
is actually disabled.

Now, the properties table feature absolutely cannot be (effectively)
enabled in OVMF as a default. It would break Windows 7 / Windows Server
2008 R2. A huge number of users run such guests for GPU passthrough.

The idea that just crossed my mind was to introduce a new build flag for
OVMF, like -D NOEXEC_DATA_ENABLE. And this would then control
PcdSetNxForStack *and* PcdPropertiesTableEnable *together*:

if NOEXEC_DATA_ENABLE:
   PcdSetNxForStack := TRUE
   PcdPropertiesTableEnable := TRUE
else
   PcdSetNxForStack := FALSE
   PcdPropertiesTableEnable := FALSE

However, I think that's a bad idea.

"PcdPropertiesTableEnable" breaks a very widely used guest OS for which
there is no update in sight (ie. no Service Pack 2 for Windows 7 /
Windows Server 2008 R2), but is otherwise supposed to be supported for
years to come.

Whereas Debian Wheezy is not as widely used as a guest (for one: it
"competes" with all the other Linux distros from the same timeframe).
Debian Wheezy also provides a quite non-intrusive upgrade path (to
Jessie), which is not the case for Windows 7. So the breakage casued by
setting PcdSetNxForStack has much smaller impact, I think, and the
benefits might outweigh the breakage.

Which just means that a heavy-handed -D NOEXEC_DATA_ENABLE, like above,
would not be appropriate. PcdSetNxForStack set, and
PcdPropertiesTableEnable clear, is a valid configuration.

In any case, I sort of convinced myself that Wheezy's grub is not at
fault; it was simply written against an earlier release of the UEFI spec.

How about this:

- (somewhat unrelatedly, but for completeness):
   I post a patch that exposes PcdPropertiesTableEnable with a build
   time flag (NX_PROP_TABLE_ENABLE) with an OVMF-default of FALSE,

- I post another patch that exposes PcdSetNxForStack with a build time
   flag (NX_STACK_ENABLE) with an OVMF-default of *TRUE*. You could then
   pass -D NX_STACK_ENABLE=FALSE when you build OVMF for any environment
   where Wheezy guests are expected.

Jordan?

Yet another (quite complex) possibility:

- According to "MdeModulePkg/MdeModulePkg.dec",
   a platform DSC can already type PcdPropertiesTableEnable as a dynamic
   PCD. We could allow the same for PcdSetNxForStack. Star?


I think PcdSetNxForStack could be extended to support dynamic type if 
the platform really needs to set the PCD dynamically after some 
condition check.




   Both PCDs are consumed "acceptably late" (the first in the DXE core,
   the second in the DXE IPL PEIM). This would allow
   OvmfPkg/PlatformPei to set the PCDs dynamically.

- Then the question is how we pass in the PCD values from the outside.
   For QEMU/KVM virtual machines, we could use Gabriel's QEMU feature

   -fw_cfg name=opt/my_item_name,file=./my_blob.bin

   ie. no changes for QEMU would be necessary. Xen virtual machines
   don't have fw_cfg however,

Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

2015-09-09 Thread El-Haj-Mahmoud, Samer

Adding back edk2-devel that got accidently dropped 

I am against putting any GPL licensed code in EDK2. Having it live in a 
separate repo and pulling an additional package from that repo is fine. But the 
main EDK2 repo needs to stay GPL-free.

Thanks,
--Samer

-Original Message-
From: af...@apple.com [mailto:af...@apple.com] 
Sent: Wednesday, September 09, 2015 6:05 PM
To: Jordan Justen 
Cc: El-Haj-Mahmoud, Samer ; Lenny Szubowicz 
; Karen Noel ; Ard Biesheuvel 
; edk2-devel-01 ; Cole 
Robinson ; Ademar de Souza Reis Jr. ; 
Alexander Graf ; qemu devel list ; 
Gabriel L. Somlo (GMail) ; Peter Jones ; 
Peter Batard ; Hannes Reinecke ; Reza Jelveh 
; Paolo Bonzini ; 
xen-devel@lists.xen.org; Laszlo Ersek ; Gerd Hoffmann 
; Doran, Mark 
Subject: Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

> On Sep 9, 2015, at 3:24 PM, Jordan Justen  wrote:
> 
> On 2015-09-09 12:11:26, El-Haj-Mahmoud, Samer wrote:
>> The recent expansions beyond BSD where all permissive licenses (BSD
>> like) as far as I can tell.
>> 
>> I agree with Andrew, opening the door for GPL licensed code in EDK2 
>> will have severe consequences for products that are built using EDK2.
> 
> I don't think simply having a GplDriverPkg in the tree would have any 
> consequences for a platform that doesn't use any code in that package.
> Obviously we could not make any core packages rely on that package.
> 

So you have a legal degree and are speaking on behalf of your employer on this 
subject? 

> This would just be a sanctioned, clear landing place for people that 
> cannot, or will not provide their driver under a permissive license.
> 
> This license will limit who can use drivers from this package. For 
> that reason, I hope that we will always ask if a contribution can be 
> permissively licensed instead.
> 
> Personally, I would prefer a 2-clause BSD only tree for simplicity, 
> but unfortunately, that sort of restriction has its own drawbacks as 
> well. (frustrated contributors and less contributions)
> 
> FWIW, I don't mind if the consensus is that GplDriverPkg must live in 
> a separate repo. But, it would be nice to hear a good reason why it 
> must live elsewhere.

Because GPL is not a permissive license. An accidental git grep and copying 
some code can change the license of the code that gets the GPL code pasted into 
it. Thus having GPL code in the same repository as BSD code can end up 
accidentally converting BSD code to GPL code over time. If GPL was OK with 
everyone we would have started with GPL. The good thing is the BDS code is GPL 
compatible so it can be used for GPL code and bug fixes in the BDS code can be 
merged into to GPL code, but this is a one way operation. 

If you don’t believe me please feel free to sit down and have a long 
conversation with Intel IP lawyers.

> (And, why that doesn't also apply to FatBinPkg.)
> 

There is no IP leakage from a binary. This FAT driver is licensed for use with 
EFI, and given this is a EFI code base that seemed like a good thing. 

I don’t pretent to understand the GPL FAT thing, I guess it is some kind of 
civil disobedience. it does not mater what license you strap on the code the 
the device makers still have to “pay the man”. 

Thanks,

Andrew Fish

PS As I stated before I’m fine removing all the binaries from the main repo, as 
you don’t really want binaries in your production repo, and source level 
debugging is a nice feature and all. 

> -Jordan
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
>> Of Jordan Justen
>> Sent: Wednesday, September 09, 2015 12:58 PM
>> To: Andrew Fish 
>> Cc: Lenny Szubowicz ; Karen Noel 
>> ; Ard Biesheuvel ; 
>> edk2-devel-01 ; Reza Jelveh 
>> ; Alexander Graf ; qemu devel 
>> list ; Hannes Reinecke ; Gabriel 
>> L. Somlo (GMail) ; Peter Jones ; 
>> Peter Batard ; Gerd Hoffmann ; Cole 
>> Robinson ; Paolo Bonzini ; 
>> xen-devel@lists.xen.org; Laszlo Ersek ; Ademar de 
>> Souza Reis Jr. 
>> Subject: Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015
>> 
>> On 2015-09-09 10:04:50, Andrew Fish wrote:
>>> 
 On Sep 9, 2015, at 9:17 AM, Jordan Justen  
 wrote:

 So, related to this, I wonder

Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

2015-09-09 Thread El-Haj-Mahmoud, Samer

The recent expansions beyond BSD where all permissive licenses (BSD like) as 
far as I can tell.

I agree with Andrew, opening the door for GPL licensed code in EDK2 will have 
severe consequences for products that are built using EDK2. 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan 
Justen
Sent: Wednesday, September 09, 2015 12:58 PM
To: Andrew Fish 
Cc: Lenny Szubowicz ; Karen Noel ; Ard 
Biesheuvel ; edk2-devel-01 
; Reza Jelveh ; Alexander Graf 
; qemu devel list ; Hannes Reinecke 
; Gabriel L. Somlo (GMail) ; Peter Jones 
; Peter Batard ; Gerd Hoffmann 
; Cole Robinson ; Paolo Bonzini 
; xen-devel@lists.xen.org; Laszlo Ersek 
; Ademar de Souza Reis Jr. 
Subject: Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

On 2015-09-09 10:04:50, Andrew Fish wrote:
> 
> > On Sep 9, 2015, at 9:17 AM, Jordan Justen  wrote:
> > 
> > So, related to this, I wonder how the community would feel about a 
> > GplDriverPkg. Would the community allow it as a new package in EDK 
> > II directly, or would a separate repo be required?
> > 
> 
> I think we would need a separate repo, like the FAT driver. That is 
> the only way to deal with the license issues.

There doesn't seem to be any guiding rules here. For example, I think some 
people are not comfortable with the FatBinPkg being in the tree due to the 
license. Why is that okay?

> > With regards to adding it directly into the EDK II tree, here are 
> > some potential concerns that I might anticipate hearing from the community:
> > 
> > * It will make it easier for contributors to choose GPL compared to 
> > a  permissive license, thereby limiting some users of the 
> > contribution
> > 
> > * GPL code will more easily be copied into the permissively licensed  
> > packages
> > 
> > * Some might refuse to look at EDK II entirely if it has a directory  
> > with GPL source code in it
> > 
> 
> Or have their rights to contribute revoked since this is a fundamental 
> change, and would require employees to get reauthorized by their legal 
> departments to contribute.

We've recently expanded beyond just allowing BSD code into the tree, and that 
appeared to be no big deal. No one brought this up as a fundamental change.

Just to be clear, are you saying Apple probably won't be able to contribute to 
EDK II if there is any GPL licensed code in the tree?
(Even if it is contained in a clearly indicated package.) I guess using 
dual-licensed BSD/GPL is okay though?
(EmbeddedPkg/Library/FdtLib)

-Jordan
___
edk2-devel mailing list
edk2-de...@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [PATCH] OvmfPkg: prevent code execution from DXE stack)

2015-09-09 Thread Zeng, Star

On 2015/9/9 19:30, Laszlo Ersek wrote:

On 09/09/15 13:07, Ian Campbell wrote:

On Wed, 2015-09-09 at 12:48 +0200, Laszlo Ersek wrote:

Thanks for all the info, I think I get it (although its not clear to me
whether how an app can claim to be UEFI 2.5 capable and what the transition
plan for legacy applications was going to be).

... The question could be then if grub (in Wheezy) should be adapted to
UEFI-2.5 (if that's possible)

I don't know either I'm afraid.

[...]

Hmmm. Actually, I'm torn about the default for PcdSetNxForStack.

I have a question: What attack vector is setting the stack as Nx in OVMF
(or even UEFI generally) trying to protect against? Or is this being done
for a reason other than security?

I think it is being done for security, generally speaking (ie. as far as
edk2 and the UEFI spec are concerned).

Specifically for OVMF, I wrote the patch because Paolo suggested it,
after (I think) he saw Star's feature patch on the edk2 mailing list. I
thought it was a good suggestion, even in case we had no particular
attack in mind: OVMF is frequently used as a UEFI development / test
bed, and we try to enable new edk2 / UEFI features in it, unless the
firmware size increase would be large, or something would break. (In
which cases we usually bracket the new feature with build time flags.)

I did consider regressions while writing this patch. In the commit
message I mentioned "-cpu ,-nx" as a way to turn of NX support in
the virtual CPU (which the edk2 feature dynamically detects and depends
on), should anything break. I did not expect two things: (a) old grub
actually executes stuff from the stack, (b) Xen has no way (?) to
disable NX in a VCPU (or maybe that would be detrimental for other reasons).

I understand why it is done for kernels and apps, but where does the
untrusted element which is being protected against come from when running
UEFI?

I'm sure this is explained in the five ECR documents attached to Mantis
ticket 1224:

https://mantis.uefi.org/mantis/view.php?id=1224

Unfortunately, I don't think I can just publish those ECRs here (or dump
the mantis ticket).

I have no clue why UEFI development is so secretive. I had been annoyed
by not seeing mantis tickets myself (and thereby missing the
justification behind new UEFI features), so at some point I applied for
"non-voter, observer-only" membership in both the PIWG and the USWG, and
I got them. (I'm fuzzy on the details if this was helped by my being
@redhat.com -- it probably was.)

Perhaps you can also apply for membership (and read the ECRs on the
ticket), or hopefully Star (who implemented the feature) could summarize
the purpose here?

According to the mantis, the idea should come from
http://www.uefi.org/sites/default/files/resources/3_-_UEFI_Summit_-_Security_Defenses_PTEC.pdf
and adopted by USWG to UEFI has more abilities to provide defense in depth.

(I won't try, based on the ECRs, because that will unavoidably put me in
the position where I have to explain and defend the feature. Thanks, but
no, thanks :))

Cheers
Laszlo

Thanks,
Star

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [v2][PATCH] xen/vtd/iommu: permit group devices to passthrough in relaxed mode


Need to have separate warning/error level for relax/strict.

However I don't think this patch is a right fix. So far relax/strict policy
is per-domain. what about one VM specifies relax while another VM
specifies strict when each is assigned with a device sharing rmrr
with the other? In that case it becomes a system-wide security hole.

Once we add code to track group relationship cross domains, it'd be
close to the final fix to support group assignment which originally target
4.7. It might be risky to add that in 4.6.


Yes.



So my suggestion is to live with current limitation.



But recently someone was encountering this problem.

http://www.gossamer-threads.com/lists/xen/devel/391684?page=last

We'd better figure out a simple way to this regression.

Thanks
Tiejun

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

> On Sep 9, 2015, at 9:17 AM, Jordan Justen  wrote:
> 
> On 2015-09-09 01:57:51, Laszlo Ersek wrote:
>> On 08/10/15 18:24, Laszlo Ersek wrote:
>>> Hi.
>>> 
>>> Let's do an OVMF BoF at this year's KVM Forum too.
>> 
>> Here's a preliminary task list, after some off-list discussion (I tried
>> to incorporate comments):
>> 
>> - create GPL'd fork called "ovmf" for expediting virt development
>>  (OvmfPkg, ArmVirtPkg)
>>  - maybe leverage the feature under
>>
>> >  > for
>>setting up a separate "tianocore/edk2-gpl" repo, for GPL'd
>>contributions [Jordan]
>>- repo separation by license could make things harder for packagers
>>  and QEMU bundling [Laszlo]
> 
> I would like OVMF to follow a plan for GPL that the whole EDK II
> community decides on.
> 
> I would also like to see EDK II add a (permissively licensed; BSD,
> MIT, etc) DriverPkg (DriversPkg?). We discussed this on the list
> recently:
> 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__thread.gmane.org_gmane.comp.bios.tianocore.devel_17544_focus-3D676=BQICAg=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=Izfl0sCkWmvl39u6ZohbZ52fhf2U-GzLJ9cQpL9sdnA=HauTLYzaQYz935VMYQCCR8xzuSADw1ZcWSSjSyEXIpw=
>  
> 
> So, related to this, I wonder how the community would feel about a
> GplDriverPkg. Would the community allow it as a new package in EDK II
> directly, or would a separate repo be required?
> 

I think we would need a separate repo, like the FAT driver. That is the only 
way to deal with the license issues. 

> With regards to adding it directly into the EDK II tree, here are some
> potential concerns that I might anticipate hearing from the community:
> 
> * It will make it easier for contributors to choose GPL compared to a
>  permissive license, thereby limiting some users of the contribution
> 
> * GPL code will more easily be copied into the permissively licensed
>  packages
> 
> * Some might refuse to look at EDK II entirely if it has a directory
>  with GPL source code in it
> 

Or have their rights to contribute revoked since this is a fundamental change, 
and would require employees to get reauthorized by their legal departments to 
contribute. 

> Of these, I personally only sympathize with the first.
> 

Your employer probably has issues with all of this. 

> Regarding the separate OVMF repo, my hope is that it is more of a OVMF
> specific working area, rather than a 'GPL OVMF'. For example, patches
> or features that we've not yet figured out how to upstream, but we
> hopefully plan to.
> 

Mixing is never going to work. If you mix then the pure BSD edk2 will fork and 
continue, I’m guessing a lot of the Intel resources will work on that version 
as it will be the one enabling Intel products. 

> Additionally, it makes sense to use it as needed for OVMF specific
> releases. (Ie, OVMF release tags)
> 

Seems to me we are really solving the wrong problem. What we need is a smaller 
BSD edk2 project that supports the industry standards and works on some set of 
BSD platforms. There can be down stream consumers that have more platform 
support, and different licenses. 

Seems the real problem is the unpredictable changes to MdePkg libraries, and 
MdeModulePkg infrastructure. So it is the lack of a transparent plan, and 
discussion about upcoming changes that break compatibility between different 
projects. So the solution is to keep everything in the tree working on master. 
We should fix the edk2 process, and place a process in place to communicate 
pending non backward compatible changes in the edk2 to down stream consumers. 

Don’t forget a lot (majority) of edk2 based products that ship today live in a 
separate repo that likely contains a UDK or specific version of edk2 with 
cherry picked patches. So this processes is kind of already happening in the 
non-GPL world….

Thanks,

Andrew Fish

> -Jordan
> 
>> - document the rules / justification for "ovmf" (licensing
>>  conflicts, non-technical blockage on edk2 etc).
>> - No new mailing list needed
>> - push RH's downstream-only patches to "ovmf", wherever that makes
>>  sense
>> - remove encumbered FAT driver
>> - import Peter Batard's GPL r/o FAT driver port of GRUB's
>> - secure OpenSSL linking exception for the former from the copyright
>>  holders (Peter Batard, GRUB project)
>> - "ovmf" should be periodically rebased / should fetch+merge edk2 as
>>  master (arguments both for and against merging); distros should
>>  then track "ovmf" as their upstream, not edk2
>> - get OVMF into Fedora (as pkg) and QEMU (as bundled binary)
>> - do OVMF releases, maybe in sync with QEMU's releases
>>  - we can probably build from known good revisions from git [Alex]
>> - revive Q35 SATA driver work / poke Reza

[Xen-devel] Missing copyright in the Xen header files

2015-09-09 Thread Mike Belopuhov

Hi,

We're in the process of porting Xen PVHVM drivers to OpenBSD
and have come across missing copyright lines on some of Xen
interface header files, for instance:

https://svnweb.freebsd.org/base/head/sys/xen/interface/hvm/hvm_op.h?revision=251767=markup
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/xen/interface/hvm/hvm_op.h

This is not common and we have some concerns whether it is
valid to release source code w/o stating who has granted those
rights that are stated in the license.

Would it be possible to amend the license and add a Copyright
line mentioning Xen project or an individual contributor like
it's done it othe places in the Xen source code?

With kind regards,
Mike

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [linux-3.10 test] 61615: regressions - FAIL

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow2 9 debian-di-install fail REGR. vs. 60670
 test-amd64-amd64-xl-vhd   9 debian-di-install fail REGR. vs. 60670
 test-amd64-i386-freebsd10-amd64 15 guest-saverestore.2fail REGR. vs. 60670
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
60670
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
60670
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
fail REGR. vs. 60670
 test-amd64-i386-xl-qcow2 10 guest-start   fail REGR. vs. 60670
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 12 guest-saverestore fail 
REGR. vs. 60670
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 12 guest-saverestore fail REGR. 
vs. 60670
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 60670
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 60670
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install fail REGR. vs. 60670
 test-amd64-i386-xl-qemuu-winxpsp3  9 windows-install  fail REGR. vs. 60670
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 60670
 test-amd64-amd64-xl-qemut-win7-amd64  9 windows-install   fail REGR. vs. 60670
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install fail REGR. vs. 60670
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 60670
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-installfail REGR. vs. 60670
 test-amd64-amd64-xl-qemuu-win7-amd64  9 windows-install   fail REGR. vs. 60670
 test-amd64-i386-xl-qemut-win7-amd64  9 windows-installfail REGR. vs. 60670
 test-amd64-i386-xl-qemut-debianhvm-amd64 15 guest-localmigrate.2 fail in 60748 
REGR. vs. 60670
 test-amd64-i386-qemuu-rhel6hvm-intel 12 guest-start/redhat.repeat fail in 
60790 REGR. vs. 60670
 test-amd64-i386-qemut-rhel6hvm-amd 10 guest-stop fail in 60790 REGR. vs. 60670
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 13 guest-localmigrate fail in 
60790 REGR. vs. 60670
 test-amd64-i386-freebsd10-i386 14 guest-localmigrate fail in 60865 REGR. vs. 
60670
 test-amd64-i386-xl-qemuu-ovmf-amd64 14 guest-saverestore.2 fail in 60950 REGR. 
vs. 60670
 test-amd64-i386-xl-vhd   10 guest-start  fail in 60950 REGR. vs. 60670
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 12 guest-saverestore fail in 
60950 REGR. vs. 60670
 test-amd64-i386-qemuu-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 60950 
REGR. vs. 60670
 test-amd64-i386-xl-qemut-winxpsp3 12 guest-saverestore fail in 60992 REGR. vs. 
60670
 test-amd64-i386-qemut-rhel6hvm-intel 10 guest-stop fail in 61520 REGR. vs. 
60670

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw  3 host-install(3)  broken in 61520 pass in 61615
 test-amd64-i386-xl6 xen-boot   fail in 60748 pass in 61615
 test-amd64-i386-xl-qemuu-debianhvm-amd64 12 guest-saverestore fail in 60790 
pass in 60865
 test-amd64-i386-libvirt  16 guest-stop fail in 60790 pass in 60865
 test-amd64-amd64-libvirt-xsm 14 guest-saverestore  fail in 60790 pass in 61615
 test-amd64-i386-freebsd10-amd64 14 guest-localmigrate fail in 60790 pass in 
61615
 test-amd64-i386-qemuu-rhel6hvm-intel 11 guest-start.2 fail in 60950 pass in 
60790
 test-amd64-i386-libvirt-xsm 15 guest-saverestore.2 fail in 60950 pass in 60992
 test-amd64-i386-libvirt  14 guest-saverestore  fail in 60950 pass in 61615
 test-amd64-i386-freebsd10-amd64 13 guest-saverestore fail in 60950 pass in 
61615
 test-amd64-i386-xl-qcow2  9 debian-di-install  fail in 60950 pass in 61615
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail in 
60950 pass in 61615
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
in 60950 pass in 61615
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail in 
60950 pass in 61615
 test-amd64-i386-qemuu-rhel6hvm-intel 9 redhat-install fail in 61520 pass in 
61615
 test-amd64-i386-qemuu-rhel6hvm-amd 9 redhat-install fail in 61520 pass in 61615
 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail pass in 
60748
 test-amd64-i386-qemut-rhel6hvm-amd  9 redhat-installfail pass in 60790
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 12 guest-saverestore fail pass in 
60790
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail pass in 
60865
 test-amd64-i386-libvirt  15 guest-saverestore.2 fail pass in 60865
 test-amd64-i386-freebsd10-i386 13 guest-saverestore fail pass in 60865
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install   fail pass in 60950
 test-amd64-i386-xl-vhd9 debian-di-install   fail pass in 60950
 test-amd64-i386-qemuu-rhel6hvm-intel 10 guest-stop  fail

[Xen-devel] [qemu-upstream-4.4-testing test] 61617: regressions - FAIL

flight 61617 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/61617/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-vhd9 debian-di-install fail REGR. vs. 60565

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-raw   9 debian-di-install fail REGR. vs. 60565
 test-amd64-i386-libvirt  11 guest-start  fail   like 60565
 test-amd64-amd64-libvirt 11 guest-start  fail   like 60565

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qcow2  9 debian-di-installfail  never pass
 test-amd64-amd64-xl-raw   9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-i386-libvirt-pair 20 guest-start/debian   fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu181e2e0ff39cbfeab173fa6d6b31839f00efcd06
baseline version:
 qemuu0fc147387f0b683d2dfefec7b1af569f17b72e9c

Last test of basis60565  2015-08-04 01:59:38 Z   36 days
Testing same since61617  2015-09-08 12:10:54 Z1 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Peter Lieven 

jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt fail
 test-amd64-i386-libvirt  fail
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-libvirt-pairfail
 test-amd64-i386-libvirt-pair fail
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-libvirt-qcow2   pass
 test-amd64-i386-libvirt-qcow2fail
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-qcow2 pass
 test-amd64-amd64-libvirt-raw pass
 test-amd64-i386-libvirt-raw  fail
 test-amd64-amd64-xl-raw  fail
 test-amd64-i386-xl-raw   pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-libvirt-vhd pass

[Xen-devel] [PATCH for 4.6 v2 0/3] More vNUMA patches

Discovered some fallouts when I tried to fix a migration v2 bug

Wei Liu (3):
  libxl: set ret to non-zero value in failure path
  libxc: introduce xc_domain_getvnuma
  xl/libxl: disallow saving a guest with vNUMA configured

 docs/man/xl.cfg.pod.5 |  2 ++
 tools/libxc/include/xenctrl.h | 18 +++
 tools/libxc/xc_domain.c   | 54 +++
 tools/libxl/libxl_create.c|  1 +
 tools/libxl/libxl_dom.c   | 14 +++
 5 files changed, 89 insertions(+)

-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH for 4.6 v2 3/3] xl/libxl: disallow saving a guest with vNUMA configured

This is due to migration v2 frame record doesn't contain node
information.

Signed-off-by: Wei Liu 
---
Cc: andrew.coop...@citrix.com
---
 docs/man/xl.cfg.pod.5   |  2 ++
 tools/libxl/libxl_dom.c | 14 ++
 2 files changed, 16 insertions(+)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 80e51bb..dbd0700 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -263,6 +263,8 @@ virtual node.
 
 Note that virtual NUMA for PV guest is not yet supported, because
 there is an issue with cpuid handling that affects PV virtual NUMA.
+Further more, guest with virtual NUMA cannot be saved or migrated
+because node information of guest frames is not preserved.
 
 Each B is a list, which has a form of
 "[VNODE_CONFIG_OPTION,VNODE_CONFIG_OPTION, ... ]"  (without quotes).
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c2518a3..5dc4d3a 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
 {
@@ -1612,6 +1613,7 @@ void libxl__domain_save(libxl__egc *egc, 
libxl__domain_suspend_state *dss)
 const libxl_domain_remus_info *const r_info = dss->remus;
 libxl__srm_save_autogen_callbacks *const callbacks =
 >sws.shs.callbacks.save.a;
+unsigned int nr_vnodes = 0, nr_vmemranges = 0, nr_vcpus = 0;
 
 dss->rc = 0;
 logdirty_init(>logdirty);
@@ -1636,6 +1638,18 @@ void libxl__domain_save(libxl__egc *egc, 
libxl__domain_suspend_state *dss)
   | (debug ? XCFLAGS_DEBUG : 0)
   | (dss->hvm ? XCFLAGS_HVM : 0);
 
+/* Disallow saving a guest with vNUMA configured because migration
+ * v2 record doesn't contain node information for guest frame.
+ */
+rc = xc_domain_getvnuma(CTX->xch, domid, _vnodes, _vmemranges,
+_vcpus, NULL, NULL, NULL);
+assert(rc == -1 && (errno == XEN_ENOBUFS || errno == XEN_EOPNOTSUPP));
+if (errno == XEN_ENOBUFS && nr_vnodes) {
+LOG(ERROR, "Cannot save a guest with vNUMA configured");
+rc = ERROR_FAIL;
+goto out;
+}
+
 dss->guest_evtchn.port = -1;
 dss->guest_evtchn_lockfd = -1;
 dss->guest_responded = 0;
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH for 4.6 v2 1/3] libxl: set ret to non-zero value in failure path

... otherwise we have something like:

xl: libxl_create.c:968: initiate_domain_create: Assertion `ret' failed.

Signed-off-by: Wei Liu 
---
 tools/libxl/libxl_create.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 5128160..29c2641 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -865,6 +865,7 @@ static void initiate_domain_create(libxl__egc *egc,
  */
 if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
 d_config->b_info.num_vnuma_nodes) {
+ret = ERROR_INVAL;
 LOG(ERROR, "PV vNUMA is not yet supported");
 goto error_out;
 }
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for 4.6 v2 3/3] xl/libxl: disallow saving a guest with vNUMA configured

2015-09-09 Thread Boris Ostrovsky


On 09/09/2015 01:03 PM, Wei Liu wrote:

This is due to migration v2 frame record doesn't contain node
information.

Signed-off-by: Wei Liu 
---
Cc: andrew.coop...@citrix.com
---
  docs/man/xl.cfg.pod.5   |  2 ++
  tools/libxl/libxl_dom.c | 14 ++
  2 files changed, 16 insertions(+)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 80e51bb..dbd0700 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -263,6 +263,8 @@ virtual node.
  
  Note that virtual NUMA for PV guest is not yet supported, because

  there is an issue with cpuid handling that affects PV virtual NUMA.
+Further more, guest with virtual NUMA cannot be saved or migrated
+because node information of guest frames is not preserved.


Should we also issue a warning during startup if nomigrate is not set?

-boris

  
  Each B is a list, which has a form of

  "[VNODE_CONFIG_OPTION,VNODE_CONFIG_OPTION, ... ]"  (without quotes).
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c2518a3..5dc4d3a 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -24,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 
  
  libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)

  {
@@ -1612,6 +1613,7 @@ void libxl__domain_save(libxl__egc *egc, 
libxl__domain_suspend_state *dss)
  const libxl_domain_remus_info *const r_info = dss->remus;
  libxl__srm_save_autogen_callbacks *const callbacks =
  >sws.shs.callbacks.save.a;
+unsigned int nr_vnodes = 0, nr_vmemranges = 0, nr_vcpus = 0;
  
  dss->rc = 0;

  logdirty_init(>logdirty);
@@ -1636,6 +1638,18 @@ void libxl__domain_save(libxl__egc *egc, 
libxl__domain_suspend_state *dss)
| (debug ? XCFLAGS_DEBUG : 0)
| (dss->hvm ? XCFLAGS_HVM : 0);
  
+/* Disallow saving a guest with vNUMA configured because migration

+ * v2 record doesn't contain node information for guest frame.
+ */
+rc = xc_domain_getvnuma(CTX->xch, domid, _vnodes, _vmemranges,
+_vcpus, NULL, NULL, NULL);
+assert(rc == -1 && (errno == XEN_ENOBUFS || errno == XEN_EOPNOTSUPP));
+if (errno == XEN_ENOBUFS && nr_vnodes) {
+LOG(ERROR, "Cannot save a guest with vNUMA configured");
+rc = ERROR_FAIL;
+goto out;
+}
+
  dss->guest_evtchn.port = -1;
  dss->guest_evtchn_lockfd = -1;
  dss->guest_responded = 0;



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

On 2015-09-09 10:04:50, Andrew Fish wrote:
> 
> > On Sep 9, 2015, at 9:17 AM, Jordan Justen  wrote:
> > 
> > So, related to this, I wonder how the community would feel about a
> > GplDriverPkg. Would the community allow it as a new package in EDK II
> > directly, or would a separate repo be required?
> > 
> 
> I think we would need a separate repo, like the FAT driver. That is
> the only way to deal with the license issues.

There doesn't seem to be any guiding rules here. For example, I think
some people are not comfortable with the FatBinPkg being in the tree
due to the license. Why is that okay?

> > With regards to adding it directly into the EDK II tree, here are some
> > potential concerns that I might anticipate hearing from the community:
> > 
> > * It will make it easier for contributors to choose GPL compared to a
> >  permissive license, thereby limiting some users of the contribution
> > 
> > * GPL code will more easily be copied into the permissively licensed
> >  packages
> > 
> > * Some might refuse to look at EDK II entirely if it has a directory
> >  with GPL source code in it
> > 
> 
> Or have their rights to contribute revoked since this is a
> fundamental change, and would require employees to get reauthorized
> by their legal departments to contribute.

We've recently expanded beyond just allowing BSD code into the tree,
and that appeared to be no big deal. No one brought this up as a
fundamental change.

Just to be clear, are you saying Apple probably won't be able to
contribute to EDK II if there is any GPL licensed code in the tree?
(Even if it is contained in a clearly indicated package.) I guess
using dual-licensed BSD/GPL is okay though?
(EmbeddedPkg/Library/FdtLib)

-Jordan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH OSSTEST] ts-xen-install: Rewrite /etc/hosts to comment out 127.0.1.1 entry

On Wed, 2015-09-09 at 18:31 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST] ts-xen-install: Rewrite
> /etc/hosts to comment out 127.0.1.1 entry"):
> > +   s|^127.0.1.1|#$&|;
> 
> I think you mean
> 
> s|^\Q127.0.1.1\E\b|#$&|;
> 
> or
> 
> s|^127\.0\.1\.1\b|#$&|;
> 
> (I have tested both of these ad-hoc.)

Yes, I went with the former.

> Also
> 
> > +my $hn = $ho->{Name};
> 
> This seems unused ?

Right, it was a remnant of a previous attempt.

> With those two this corrected.
> 
> Acked-by: Ian Jackson 

Thanks, I've added the following to pretest.

Ian.

commit e1adb8b552dda5c653958083c9c7457f0398ad09
Author: Ian Campbell 
Date:   Mon Sep 7 13:58:29 2015 +0100

ts-xen-install: Rewrite /etc/hosts to comment out 127.0.1.1 entry

Debian creates an entry such as:
127.0.1.1 lace-bug.xs.citrite.net lace-bug

This causes local lookups of the FQDN to get 127.0.1.1, which is
unhelpful if you are looking for an address to bind to and were hoping
to get the public IP address, as libvirt does on the target host for
migration.

Here we remove (actually, comment) any 127.0.1.1 line in /etc/hosts.
This means that lookups of a hosts own name (fqdn or just dn) now rely
on DNS, which may not be ideal. However for a host which uses DHCP I'm
not aware of a way to keep /etc/hosts up to date with the actual IP
address the machine has.  In our infra the test host IP addresses are
all static, but I don't think we want to rely on at any more that we
already do.

Signed-off-by: Ian Campbell 
Acked-by: Ian Jackson 

diff --git a/ts-xen-install b/ts-xen-install
index 070e74d..b511e2b 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -230,6 +230,23 @@ END
 target_cmd_root($ho, $cmd);
 }

+sub hosts () {
+# Debian installer generates a line like:
+#
+# 127.0.1.1 lace-bug.xs.citrite.net lace-bug
+#
+# Where xs.citrite.net is $c{TestHostDomain} and lace-bug is the
+# hostname, this causes lookups of the hosts FQDN to result in
+# 127.0.1.1 which is not useful if the reason for the lookup was
+# to be able to bind to the externally accessible IP address.
+target_editfile_root($ho, "/etc/hosts", "etc-hosts", sub {
+while () {
+   s|^\Q127.0.1.1\E\b|#$&|;
+   print EO;
+}
+});
+}
+
 sub nodhcp () {
 target_editfile_root($ho, "/etc/network/interfaces",
  "etc-network-interfaces", sub {
@@ -351,4 +368,5 @@ if ($checkmode) {
 setupboot();
 setupinitd();
 nodhcp();
+hosts();
 }

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PULL 0/19] xen-2015-09-08-tag

2015-09-09 Thread Peter Maydell

On 9 September 2015 at 14:06, Stefano Stabellini
 wrote:
> Speak about build environments, Peter, would you care to share your
> scripts and setup so that I can run similar tests in the future on my
> own?  I have no OSX machines so I tried to do a Windows
> cross-compile, following http://wiki.qemu.org/Hosts/W32 on Debian 7, but
> I failed very early with an "ERROR: zlib check failed".

My build scripts are at
https://git.linaro.org/people/peter.maydell/misc-scripts.git
(in particular pull-buildtest runs the test and remake-merge-builds
does the one-time configure-each-build-tree setup.) But they're really
just doing a make/make check. I don't have scripts for getting the
cross-compile environment set up in the first place, I'm afraid.

Your error message means you're missing the zlib cross library.
Fedora provides packaged versions of all the cross libs, but for
Debian you have to download them from the upstream websites and
stick them in a directory somewhere.

My (Ubuntu-based) instructions from last time somebody asked:
https://lists.gnu.org/archive/html/qemu-devel/2015-04/msg00688.html

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] OVMF BoF @ KVM Forum 2015

2015-09-09 Thread Laszlo Ersek

On 09/09/15 18:34, Ian Campbell wrote:
> On Wed, 2015-09-09 at 10:57 +0200, Laszlo Ersek wrote:
>> On 08/10/15 18:24, Laszlo Ersek wrote:
>>> Hi.
>>>
>>> Let's do an OVMF BoF at this year's KVM Forum too.
>>
>> Here's a preliminary task list
> 
> Thanks for including xen-devel in this. Was anyone from the Xen community
> present at the BoF (so far as you know)?

Noone was. And I know it for a fact, because all of the handful of BoF
participants were sitting around one table. :)

(If someone speaks up now, "hey I was there, and I'm a Xen guy", then
I'll just dig myself a pit.)

> Are there any minutes or anything
> like that for those interested in the discussion and reasoning rather than
> just the resulting action items?

Not really; I think this todo list is pretty comprehensive. I remember
talking a lot and having trouble breathing (I had gotten sick just a few
days earlier -- yay crowded conferences and parties), but I tend to
speak in many details about few things, and not concisely about many things.

Should you care about those details, I've now forgotten them all. They
probably weren't important anyway. I recall trying to convince Jordan
politely to review my SMM patches. We probably discussed some SMM details.

... Please ask Jordan or the other participants, they weren't sick, and
they don't have a chronic verbosity problem.

... Man, it must be great to work with me! ;)

Thanks for your interest!
Laszlo

> 
> Thanks,
> Ian.
> 
>> , after some off-list discussion (I tried
>> to incorporate comments):
>>
>> - create GPL'd fork called "ovmf" for expediting virt development
>>   (OvmfPkg, ArmVirtPkg)
>>   - maybe leverage the feature under
>>  for
>> setting up a separate "tianocore/edk2-gpl" repo, for GPL'd
>> contributions [Jordan]
>> - repo separation by license could make things harder for packagers
>>   and QEMU bundling [Laszlo]
>> - document the rules / justification for "ovmf" (licensing
>>   conflicts, non-technical blockage on edk2 etc).
>> - No new mailing list needed
>> - push RH's downstream-only patches to "ovmf", wherever that makes
>>   sense
>> - remove encumbered FAT driver
>> - import Peter Batard's GPL r/o FAT driver port of GRUB's
>> - secure OpenSSL linking exception for the former from the copyright
>>   holders (Peter Batard, GRUB project)
>> - "ovmf" should be periodically rebased / should fetch+merge edk2 as
>>   master (arguments both for and against merging); distros should
>>   then track "ovmf" as their upstream, not edk2
>> - get OVMF into Fedora (as pkg) and QEMU (as bundled binary)
>> - do OVMF releases, maybe in sync with QEMU's releases
>>   - we can probably build from known good revisions from git [Alex]
>> - revive Q35 SATA driver work / poke Reza
>>   - Hannes and Gabriel have refreshed patches, but their versions differ
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for 4.6 v2 3/3] xl/libxl: disallow saving a guest with vNUMA configured

On Wed, Sep 09, 2015 at 01:17:40PM -0400, Boris Ostrovsky wrote:
> On 09/09/2015 01:03 PM, Wei Liu wrote:
> >This is due to migration v2 frame record doesn't contain node
> >information.
> >
> >Signed-off-by: Wei Liu 
> >---
> >Cc: andrew.coop...@citrix.com
> >---
> >  docs/man/xl.cfg.pod.5   |  2 ++
> >  tools/libxl/libxl_dom.c | 14 ++
> >  2 files changed, 16 insertions(+)
> >
> >diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> >index 80e51bb..dbd0700 100644
> >--- a/docs/man/xl.cfg.pod.5
> >+++ b/docs/man/xl.cfg.pod.5
> >@@ -263,6 +263,8 @@ virtual node.
> >  Note that virtual NUMA for PV guest is not yet supported, because
> >  there is an issue with cpuid handling that affects PV virtual NUMA.
> >+Further more, guest with virtual NUMA cannot be saved or migrated
> >+because node information of guest frames is not preserved.
> 
> Should we also issue a warning during startup if nomigrate is not set?
> 



Ah, there is such option. I can certainly give a warning. The only
problem is it seems to be stale in libxl, there is no code that checks
that! I can still migrate a guest even with nomigrate set to true.

Maybe someone with more knowledge about that option can lecture me on
what that does? The manpage says it *enables* certain feature? Does that
actually mean *make available*?

Wei.


> -boris
> 
> >  Each B is a list, which has a form of
> >  "[VNODE_CONFIG_OPTION,VNODE_CONFIG_OPTION, ... ]"  (without quotes).
> >diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> >index c2518a3..5dc4d3a 100644
> >--- a/tools/libxl/libxl_dom.c
> >+++ b/tools/libxl/libxl_dom.c
> >@@ -24,6 +24,7 @@
> >  #include 
> >  #include 
> >  #include 
> >+#include 
> >  libxl_domain_type libxl__domain_type(libxl__gc *gc, uint32_t domid)
> >  {
> >@@ -1612,6 +1613,7 @@ void libxl__domain_save(libxl__egc *egc, 
> >libxl__domain_suspend_state *dss)
> >  const libxl_domain_remus_info *const r_info = dss->remus;
> >  libxl__srm_save_autogen_callbacks *const callbacks =
> >  >sws.shs.callbacks.save.a;
> >+unsigned int nr_vnodes = 0, nr_vmemranges = 0, nr_vcpus = 0;
> >  dss->rc = 0;
> >  logdirty_init(>logdirty);
> >@@ -1636,6 +1638,18 @@ void libxl__domain_save(libxl__egc *egc, 
> >libxl__domain_suspend_state *dss)
> >| (debug ? XCFLAGS_DEBUG : 0)
> >| (dss->hvm ? XCFLAGS_HVM : 0);
> >+/* Disallow saving a guest with vNUMA configured because migration
> >+ * v2 record doesn't contain node information for guest frame.
> >+ */
> >+rc = xc_domain_getvnuma(CTX->xch, domid, _vnodes, _vmemranges,
> >+_vcpus, NULL, NULL, NULL);
> >+assert(rc == -1 && (errno == XEN_ENOBUFS || errno == XEN_EOPNOTSUPP));
> >+if (errno == XEN_ENOBUFS && nr_vnodes) {
> >+LOG(ERROR, "Cannot save a guest with vNUMA configured");
> >+rc = ERROR_FAIL;
> >+goto out;
> >+}
> >+
> >  dss->guest_evtchn.port = -1;
> >  dss->guest_evtchn_lockfd = -1;
> >  dss->guest_responded = 0;

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for 4.6 v2 3/3] xl/libxl: disallow saving a guest with vNUMA configured

2015-09-09 Thread Boris Ostrovsky


On 09/09/2015 01:29 PM, Wei Liu wrote:

On Wed, Sep 09, 2015 at 01:17:40PM -0400, Boris Ostrovsky wrote:

On 09/09/2015 01:03 PM, Wei Liu wrote:

This is due to migration v2 frame record doesn't contain node
information.

Signed-off-by: Wei Liu 
---
Cc: andrew.coop...@citrix.com
---
  docs/man/xl.cfg.pod.5   |  2 ++
  tools/libxl/libxl_dom.c | 14 ++
  2 files changed, 16 insertions(+)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 80e51bb..dbd0700 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -263,6 +263,8 @@ virtual node.
  Note that virtual NUMA for PV guest is not yet supported, because
  there is an issue with cpuid handling that affects PV virtual NUMA.
+Further more, guest with virtual NUMA cannot be saved or migrated
+because node information of guest frames is not preserved.

Should we also issue a warning during startup if nomigrate is not set?




Ah, there is such option. I can certainly give a warning. The only
problem is it seems to be stale in libxl, there is no code that checks
that! I can still migrate a guest even with nomigrate set to true.

Maybe someone with more knowledge about that option can lecture me on
what that does? The manpage says it *enables* certain feature? Does that
actually mean *make available*?


IIRC it was added to allow/control certain TSC modes (see domain_cpuid()).

-boris



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] OVMF BoF @ KVM Forum 2015

On Wed, 2015-09-09 at 10:57 +0200, Laszlo Ersek wrote:
> On 08/10/15 18:24, Laszlo Ersek wrote:
> > Hi.
> > 
> > Let's do an OVMF BoF at this year's KVM Forum too.
> 
> Here's a preliminary task list

Thanks for including xen-devel in this. Was anyone from the Xen community
present at the BoF (so far as you know)? Are there any minutes or anything
like that for those interested in the discussion and reasoning rather than
just the resulting action items?

Thanks,
Ian.

> , after some off-list discussion (I tried
> to incorporate comments):
> 
> - create GPL'd fork called "ovmf" for expediting virt development
>   (OvmfPkg, ArmVirtPkg)
>   - maybe leverage the feature under
>  for
> setting up a separate "tianocore/edk2-gpl" repo, for GPL'd
> contributions [Jordan]
> - repo separation by license could make things harder for packagers
>   and QEMU bundling [Laszlo]
> - document the rules / justification for "ovmf" (licensing
>   conflicts, non-technical blockage on edk2 etc).
> - No new mailing list needed
> - push RH's downstream-only patches to "ovmf", wherever that makes
>   sense
> - remove encumbered FAT driver
> - import Peter Batard's GPL r/o FAT driver port of GRUB's
> - secure OpenSSL linking exception for the former from the copyright
>   holders (Peter Batard, GRUB project)
> - "ovmf" should be periodically rebased / should fetch+merge edk2 as
>   master (arguments both for and against merging); distros should
>   then track "ovmf" as their upstream, not edk2
> - get OVMF into Fedora (as pkg) and QEMU (as bundled binary)
> - do OVMF releases, maybe in sync with QEMU's releases
>   - we can probably build from known good revisions from git [Alex]
> - revive Q35 SATA driver work / poke Reza
>   - Hannes and Gabriel have refreshed patches, but their versions differ
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH for 4.6 v2 2/3] libxc: introduce xc_domain_getvnuma

A simple wrapper for XENMEM_get_vnumainfo.

Signed-off-by: Wei Liu 
---
 tools/libxc/include/xenctrl.h | 18 +++
 tools/libxc/xc_domain.c   | 54 +++
 2 files changed, 72 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 742724e..b477d8a 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1287,6 +1287,24 @@ int xc_domain_setvnuma(xc_interface *xch,
 unsigned int *vdistance,
 unsigned int *vcpu_to_vnode,
 unsigned int *vnode_to_pnode);
+/*
+ * Retrieve vnuma configuration
+ * domid: IN, target domid
+ * nr_vnodes: IN/OUT, number of vnodes, not NULL
+ * nr_vmemranges: IN/OUT, number of vmemranges, not NULL
+ * nr_vcpus: IN/OUT, number of vcpus, not NULL
+ * vmemranges: OUT, an array which has length of nr_vmemranges
+ * vdistance: OUT, an array which has length of nr_vnodes * nr_vnodes
+ * vcpu_to_vnode: OUT, an array which has length of nr_vcpus
+ */
+int xc_domain_getvnuma(xc_interface *xch,
+   uint32_t domid,
+   uint32_t *nr_vnodes,
+   uint32_t *nr_vmemranges,
+   uint32_t *nr_vcpus,
+   xen_vmemrange_t *vmemrange,
+   unsigned int *vdistance,
+   unsigned int *vcpu_to_vnode);
 
 #if defined(__i386__) || defined(__x86_64__)
 /*
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 780797f..09ef748 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -2493,6 +2493,60 @@ int xc_domain_setvnuma(xc_interface *xch,
 return rc;
 }
 
+int xc_domain_getvnuma(xc_interface *xch,
+   uint32_t domid,
+   uint32_t *nr_vnodes,
+   uint32_t *nr_vmemranges,
+   uint32_t *nr_vcpus,
+   xen_vmemrange_t *vmemrange,
+   unsigned int *vdistance,
+   unsigned int *vcpu_to_vnode)
+{
+int rc;
+DECLARE_HYPERCALL_BOUNCE(vmemrange, sizeof(*vmemrange) * *nr_vmemranges,
+ XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+DECLARE_HYPERCALL_BOUNCE(vdistance, sizeof(*vdistance) *
+ *nr_vnodes * *nr_vnodes,
+ XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+DECLARE_HYPERCALL_BOUNCE(vcpu_to_vnode, sizeof(*vcpu_to_vnode) * *nr_vcpus,
+ XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+
+struct xen_vnuma_topology_info vnuma_topo;
+
+if ( xc_hypercall_bounce_pre(xch, vmemrange)  ||
+ xc_hypercall_bounce_pre(xch, vdistance)  ||
+ xc_hypercall_bounce_pre(xch, vcpu_to_vnode) )
+{
+rc = -1;
+errno = ENOMEM;
+goto vnumaget_fail;
+}
+
+set_xen_guest_handle(vnuma_topo.vmemrange.h, vmemrange);
+set_xen_guest_handle(vnuma_topo.vdistance.h, vdistance);
+set_xen_guest_handle(vnuma_topo.vcpu_to_vnode.h, vcpu_to_vnode);
+
+vnuma_topo.nr_vnodes = *nr_vnodes;
+vnuma_topo.nr_vcpus = *nr_vcpus;
+vnuma_topo.nr_vmemranges = *nr_vmemranges;
+vnuma_topo.domid = domid;
+vnuma_topo.pad = 0;
+
+rc = do_memory_op(xch, XENMEM_get_vnumainfo, _topo,
+  sizeof(vnuma_topo));
+
+*nr_vnodes = vnuma_topo.nr_vnodes;
+*nr_vcpus = vnuma_topo.nr_vcpus;
+*nr_vmemranges = vnuma_topo.nr_vmemranges;
+
+ vnumaget_fail:
+xc_hypercall_bounce_post(xch, vmemrange);
+xc_hypercall_bounce_post(xch, vdistance);
+xc_hypercall_bounce_post(xch, vcpu_to_vnode);
+
+return rc;
+}
+
 /*
  * Local variables:
  * mode: C
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PULL 0/19] xen-2015-09-08-tag

2015-09-09 Thread Peter Maydell

On 9 September 2015 at 17:10, Stefano Stabellini
 wrote:
> I found another issue introduced by the gfx passthrough series on
> Windows:
>
> ../hw/pci-host/piix.o: In function `host_pci_config_read':
> /root/qemu/hw/pci-host/piix.c:778: undefined reference to `_pread'
>
> It is introduced by:
>
> commit fdb70721ba0496a767137e5505dd27627d19c4a8
> Author: Tiejun Chen 
> Date:   Wed Jul 15 13:37:43 2015 +0800
>
> piix: create host bridge to passthrough
>
>
> You might have to replace the pread call with lseek and read.

Will passthrough even work on Windows and OSX hosts?
Consider whether we should be building this code on those
hosts at all...

thanks
-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

2015-09-09 Thread Paolo Bonzini

Well, FatPkg is only superficially permissive and not even open source, so 
there is a precedent. (A precedent that, I might add, happens to violate 
SourceForge's the off service).

When we import edk2 into Fedora we just remove FatBinPkg. We would think twice 
before contributing to it, but do not make any kind of fuss about it.

GPL is just the same. For example, it would be possible to have an 
automatically-updated git repo that omits the GPL directory; and development 
would then be easier for people whose legal departments tend not to influence 
the engineers' productivity.

In fact:

1) it is not like, among non-Intel contributors, proprietary software companies 
have the lion's share of edk2 commits, and they probably use Tiano releases. 
Intel could strip any GPL pieces as part of the Tiano release process.

2) the GPL is working just fine for Linux, which is not that different from 
UEFI. So, picture me skeptical. If anything, what Linux can teach edk2 is that 
a closed prices and balkanized trees are a direct cause of the abysmal security 
of those implementations.

Paolo

-Original Message-
From: El-Haj-Mahmoud, Samer [samer.el-haj-mahm...@hpe.com]
Received: mercoledì, 09 set 2015, 21:12
To: Jordan Justen [jordan.l.jus...@intel.com]; Andrew Fish [af...@apple.com]
CC: Lenny Szubowicz [lenn...@redhat.com]; Karen Noel [kn...@redhat.com]; Ard 
Biesheuvel [ard.biesheu...@linaro.org]; edk2-devel-01 [edk2-de...@ml01.01.org]; 
Reza Jelveh [reza.jel...@tuhh.de]; Alexander Graf [ag...@suse.de]; qemu devel 
list [qemu-de...@nongnu.org]; Hannes Reinecke [h...@suse.de]; Gabriel L. Somlo 
(GMail) [gso...@gmail.com]; Peter Jones [pjo...@redhat.com]; Peter Batard 
[p...@akeo.ie]; Gerd Hoffmann [kra...@redhat.com]; Cole Robinson 
[crobi...@redhat.com]; Paolo Bonzini [pbonz...@redhat.com]; 
xen-devel@lists.xen.org [xen-devel@lists.xen.org]; Laszlo Ersek 
[ler...@redhat.com]; Ademar de Souza Reis Jr. [ar...@redhat.com]
Subject: RE: [edk2] EDK II & GPL - Re:  OVMF BoF @ KVM Forum 2015

The recent expansions beyond BSD where all permissive licenses (BSD like) as 
far as I can tell.

I agree with Andrew, opening the door for GPL licensed code in EDK2 will have 
severe consequences for products that are built using EDK2. 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan 
Justen
Sent: Wednesday, September 09, 2015 12:58 PM
To: Andrew Fish 
Cc: Lenny Szubowicz ; Karen Noel ; Ard 
Biesheuvel ; edk2-devel-01 
; Reza Jelveh ; Alexander Graf 
; qemu devel list ; Hannes Reinecke 
; Gabriel L. Somlo (GMail) ; Peter Jones 
; Peter Batard ; Gerd Hoffmann 
; Cole Robinson ; Paolo Bonzini 
; xen-devel@lists.xen.org; Laszlo Ersek 
; Ademar de Souza Reis Jr. 
Subject: Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

On 2015-09-09 10:04:50, Andrew Fish wrote:
> 
> > On Sep 9, 2015, at 9:17 AM, Jordan Justen  wrote:
> > 
> > So, related to this, I wonder how the community would feel about a 
> > GplDriverPkg. Would the community allow it as a new package in EDK 
> > II directly, or would a separate repo be required?
> > 
> 
> I think we would need a separate repo, like the FAT driver. That is 
> the only way to deal with the license issues.

There doesn't seem to be any guiding rules here. For example, I think some 
people are not comfortable with the FatBinPkg being in the tree due to the 
license. Why is that okay?

> > With regards to adding it directly into the EDK II tree, here are 
> > some potential concerns that I might anticipate hearing from the community:
> > 
> > * It will make it easier for contributors to choose GPL compared to 
> > a  permissive license, thereby limiting some users of the 
> > contribution
> > 
> > * GPL code will more easily be copied into the permissively licensed  
> > packages
> > 
> > * Some might refuse to look at EDK II entirely if it has a directory  
> > with GPL source code in it
> > 
> 
> Or have their rights to contribute revoked since this is a fundamental 
> change, and would require employees to get reauthorized by their legal 
> departments to contribute.

We've recently expanded beyond just allowing BSD code into the tree, and that 
appeared to be no big deal. No one brought this up as a fundamental change.

Just to be clear, are you saying Apple probably won't be able to contribute to 
EDK II if there is any GPL licensed code in the tree?
(Even if it is contained in a clearly indicated package.) I guess using 
dual-licensed BSD/GPL is okay though?
(EmbeddedPkg/Library/FdtLib)

-Jordan
___
edk2-devel mailing list

Re: [Xen-devel] [PATCH for 4.6 v2 3/3] xl/libxl: disallow saving a guest with vNUMA configured