> From: David Vrabel [mailto:david.vra...@citrix.com]
> Sent: Monday, February 01, 2016 10:50 PM
>
> On 20/12/15 06:56, Tian, Kevin wrote:
> >> From: David Vrabel [mailto:david.vra...@citrix.com]
> >> Sent: Friday, December 18, 2015 9:51 PM
> >>
> >> Holding the p2m lock while calling ept_sync_dom
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, January 30, 2016 3:18 AM
>
> c/s 0f1cb96e "x86 hvm: Allow cross-vendor migration" caused HVM domains to
> unconditionally intercept #UD exceptions. While cross-vendor migration is
> cool as a demo, it is extremely niche.
>
On Fri, Jan 29, 2016 at 11:21:48AM +0100, Juergen Gross wrote:
> When modifying the timeslice of the credit scheduler in a cpupool the
> cpupool global credit value (n_cpus * credits_per_tslice) isn't
> recalculated. This will lead to wrong scheduling decisions later.
>
> Do the recalculation when
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, January 28, 2016 2:11 AM
>
> Most updates to the exception bitmaps set or clear an individual bits.
>
> However, entering or exiting emulated real mode unilaterally clobbers it,
> leaving the exit code to recalculate what
On 02/02/16 15:48, Tian, Kevin wrote:
> > From: Zhang, Haozhong
> > Sent: Tuesday, February 02, 2016 3:39 PM
> >
> > > btw, how is persistency guaranteed in KVM/QEMU, cross guest
> > > power off/on? I guess since Qemu process is killed the allocated pmem
> > > will be freed so you may switch to fi
> From: Zhang, Haozhong
> Sent: Tuesday, February 02, 2016 3:39 PM
>
> > btw, how is persistency guaranteed in KVM/QEMU, cross guest
> > power off/on? I guess since Qemu process is killed the allocated pmem
> > will be freed so you may switch to file-backed method to keep
> > persistency (however
Hi,
> +realloc:
> +opregion = malloc_high(size * 1024);
memalign_high(PAGE_SIZE, size * 1024);
> > I'd have qemu copy the data on 0xfc write then, so things continue to
> > work without updating seabios. So, the firmware has to allocate space,
> > reserve it etc., and programming the 0xf
On Mon, Feb 01, 2016 at 12:19:23PM +, Wei Liu wrote:
> On Mon, Feb 01, 2016 at 05:11:19AM -0700, Jan Beulich wrote:
> > >>> On 01.02.16 at 11:45, wrote:
> > > * xsave/xrtors support
> > > - Shuai Ruan
> >
> > As per
> > http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg03264.
Hi Kevin,
Thanks for your review!
On 02/02/16 14:33, Tian, Kevin wrote:
> > From: Zhang, Haozhong
> > Sent: Monday, February 01, 2016 1:44 PM
> >
> [...]
> >
> > 1.2 ACPI Support
> >
> > ACPI provides two factors of support for NVDIMM. First, NVDIMM
> > devices are described by firmware (BIO
From: George Dunlap
At the moment, the pfec argument to gva_to_gfn has two functions:
* To inform guest_walk what kind of access is happenind
* As a value to pass back into the guest in the event of a fault.
Unfortunately this is not quite treated consistently: the hvm_fetch_*
function will "p
The XSAVE feature set can operate on PKRU state only if the feature set is
enabled (CR4.OSXSAVE = 1) and has been configured to manage PKRU state
(XCR0[9] = 1). And XCR0.PKRU is disabled on PV mode without PKU feature
enabled.
Signed-off-by: Huaitong Han
Reviewed-by: Andrew Cooper
---
Changes in
Changes in v8:
*Add the comment describing for paging_gva_to_gfn.
*Abstract out _write_cr4.
Changes in v7:
*Add static for pkey_fault.
*Add a comment for page present check and adjust indentation.
*Init pkru_ad and pkru_wd.
*Delete l3e_get_pkey the outer parentheses.
*The first parameter of read_p
This patch disables pkeys for guest in non-paging mode, However XEN always uses
paging mode to emulate guest non-paging mode, To emulate this behavior, pkeys
needs to be manually disabled when guest switches to non-paging mode.
Signed-off-by: Huaitong Han
Reviewed-by: Andrew Cooper
---
Changes i
This patch adds pkeys support for cpuid handing.
Pkeys hardware support is CPUID.7.0.ECX[3]:PKU. software support is
CPUID.7.0.ECX[4]:OSPKE and it reflects the support setting of CR4.PKE.
X86_FEATURE_OSXSAVE depends on guest X86_FEATURE_XSAVE, but cpu_has_xsave
function reflects hypervisor X86_FE
Protection keys define a new 4-bit protection key field(PKEY) in bits 62:59 of
leaf entries of the page tables.
PKRU register defines 32 bits, there are 16 domains and 2 attribute bits per
domain in pkru, for each i (0 ≤ i ≤ 15), PKRU[2i] is the access-disable bit for
protection key i (ADi); PKRU[
This patch use alternavtive asm on the xsave side.
As xsaves use modified optimization like xsaveopt, xsaves
may not writing the FPU portion of the save image too.
So xsaves also need some extra tweaks.
Signed-off-by: Shuai Ruan
---
xen/arch/x86/xstate.c | 49
This patch add alternative_io_2/3 to support alternative with 2/3 features.
Also use alternavitive asm on xsave side.
Shuai Ruan (2):
x86: add alternavive_io_2/3 to support alternative with 2/3 features.
x86/xsave: use alternative asm on xsave side.
xen/arch/x86/xstate.c | 49 +++
Most of the code is porting from linux with some changes.
alternative_io_2 replaces old instruction with new instructions
based on two features.
alternative_io_3 replaces old instruction with new instructions
based on three features.
Signed-off-by: Shuai Ruan
---
xen/include/asm-x86/alternative.
> From: Kay, Allen M
> Sent: Saturday, January 30, 2016 5:58 AM
>
> First of all, I would like to clarify I'm talking about general IGD
> passthrough case - not
> specific to KVMGT. In IGD passthrough configuration, one of the following
> will happen
> when the driver accesses OpRegion:
>
> 1)
> From: Gerd Hoffmann
> Sent: Monday, February 01, 2016 8:49 PM
>
> Hi,
>
> > Thanks for the tip that seabios allocated pages automatically become
> > e820 reserved, that simplifies things a bit.
>
> It's common practice for all firmware. The e820 table from qemu is just
> a starting point, i
Hi all:
In patch e1e40bccee7490a01ac7d1f759ec2bbafd3c7185, it says that"many routines
can logically assert holding the p2m *FOR A SPECIFIC GFN.*" ,
But I find out that it did nothing for locking a single gfn, in fact it still
locked the entire p2m list.
-#define p2m_lock_recursive(p) mm_lock_
flight 79778 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79778/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
build-amd64-rumpuserx
While npo.copy and npo.meta are initialized in xenvif_rx_action, fields
such as npo.meta_prod are directly used later in xenvif_gop_skb without
being initialized first. Although the output of xenvif_rx_action is based
on the difference between new npo->meta_prod and old npo->meta_prod, it is
better
> From: Kay, Allen M
> Sent: Tuesday, February 02, 2016 8:04 AM
> >
> > David notes in the latter commit above:
> >
> > "We should be able to successfully assign graphics devices to guests too, as
> > long as the initial handling of stolen memory is reconfigured
> > appropriately."
> >
> > What co
On Tue, Jan 26, 2016 at 08:12:20AM -0700, Jan Beulich wrote:
> >>> On 26.01.16 at 15:33, wrote:
> > originally I only meant to inquire about the state of the promised
> > alternatives improvement to the XSAVE code. However, while
> > looking over the code in question again I stumbled across a
> >
> From: Zhang, Haozhong
> Sent: Monday, February 01, 2016 1:44 PM
>
[...]
>
> 1.2 ACPI Support
>
> ACPI provides two factors of support for NVDIMM. First, NVDIMM
> devices are described by firmware (BIOS/EFI) to OS via ACPI-defined
> NVDIMM Firmware Interface Table (NFIT). Second, several fun
The following script caused an unresponsive dom0 and it can not be
reproduced all the time. The dom0 is using credit2 scheduler.
#!/bin/bash
xl cpupool-list -c
xl cpupool-cpu-remove Pool-0 3
xl cpupool-cpu-remove Pool-0 2
xl cpupool-create name=\"r\" sched=\"credit\"
xl cpupool-create name=\"t
Hi Paul,
On 01/12/2016 05:58 PM, Paul Durrant wrote:
> This series documents changes needed to support toeplitz hashing in a
> backend, configurable by the frontend.
>
> Patch #1 adds further clarifications to the receive and transmit wire
> formats.
>
> Patch #2 documents a new 'control ring' f
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, January 29, 2016 5:32 PM
> To: Wu, Feng
> Cc: Andrew Cooper ; Dario Faggioli
> ; George Dunlap ;
> Tian, Kevin ; xen-devel@lists.xen.org; Keir Fraser
>
> Subject: RE: [PATCH v11 1/2] vmx: VT-d posted-int
On Wed, Jan 20, 2016 at 03:06:09AM -0700, Jan Beulich wrote:
> >>> On 19.01.16 at 20:55, wrote:
Sorry for late response. I am away from the mail list for a couple
weeks.
> > I tried booting staging branch but results were identical. Following
> > line repeats endlessly.
> > (XEN) traps.c:3290: GP
Quoting Ian Campbell :
On Mon, 2016-01-25 at 11:59 +, Ian Campbell wrote:
On Sun, 2016-01-24 at 19:45 -0500, Chester Lin wrote:
> Coverity CID 1343309
>
> Make GC_FREE reachable in all cases in libxl_get_scheduler() by
> eliminating the error-path return and instead storing the error code i
Hi,all:
I met a problem when passthrough 82599 to domU(for some reasons, I use pci
passthrough not SRIOV).
It works well after passthrough, but the host hung after destroy domU.
Btw, no log prints even from serial port, but I found it hung afer unbind irq.
anyone knows what's wrong with it? thank
>>> On 1/27/2016 at 12:21 AM, in message
, George
Dunlap wrote:
> On Tue, Jan 26, 2016 at 7:43 AM, Chun Yan Liu wrote:
> >
> >
> On 1/20/2016 at 12:56 PM, in message
> > <569f83f502660009e...@relay2.provo.novell.com>, "Chun Yan Liu"
> > wrote:
> >
> >>
> > On 1/19/2016 at
On 02/01/16 18:25, Andrew Cooper wrote:
> On 01/02/16 05:44, Haozhong Zhang wrote:
> > Hi,
> >
> > The following document describes the design of adding vNVDIMM support
> > for Xen. Any comments are welcome.
> >
> > Thanks,
> > Haozhong
>
> Thankyou for doing this. It is a very comprehensive docu
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, February 02, 2016 2:25 AM
>
> On 01/02/16 05:44, Haozhong Zhang wrote:
> > Hi,
> >
> > The following document describes the design of adding vNVDIMM support
> > for Xen. Any comments are welcome.
> >
> > Thanks,
> > Haozhong
flight 79738 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79738/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 11 guest-start fail REGR. vs. 79587
test-armhf-armhf-libvi
flight 79772 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79772/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail
REGR. vs. 65543
test-amd64-i386-
On 01/20/2016 12:00 PM, Joao Martins wrote:
> . From libxlMigrationBegin to libxlDomainMigrateBegin3Params().
> This is a preparatory patch to be able to begin a job in the
> perform phase.
>
> Signed-off-by: Joao Martins
> ---
> src/libxl/libxl_driver.c| 18 +-
> src/libxl/li
On 01/20/2016 12:00 PM, Joao Martins wrote:
> Introduce support for VIR_MIGRATE_PEER2PEER in libvirt migration.
> Most of the changes occur at the source and no modifications
> at the receiver.
>
> In P2P mode there is only the Perform phase so we must handle
> the connection with the destination a
This run is configured for baseline tests only.
flight 38719 linux-3.14 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38719/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 6 xen-build
> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Sunday, January 31, 2016 9:42 AM
> To: Kay, Allen M; Gerd Hoffmann; David Woodhouse
> Cc: igv...@ml01.01.org; xen-de...@lists.xensource.com; Eduardo Habkost;
> Stefano Stabellini; qemu-de...@nongnu.or
On Mon, Feb 1, 2016 at 11:58 AM, Boris Ostrovsky wrote:
> On 02/01/2016 02:27 PM, PGNet Dev wrote:
>
>> On 02/01/2016 11:14 AM, Boris Ostrovsky wrote:
>>
>>> Is 'HVMLite' replacing 'PVH'? Or are they separate modes?
>>>
>>> Yes, HVMlite is replacing PVH. Probably once we get dom0 support.
>>
flight 79698 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79698/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 78986
build-i386-rumpuserxen
On Mon, 2016-02-01 at 13:49 +0100, Gerd Hoffmann wrote:
> > > Maybe we should define the interface as "guest writes 0xfc to pick
> > > address, qemu takes care to place opregion there". That gives us the
> > > freedom to change the qemu implementation (either copy host opregion or
> > > map the ho
On Mon, Feb 01, 2016 at 10:00:59AM -0800, Andy Lutomirski wrote:
> Signed-off-by: Andy Lutomirski
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Sun, Jan 31, 2016 at 10:09:07PM +0200, Michael S. Tsirkin wrote:
> On Fri, Jan 29, 2016 at 10:34:59AM +, David Vrabel wrote:
> > On 29/01/16 02:31, Andy Lutomirski wrote:
> > > Signed-off-by: Andy Lutomirski
> > > ---
> > > drivers/virtio/virtio_ring.c | 12
> > > 1 file chang
On Mon, Feb 01, 2016 at 10:04:07AM -0800, Andy Lutomirski wrote:
> On Mon, Feb 1, 2016 at 3:00 AM, Wei Liu wrote:
> > Nice work, Andy.
> >
> > On Thu, Jan 28, 2016 at 06:31:13PM -0800, Andy Lutomirski wrote:
> >> This switches virtio to use the DMA API on Xen and if requested by
> >> module option
This run is configured for baseline tests only.
flight 38720 linux-3.10 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38720/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-qemut-rhel6hvm-intel 3 host-install(3) bro
On 02/01/2016 02:27 PM, PGNet Dev wrote:
On 02/01/2016 11:14 AM, Boris Ostrovsky wrote:
Is 'HVMLite' replacing 'PVH'? Or are they separate modes?
Yes, HVMlite is replacing PVH. Probably once we get dom0 support.
If that's a 'done deal', and it sounds like it is, it'd be useful to
have it in
On 02/01/2016 11:14 AM, Boris Ostrovsky wrote:
Is 'HVMLite' replacing 'PVH'? Or are they separate modes?
Yes, HVMlite is replacing PVH. Probably once we get dom0 support.
If that's a 'done deal', and it sounds like it is, it'd be useful to
have it integrated into:
http://wiki.xen.org/wik
flight 79622 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79622/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 5 xen-build fail REGR. vs. 79422
build-i386
On 02/01/2016 11:56 AM, Jan Beulich wrote:
On 01.02.16 at 15:54, wrote:
This looks very much like it needs backport of 33c19df9a ("x86/PCI:
intercept accesses to RO MMIO from dom0s in HVM containers") from
unstable, which fixes PVH regression introduced by 9256f66c1606
("x86/PCI: intercept all
On 02/01/2016 10:49 AM, PGNet Dev wrote:
On 02/01/2016 06:11 AM, Boris Ostrovsky wrote:
This actually never happened for Linux: HVMlite showed up fast enough
that it didn't make sense anymore to add 32-bit support to Linux
(especially given that AMD was still not supported).
Is 'HVMLite' repla
On 01/02/16 05:44, Haozhong Zhang wrote:
> Hi,
>
> The following document describes the design of adding vNVDIMM support
> for Xen. Any comments are welcome.
>
> Thanks,
> Haozhong
Thankyou for doing this. It is a very comprehensive document, and a
fantastic example for future similar situations.
This switches to vring_create_virtqueue, simplifying the driver and
adding DMA API support.
This fixes virtio-pci on platforms and busses that have IOMMUs. This
will break the experimental QEMU Q35 IOMMU support until QEMU is
fixed. In exchange, it fixes physical virtio hardware as well as
virti
virtio_ring currently sends the device (usually a hypervisor)
physical addresses of its I/O buffers. This is okay when DMA
addresses and physical addresses are the same thing, but this isn't
always the case. For example, this never works on Xen guests, and
it is likely to fail if a physical "virt
On Mon, Feb 1, 2016 at 3:00 AM, Wei Liu wrote:
> Nice work, Andy.
>
> On Thu, Jan 28, 2016 at 06:31:13PM -0800, Andy Lutomirski wrote:
>> This switches virtio to use the DMA API on Xen and if requested by
>> module option.
>>
>> This fixes virtio on Xen, and it should break anything because it's
>
On 01/02/16 18:00, Andy Lutomirski wrote:
> Signed-off-by: Andy Lutomirski
Reviewed-by: David Vrabel
Thanks.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
From: Christian Borntraeger
We are going to require dma_ops for several common drivers, even for
systems that do have an identity mapping. Lets provide some minimal
no-op dma_ops that can be used for that purpose.
Signed-off-by: Christian Borntraeger
Reviewed-by: Joerg Roedel
---
include/linu
This switches virtio to use the DMA API on Xen and if requested by
module option.
This fixes virtio on Xen, and it should break anything because it's
off by default on everything except Xen PV on x86.
To the Xen people: is this okay? If it doesn't work on other Xen
variants (PVH? HVM?), can you
From: Christian Borntraeger
As virtio-ccw will have dma ops, we can no longer default to the
zPCI ones. Make use of dev_archdata to keep the dma_ops per device.
The pci devices now use that to override the default, and the
default is changed to use the noop ops for everything that does not
specif
This switches to vring_create_virtqueue, simplifying the driver and
adding DMA API support.
Signed-off-by: Andy Lutomirski
---
drivers/virtio/virtio_mmio.c | 67 ++--
1 file changed, 15 insertions(+), 52 deletions(-)
diff --git a/drivers/virtio/virtio_mmi
This leaves vring_new_virtqueue alone for compatbility, but it
adds two new improved APIs:
vring_create_virtqueue: Creates a virtqueue backed by automatically
allocated coherent memory. (Some day it this could be extended to
support non-coherent memory, too, if there ends up being a platform
on w
Signed-off-by: Andy Lutomirski
---
drivers/virtio/virtio_ring.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index cf2840c7e500..2a921e5b1809 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring
This is a kludge, but no one has come up with a a better idea yet.
We'll introduce DMA API support guarded by vring_use_dma_api().
Eventually we may be able to return true on more and more systems,
and hopefully we can get rid of vring_use_dma_api() entirely some
day.
Signed-off-by: Andy Lutomirsk
From: Christian Borntraeger
Some of the alpha pci noop dma ops are identical to the common ones.
Use them.
Signed-off-by: Christian Borntraeger
Reviewed-by: Joerg Roedel
---
arch/alpha/kernel/pci-noop.c | 46
1 file changed, 4 insertions(+), 42 del
c/s 428607a "x86: shrink 'struct domain', was already PAGE_SIZE" introduced a
use-after-free error during domain destruction, because of the order in which
timers are torn down.
(XEN) Xen call trace:
(XEN)[] spinlock.c#check_lock+0x1e/0x40
(XEN)[] _spin_lock+0x11/0x52
(XEN)[] v
flight 79642 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79642/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 66399
build-amd64
On 01/02/16 17:09, David Vrabel wrote:
> Since the NMI handler can now recognize watchdog NMIs, make
> check_nmi_watchdog() only check for at least two watchdog NMIs. This
> prevents false negatives caused by other processors (which may be
> being power managed by the BIOS) running at reduced cloc
On 01/02/16 16:51, Jan Beulich wrote:
On 01.02.16 at 17:34, wrote:
>> On 01/02/16 16:28, Jan Beulich wrote:
>> On 01.02.16 at 15:07, wrote:
On 01/02/16 13:20, Jan Beulich wrote:
> Ping? (I'd really like to get this resolved, so we don't need to
> indefinitely run with non-up
flight 79697 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79697/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
build-amd6
Since the NMI handler can now recognize watchdog NMIs, make
check_nmi_watchdog() only check for at least two watchdog NMIs. This
prevents false negatives caused by other processors (which may be
being power managed by the BIOS) running at reduced clock frequencies.
We check for more than one NMI
Yu, Zhang writes ("Re: [Xen-devel] [PATCH v3 3/3] tools: introduce parameter
max_wp_ram_ranges."):
> On 2/2/2016 12:35 AM, Jan Beulich wrote:
>> On 01.02.16 at 17:19, wrote:
> >> So, we need also validate this param in hvm_allow_set_param,
> >> current although hvm_allow_set_param has not perform
>>> On 01.02.16 at 17:58, wrote:
> Jan Beulich writes ("Re: [PATCH v2 1/2] altp2m: Merge
> p2m_set_altp2m_mem_access and p2m_set_mem_access"):
>> On 01.02.16 at 16:22, wrote:
>> > It's not like we're short of memory op values.
>>
>> Are we not? They need to fit in 6 bits (unless we want to play
Jan Beulich writes ("Re: [PATCH v2 1/2] altp2m: Merge p2m_set_altp2m_mem_access
and p2m_set_mem_access"):
> On 01.02.16 at 16:22, wrote:
> > It's not like we're short of memory op values.
>
> Are we not? They need to fit in 6 bits (unless we want to play tricks),
> and numbers up to 27 are alrea
>>> On 01.02.16 at 15:54, wrote:
> On 02/01/2016 08:38 AM, PGNet Dev wrote:
>>
>> Loading Xen 4.6.0_08-405 with Linux 4.4.0-8.g9f68b90-default
>> ...Loading Xen 4.6.0_08-405 with Linux 4.4.0-8.g9f68b90-default ...
>>
>> /EndEntire
>> /EndEntire
>> file path: file path:
>>
> /ACPI(a0341d0,0)/ACP
Ian Campbell writes ("Re: [PATCH OSSTEST v1 5/5] mg-show-flight-runvars:
recurse on buildjobs upon request"):
> ITIYM:
>
> foreach my $row (map { $_->[1] }
> sort { $a->[0] cmp $b->[0] }
> map { $xform->($_) }
> @rows) {
> ...
>>> On 01.02.16 at 17:34, wrote:
> On 01/02/16 16:28, Jan Beulich wrote:
> On 01.02.16 at 15:07, wrote:
>>> On 01/02/16 13:20, Jan Beulich wrote:
Ping? (I'd really like to get this resolved, so we don't need to
indefinitely run with non-upstream behavior in our distros.)
>>> My rema
>>> On 01.02.16 at 17:35, wrote:
> On Mon, Feb 1, 2016 at 9:30 AM, Ian Campbell
> wrote:
>
>> On Mon, 2016-02-01 at 09:21 -0700, Jan Beulich wrote:
>> > > > > On 01.02.16 at 15:45, wrote:
>> > > On Fri, 2016-01-29 at 09:47 -0700, Jan Beulich wrote:
>> > > > > > > On 29.01.16 at 17:32, wrote:
>
>>> On 01.02.16 at 16:22, wrote:
> Ian Campbell writes ("Re: [PATCH v2 1/2] altp2m: Merge
> p2m_set_altp2m_mem_access and p2m_set_mem_access"):
>> It's unfortunate that we've found ourselves here, but I think rather than
>> deprecating the current and adding a new op alongside we should just acce
>>> On 01.02.16 at 17:30, wrote:
> On Mon, 2016-02-01 at 09:21 -0700, Jan Beulich wrote:
>> > > > On 01.02.16 at 15:45, wrote:
>> > On Fri, 2016-01-29 at 09:47 -0700, Jan Beulich wrote:
>> > > > > > On 29.01.16 at 17:32, wrote:
>> > > > On Fri, Jan 29, 2016 at 9:19 AM, Jan Beulich
>> > > > wrot
On 2/2/2016 12:35 AM, Jan Beulich wrote:
On 01.02.16 at 17:19, wrote:
After a second thought, I guess one of the security concern
is when some APP is trying to trigger the HVMOP_set_param
directly with some illegal values.
Not sure what "directly" is supposed to mean here.
I mean with no
On Mon, Feb 1, 2016 at 9:21 AM, Jan Beulich wrote:
> >>> On 01.02.16 at 15:45, wrote:
> > On Fri, 2016-01-29 at 09:47 -0700, Jan Beulich wrote:
> >> > > > On 29.01.16 at 17:32, wrote:
> >> > On Fri, Jan 29, 2016 at 9:19 AM, Jan Beulich
> wrote:
> >> > > > > > On 29.01.16 at 17:12, wrote:
> >>
On 2/1/2016 11:14 PM, Yu, Zhang wrote:
On 2/1/2016 9:07 PM, Jan Beulich wrote:
On 01.02.16 at 13:49, wrote:
On Mon, Feb 01, 2016 at 05:15:16AM -0700, Jan Beulich wrote:
On 01.02.16 at 13:02, wrote:
On Mon, Feb 01, 2016 at 12:52:51AM -0700, Jan Beulich wrote:
On 30.01.16 at 15:38, wrot
On Mon, Feb 1, 2016 at 9:30 AM, Ian Campbell
wrote:
> On Mon, 2016-02-01 at 09:21 -0700, Jan Beulich wrote:
> > > > > On 01.02.16 at 15:45, wrote:
> > > On Fri, 2016-01-29 at 09:47 -0700, Jan Beulich wrote:
> > > > > > > On 29.01.16 at 17:32, wrote:
> > > > > On Fri, Jan 29, 2016 at 9:19 AM, Ja
>>> On 01.02.16 at 17:19, wrote:
> After a second thought, I guess one of the security concern
> is when some APP is trying to trigger the HVMOP_set_param
> directly with some illegal values.
Not sure what "directly" is supposed to mean here.
> So, we need also validate this param in hvm_allow_s
On 2/2/2016 12:16 AM, Jan Beulich wrote:
On 01.02.16 at 16:14, wrote:
But I still do not quite understand. :)
If tool stack can guarantee the validity of a parameter,
under which circumstances will hypervisor be threatened?
At least in disaggregated environments the hypervisor cannot
trust
On 01/02/16 16:28, Jan Beulich wrote:
On 01.02.16 at 15:07, wrote:
>> On 01/02/16 13:20, Jan Beulich wrote:
>>> Ping? (I'd really like to get this resolved, so we don't need to
>>> indefinitely run with non-upstream behavior in our distros.)
>> My remaining issue is whether this loop gets exe
On Mon, 2016-02-01 at 09:21 -0700, Jan Beulich wrote:
> > > > On 01.02.16 at 15:45, wrote:
> > On Fri, 2016-01-29 at 09:47 -0700, Jan Beulich wrote:
> > > > > > On 29.01.16 at 17:32, wrote:
> > > > On Fri, Jan 29, 2016 at 9:19 AM, Jan Beulich
> > > > wrote:
> > > > > > > > On 29.01.16 at 17:12,
> Once vm_event.c is added to ARM:
>
> I don't think that's a prerequisite for accepting this patch, is it? (In
> some ways that's the point -- it covers all future ARCH vm_event.c)
>
Oh yea, good point. I just found it odd to list files here that don't (yet)
exist.
Tamas
>>> On 01.02.16 at 15:07, wrote:
> On 01/02/16 13:20, Jan Beulich wrote:
>> Ping? (I'd really like to get this resolved, so we don't need to
>> indefinitely run with non-upstream behavior in our distros.)
>
> My remaining issue is whether this loop gets executed by default.
>
> I realise that th
Holding the p2m lock while calling ept_sync_domain() is very expensive
since it does a on_selected_cpus() call. IPIs on many socket machines
can be very slows and on_selected_cpus() is serialized.
It is safe to defer the invalidate until the p2m lock is released
except for two cases:
1. When fre
This series improves the performance of EPT by further reducing the
impact of the translation invalidations (ept_sync_domain()). By:
a) Deferring invalidations until the p2m write lock is released.
Prior to this change a 16 VCPU guest could not be successfully
migrated on an (admittedly slow) 160
>>> On 01.02.16 at 15:45, wrote:
> On Fri, 2016-01-29 at 09:47 -0700, Jan Beulich wrote:
>> > > > On 29.01.16 at 17:32, wrote:
>> > On Fri, Jan 29, 2016 at 9:19 AM, Jan Beulich wrote:
>> > > > > > On 29.01.16 at 17:12, wrote:
>> > > > On Fri, Jan 29, 2016 at 4:03 AM, Jan Beulich
>> > > > wrote
>>> On 01.02.16 at 16:14, wrote:
> But I still do not quite understand. :)
> If tool stack can guarantee the validity of a parameter,
> under which circumstances will hypervisor be threatened?
At least in disaggregated environments the hypervisor cannot
trust the (parts of the) tool stack(s) livi
On Mon, 2016-02-01 at 15:19 +, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST v1 5/5] mg-show-flight-runvars:
> recurse on buildjobs upon request"):
> > By looping over @rows looking for buildjobs runvars and adding those
> > jobs to the output until nothing changes.
> ...
> > Note t
flight 79786 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/79786/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
On Mon, 2016-02-01 at 07:39 -0800, Andy Lutomirski wrote:
>
> >> Could we have an arch_vring_eschew_dma_api(dev) function which the
> >> affected architectures could provide (as a prelude to fixing it so that
> >> the DMA API does the right thing for *itself*)?
> >
> > I'm fine with this.
>
> I m
On 22/12/15 12:23, George Dunlap wrote:
> On 18/12/15 13:50, David Vrabel wrote:
>> Holding the p2m lock while calling ept_sync_domain() is very expensive
>> since it does a on_selected_cpus() call. IPIs on many socket machines
>> can be very slows and on_selected_cpus() is serialized.
>>
>> It is
On 02/01/2016 06:11 AM, Boris Ostrovsky wrote:
This actually never happened for Linux: HVMlite showed up fast enough
that it didn't make sense anymore to add 32-bit support to Linux
(especially given that AMD was still not supported).
Is 'HVMLite' replacing 'PVH'? Or are they separate modes?
_
1 - 100 of 233 matches
Mail list logo
