>>> On 23.01.17 at 20:42, wrote:
> Whilst testing other patches today, I have noticed that some part of the
> resources allocated to a guest were not released during the destruction.
>
> The configuration of the test is:
> - ARM platform with 6 cores
> - staging Xen with credit2 enab
flight 104617 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104617/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 104579
test-armhf-armhf-libvirt 13
>>> On 23.01.17 at 19:20, wrote:
> In preparation for auxiliary RMRR data provided on Xen command line,
> make RMRR adding a separate function.
> Also free memery for rmrr device scope in error path.
>
> Signed-off-by: Elena Ufimtseva
> Signed-off-by: Venu Busireddy
> Acked-by: Kevin Tian
Rev
>>> On 23.01.17 at 19:20, wrote:
> +overlap = false;
> +list_for_each_entry(rmrru, &acpi_rmrr_units, list)
> +{
> +if ( pfn_to_paddr(base) <= rmrru->end_address &&
> + rmrru->base_address <= pfn_to_paddr(end) )
So this now looks correct as long
Commit 366ff5f1b3 ("x86: segment attribute handling adjustments" went a
little too far: We must not do such adjustments for non-present segments.
Reported-by: Roger Pau Monné
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1374,8 +1374,10 @@ int arch_set_i
On 24/01/2017 08:56, Jan Beulich wrote:
> Commit 366ff5f1b3 ("x86: segment attribute handling adjustments" went a
> little too far: We must not do such adjustments for non-present segments.
>
> Reported-by: Roger Pau Monné
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
flight 104614 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104614/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-rumprun-i386 16 rumprun-demo-xenstorels/xenstorels.repeat fail
pass in 104599
Regressions whic
>>> On 21.01.17 at 00:51, wrote:
> Commit 6e03363 ("x86: Implement TSC adjust feature for HVM guest")
> implemented TSC_ADJUST MSR for hvm guests. Though while booting
> an HVM guest the boot CPU would have a value set with delta_tsc -
> guest tsc while secondary CPUS would have 0. For example one
Other than hvm_set_guest_tsc(), neither needs to be exposed. And
hvm_get_guest_tsc_adjust() is pretty pointless as a seperate function
altogether, let alone a non-static one.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -369,7 +369,7 @@ u64 hvm_scale_ts
>>> On 23.01.17 at 14:59, wrote:
> +static bool copy_buf_from_guest(xen_dm_op_buf_t bufs[],
> +unsigned int nr_bufs, void *dst,
> +unsigned int idx, size_t dst_size)
> +{
> +if ( dst_size != bufs[idx].size )
> +return fals
>>> On 20.01.17 at 13:11, wrote:
> @@ -33,7 +35,10 @@ distclean: clean
>
> .PHONY: clean
> clean:
> - rm -f *.a *.o
> + rm -f *.a *.o afl-x86-insn-emulator-fuzzer
Perhaps *-x86-insn-emulator-fuzzer right away?
> --- /dev/null
> +++ b/tools/fuzz/x86_instruction_emulator/afl-x86-insn-e
>>> On 20.01.17 at 13:11, wrote:
> And hook it up into build system.
Same comments and same conditional R-b as for the other patch.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
flight 104618 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104618/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6a12538657f885ac9249dfb942d16ec89df2244a
baseline version:
ovmf 6671cd7444bc6c00ffe98
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 24 January 2017 10:00
> To: Paul Durrant
> Cc: Ian Jackson ; Jennifer Herbert
> ; xen-de...@lists.xenproject.org
> Subject: Re: [PATCH v7 1/8] public / x86: Introduce __HYPERCALL_dm_op...
>
> >>> On 23.01.17 at 14
flight 104616 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104616/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 12 guest-saverestore fail REGR.
vs. 59254
build-arm
On 24/01/17 09:33, Jan Beulich wrote:
> Other than hvm_set_guest_tsc(), neither needs to be exposed. And
> hvm_get_guest_tsc_adjust() is pretty pointless as a seperate function
> altogether, let alone a non-static one.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
__
Hi Jan,
On 24/01/2017 08:20, Jan Beulich wrote:
On 23.01.17 at 20:42, wrote:
Whilst testing other patches today, I have noticed that some part of the
resources allocated to a guest were not released during the destruction.
The configuration of the test is:
- ARM platform with 6 cores
On Tue, Jan 24, 2017 at 01:56:34AM -0700, Jan Beulich wrote:
> Commit 366ff5f1b3 ("x86: segment attribute handling adjustments" went a
> little too far: We must not do such adjustments for non-present segments.
>
> Reported-by: Roger Pau Monné
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau
On Mon, Jan 23, 2017 at 08:12:19AM -0700, Jan Beulich wrote:
> Don't truncate the "feature-persistent" value read from xenstore: Any
> non-zero value is supposed to enable the feature, just like is already
> being done for feature_secdiscard.
>
> Just like the other feature_* fields, feature_flush
>>> On 24.01.17 at 11:19, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 24 January 2017 10:00
>> >>> On 23.01.17 at 14:59, wrote:
>> > +static bool copy_buf_from_guest(xen_dm_op_buf_t bufs[],
>> > +unsigned int nr_bufs, void *dst,
>> > +
>>> On 24.01.17 at 11:50, wrote:
> On Tue, Jan 24, 2017 at 01:56:34AM -0700, Jan Beulich wrote:
>> Commit 366ff5f1b3 ("x86: segment attribute handling adjustments" went a
>> little too far: We must not do such adjustments for non-present segments.
>>
>> Reported-by: Roger Pau Monné
>> Signed-off
>>> On 24.01.17 at 11:50, wrote:
> On 24/01/2017 08:20, Jan Beulich wrote:
> On 23.01.17 at 20:42, wrote:
>>> Whilst testing other patches today, I have noticed that some part of the
>>> resources allocated to a guest were not released during the destruction.
>>>
>>> The configuration of the
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 24 January 2017 10:55
> To: Paul Durrant
> Cc: Ian Jackson ; Jennifer Herbert
> ; xen-de...@lists.xenproject.org
> Subject: RE: [PATCH v7 1/8] public / x86: Introduce __HYPERCALL_dm_op...
>
> >>> On 24.01.17 at 11
>>> On 23.01.17 at 15:39, wrote:
> Self-snoop describes a property of the CPU cache behaviour, which FreeBSD uses
> to optimise its cache flushing algorithm.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-
This run is configured for baseline tests only.
flight 68426 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68426/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-armhf-xsm 3 host-install(3) b
On Mon, Jan 23, 2017 at 08:11:37AM -0700, Jan Beulich wrote:
> Making use of "max_indirect_segments=" has issues:
> - blkfront_setup_indirect() may end up with zero psegs when PAGE_SIZE
> is sufficiently much larger than XEN_PAGE_SIZE
> - the variable driven by the command line option
> (xen_bl
On Tue, Jan 24, 2017 at 03:57:17AM -0700, Jan Beulich wrote:
> >>> On 24.01.17 at 11:50, wrote:
> > On Tue, Jan 24, 2017 at 01:56:34AM -0700, Jan Beulich wrote:
> >> Commit 366ff5f1b3 ("x86: segment attribute handling adjustments" went a
> >> little too far: We must not do such adjustments for non
Commit 6e03363 ("x86: Implement TSC adjust feature for HVM guest")
implemented TSC_ADJUST MSR for hvm guests. Though while booting
an HVM guest the boot CPU would have a value set with delta_tsc -
guest tsc while secondary CPUS would have 0. For example one can
observe:
$ xen-hvmctx 17 | grep tsc_
>>> On 23.01.17 at 15:39, wrote:
> @@ -153,21 +158,31 @@ static void recalculate_xstate(struct cpuid_policy *p)
>
> /*
> * Misc adjustments to the policy. Mostly clobbering reserved fields and
> - * duplicating shared fields.
> + * duplicating shared fields. Intentionally hidden fields are
The current code is poorly structured and potentially leads to multiple
config space reads when one is sufficient. Also the UNPLUG_ALL_IDE_DISKS
flag is mis-named since it also results in SCSI disks being unplugged.
This patch renames the flag and re-structures the code to be more
efficient, and r
...not just IDE and SCSI.
This patch allows the Xen tool-stack to fully support of NVMe as an
emulated disk type.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
---
hw/i386/xen/
These patches modify the implementation of Xen HVM disk unplug.
Paul Durrant (3):
xen-platform: re-structure unplug_disks
xen-platform: add support for unplugging NVMe disks...
xen-platform: add missing disk unplug option
hw/i386/xen/xen_platform.c | 50 +++-
The Xen HVM unplug protocol [1] specifies a mechanism to allow guests to
request unplug of 'aux' disks (which is stated to mean all IDE disks,
except the primary master). This patch adds support for that unplug request.
NOTE: The semantics of what happens if unplug of all disks and 'aux' disks
On Mon, Jan 23, 2017 at 02:39:04PM +, Andrew Cooper wrote:
> Self-snoop describes a property of the CPU cache behaviour, which FreeBSD uses
> to optimise its cache flushing algorithm.
>
> Signed-off-by: Andrew Cooper
Tested-by: Roger Pau Monné
Thanks, Roger.
__
Jan Beulich writes ("Re: [Xen-devel] RFC: Adding a section to the Xen security
policy about what constitutes a vulnerability"):
> "If a bug requires a vulnerable operating system to be exploitable, the
> Xen Security Team will pro-actively investigate the vulnerability of
> the following open-so
Ian Jackson writes ("[PATCH 0/2] ocaml: Start on fixing brokenness when no
ocamlopt"):
> Debian jessie arm64 has Ocaml (in the package `ocaml-nox') but the
> package lacks ocamlopt.
...
> This does not actually fix the real problem. I'm unsure how to fix it
> properly, for the following reasons:
On 24/01/17 11:20, Jan Beulich wrote:
On 23.01.17 at 15:39, wrote:
>> @@ -153,21 +158,31 @@ static void recalculate_xstate(struct cpuid_policy *p)
>>
>> /*
>> * Misc adjustments to the policy. Mostly clobbering reserved fields and
>> - * duplicating shared fields.
>> + * duplicating sha
>>> On 24.01.17 at 12:33, wrote:
> Jan Beulich writes ("Re: [Xen-devel] RFC: Adding a section to the Xen
> security
> policy about what constitutes a vulnerability"):
>> "If a bug requires a vulnerable operating system to be exploitable, the
>> Xen Security Team will pro-actively investigate th
>>> On 24.01.17 at 12:35, wrote:
> On 24/01/17 11:20, Jan Beulich wrote:
> On 23.01.17 at 15:39, wrote:
>>> @@ -153,21 +158,31 @@ static void recalculate_xstate(struct cpuid_policy *p)
>>>
>>> /*
>>> * Misc adjustments to the policy. Mostly clobbering reserved fields and
>>> - * duplica
>>> On 23.01.17 at 15:39, wrote:
> Intel reserve eax and ebx, while AMD duplicates eax from the low
> family/model/stepping leaf. For AMD, ebx contains further brand/package
> information which is left as the toolstack chooses (other than bits 27:16
> which are reserved).
>
> While moving the dy
>>> On 23.01.17 at 15:39, wrote:
> Intel reserves all of this information other than the L2 cache information,
> and the ITSC bit from the power management leaf.
>
> AMD passes all of the cache/TLB information through to the guest, while most
> of of the power management information is explicitly
Instead of using the default resolution of 800*600 for the pointing
device of xen-kbdfront try to read the resolution of the (virtual)
framebuffer device. Use the default as fallback only.
Cc: sta...@vger.kernel.org
Signed-off-by: Juergen Gross
---
drivers/input/misc/xen-kbdfront.c | 15
flight 104621 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104621/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
>>> On 23.01.17 at 15:39, wrote:
> Leaf 0x8009 is reserved.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 23.01.17 at 15:39, wrote:
> AMD uses 24 bits in eax, although nothing thus far has ever exposed a non-zero
> guest maxphysaddr to HVM guests.
I think exposing bits 16...23 should be limited to guests with nested
virt enabled, and should also be subject to bounds checking just
like is done
>>> On 23.01.17 at 15:39, wrote:
> Leaf 0x800a contains SVM information. The feature choices are borrowed
> straight from the libxc policy code.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@li
>>> On 23.01.17 at 15:39, wrote:
> Leaves 800b-18 are reserved. Leaf 8019 is 1G TLB information and leaf
> 0x801a is performance hints. These leaves have previously been hidden
> from guests, but are perfectly safe to expose.
I think 1G TLB info should be exposed only for guests see
Hi,
On 24/01/17 11:02, Jan Beulich wrote:
On 24.01.17 at 11:50, wrote:
On 24/01/2017 08:20, Jan Beulich wrote:
On 23.01.17 at 20:42, wrote:
Whilst testing other patches today, I have noticed that some part of the
resources allocated to a guest were not released during the destruction.
The
On 23/01/17 15:40, George Dunlap wrote:
> On Thu, Jan 19, 2017 at 8:08 AM, Juergen Gross wrote:
>> On 17/01/17 18:26, Dario Faggioli wrote:
>>> In fact, relying on the mask of what pCPUs belong to
>>> which Credit2 runqueue is not enough. If we only do that,
>>> when Credit2 is the boot scheduler,
Hi,
Your series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [PATCH 0/3] xen-platform: disk unplug modifications
Message-id: 1485257020-18542-1-git-send-email-paul.durr...@citrix.com
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BAS
flight 104620 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104620/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5734d486b6aa0b69a39b2c8d52b355400bcf2551
baseline version:
ovmf 6a12538657f885ac9249d
>>> On 23.01.17 at 15:39, wrote:
> Xen advertises the IBS feature flag to guests on capable AMD hardware.
> However, the PV path in Xen, and both the PV and HVM paths in libxc
> deliberately clobber the IBS CPUID leaf.
>
> Furthermore, Xen has nothing providing an implementation of the IBS MSRs,
On Tue, 2017-01-24 at 13:35 +0100, Juergen Gross wrote:
> On 23/01/17 15:40, George Dunlap wrote:
> >
> > Having a "cpupool-remove" operation that doesn't actually remove
> > the
> > cpu from the pool is a bit mad...
>
> Logically it does remove the cpu from Pool-0. It is just that there
> is
> n
Hi Stefano,
On 24/01/17 00:16, Stefano Stabellini wrote:
On Mon, 23 Jan 2017, Julien Grall wrote:
Hi all,
Before someone dig into the scheduler, I don't think this is an issue in
credit2 but the use of it highlight a bug in another component (I think RCU).
Whilst testing other patches today,
On Tue, 2017-01-24 at 10:50 +, Julien Grall wrote:
> On 24/01/2017 08:20, Jan Beulich wrote:
> > > > > On 23.01.17 at 20:42, wrote:
> > > The function domain_destroy will setup the RCU callback
> > > (complete_domain_destroy) by calling call_rcu. call_rcu will add
> > > the
> > > callback into
Hi all,
I was able to bring up Dom0 in lager board by steps followed by charles.
What could be the steps I could follow to bring up DomU in xen for lager
board.?..How to bring xen-utils in the filesystem(yocto build) of Dom0
linux for configuring DomU.
Regards,
George
Hi Dario,
On 24/01/17 12:53, Dario Faggioli wrote:
On Tue, 2017-01-24 at 10:50 +, Julien Grall wrote:
On 24/01/2017 08:20, Jan Beulich wrote:
On 23.01.17 at 20:42, wrote:
The function domain_destroy will setup the RCU callback
(complete_domain_destroy) by calling call_rcu. call_rcu will
On 24/01/17 13:04, Julien Grall wrote:
Hi Dario,
On 24/01/17 12:53, Dario Faggioli wrote:
On Tue, 2017-01-24 at 10:50 +, Julien Grall wrote:
On 24/01/2017 08:20, Jan Beulich wrote:
On 23.01.17 at 20:42, wrote:
The function domain_destroy will setup the RCU callback
(complete_domain_de
On Tue, 2017-01-24 at 13:04 +, Julien Grall wrote:
> On 24/01/17 12:53, Dario Faggioli wrote:
> > Do you have a script and/or some more info for letting me try to
> > reproduce it (e.g., you say some otf the vCPUs are pinned, which
> > one?
> > etc)?
>
> That was mentioned in my first e-mail :
This run is configured for baseline tests only.
flight 68427 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68427/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i3863 host-install(3) broken bas
On 24/01/17 13:19, Dario Faggioli wrote:
On Tue, 2017-01-24 at 13:04 +, Julien Grall wrote:
On 24/01/17 12:53, Dario Faggioli wrote:
Do you have a script and/or some more info for letting me try to
reproduce it (e.g., you say some otf the vCPUs are pinned, which
one?
etc)?
That was ment
On Fri, Jan 20, 2017 at 11:03:54AM -0600, Eric DeVolder wrote:
> Instead of the scripts having to poke at various fields we can
> provide that functionality via the -S parameter.
>
> Returns 0 if the payload is loaded. Can be used in combination
> with -l or -p to get the state of the proper kexec
On Tue, 2017-01-24 at 13:24 +, Julien Grall wrote:
> On 24/01/17 13:19, Dario Faggioli wrote:
> > How are Dom0 vCPUs pinned, exclusively (i.e., there are 2 pCPUs on
> > which _only_ Dom0 and _no_ DomU can run)?
>
> I have dom0_vcpu_pins on Xen command line option (so I guess only
> pinned?),
On 01/23/2017 01:59 PM, Boris Ostrovsky wrote:
> On 01/23/2017 05:09 AM, Juergen Gross wrote:
>> Handling of multiple concurrent Xenstore accesses through xenbus driver
>> either from the kernel or user land is rather lame today: xenbus is
>> capable to have one access active only at one point of t
Hi,
On 24/01/17 13:40, Dario Faggioli wrote:
On Tue, 2017-01-24 at 13:24 +, Julien Grall wrote:
On 24/01/17 13:19, Dario Faggioli wrote:
How are Dom0 vCPUs pinned, exclusively (i.e., there are 2 pCPUs on
which _only_ Dom0 and _no_ DomU can run)?
I have dom0_vcpu_pins on Xen command line
These patches modify the implementation of Xen HVM disk unplug.
Paul Durrant (3):
xen-platform: re-structure unplug_disks
xen-platform: add support for unplugging NVMe disks...
xen-platform: add missing disk unplug option
hw/i386/xen/xen_platform.c | 50 +++-
...not just IDE and SCSI.
This patch allows the Xen tool-stack to fully support of NVMe as an
emulated disk type.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: "Michael S. Tsirkin"
Cc: Paolo Bonzini
Cc: Richard Henderson
Cc: Eduardo Habkost
---
hw/i386/xen/
The current code is poorly structured and potentially leads to multiple
config space reads when one is sufficient. Also the UNPLUG_ALL_IDE_DISKS
flag is mis-named since it also results in SCSI disks being unplugged.
This patch renames the flag and re-structures the code to be more
efficient, and r
The Xen HVM unplug protocol [1] specifies a mechanism to allow guests to
request unplug of 'aux' disks (which is stated to mean all IDE disks,
except the primary master). This patch adds support for that unplug request.
NOTE: The semantics of what happens if unplug of all disks and 'aux' disks
On 01/24/2017 02:43 AM, Jan Beulich wrote:
On 23.01.17 at 19:36, wrote:
> I think this should be introduced in your DomU ACPI CPU hotplug series,
> and not
> set for Dom0 until we found a way to perform ACPI vCPU hotplug for Dom0
> also.
>
Right, although my underst
On Tue, 2017-01-24 at 13:49 +, Julien Grall wrote:
> On 24/01/17 13:40, Dario Faggioli wrote:
> > Ah, wow... And how --forgive my naiveness-- do you measure / check
> > that?
>
> I added a print in the interrupt path (gic_interrupt for ARM) to
> dump
> the interrupt number. This needs to be r
> Yes, the only remaining risk is some vendor using _SB.XEN0, and AFAICT there's
> no way to reserve anything in there (mostly because it's assumed that ACPI
> tables will be created by a single entity I guess).
>
> I think that the chance of this happening is 0%, and that there's no single
> syst
flight 104626 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104626/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 5 ker
Hi Stefano,
On 04/01/17 00:24, Stefano Stabellini wrote:
On Thu, 29 Dec 2016, Julien Grall wrote:
[...]
# Introduction
PCI passthrough allows to give control of physical PCI devices to guest. This
means that the guest will have full and direct access to the PCI device.
ARM is supporting on
On Wed, Jan 18, 2017 at 07:40:53PM +, Andrew Cooper wrote:
> The VT-x/SVM features are hidden from PV dom0 by the pv_featureset[] upper
> mask, but nothing thusfar has prevented the features being visible in
> HVM-based control domains (where there is no toolstack decision to hide the
> feature
Dear All,
Acutely I'm working to install the xenserver from source code but I'm still
stuck in the booting phase of the xen hypervisor I can't modify the grub of
the CENTOS the documentation is omit that in the xenproject website. Also
the dom0 installation is unclear for me.
I have followed follo
> On Jan 24, 2017, at 11:43 AM, Jan Beulich wrote:
>
On 24.01.17 at 12:33, wrote:
>> Jan Beulich writes ("Re: [Xen-devel] RFC: Adding a section to the Xen
>> security
>> policy about what constitutes a vulnerability"):
>>> "If a bug requires a vulnerable operating system to be exploitabl
... as they don't work as intended with -fPIC.
I did prefer them over *_end ones at the time because older gcc would
cause .L* symbols to be public, due to issuing .globl for all
referenced externals. And labels at the end of instructions collide
with the ones at the start of the next instruction,
On 24/01/17 11:59, Jan Beulich wrote:
On 23.01.17 at 15:39, wrote:
>> Intel reserves all of this information other than the L2 cache information,
>> and the ITSC bit from the power management leaf.
>>
>> AMD passes all of the cache/TLB information through to the guest, while most
>> of of the
>>> On 24.01.17 at 16:01, wrote:
>> On Jan 24, 2017, at 11:43 AM, Jan Beulich wrote:
>>
> On 24.01.17 at 12:33, wrote:
>>> Jan Beulich writes ("Re: [Xen-devel] RFC: Adding a section to the Xen
> security
>>> policy about what constitutes a vulnerability"):
"If a bug requires a vulne
On Tue, Jan 24, 2017 at 08:02:23AM -0700, Jan Beulich wrote:
> ... as they don't work as intended with -fPIC.
>
> I did prefer them over *_end ones at the time because older gcc would
> cause .L* symbols to be public, due to issuing .globl for all
> referenced externals. And labels at the end of i
>>> On 24.01.17 at 15:38, wrote:
> On Wed, Jan 18, 2017 at 07:40:53PM +, Andrew Cooper wrote:
>> The VT-x/SVM features are hidden from PV dom0 by the pv_featureset[] upper
>> mask, but nothing thusfar has prevented the features being visible in
>> HVM-based control domains (where there is no t
>>> On 24.01.17 at 15:48, wrote:
> On 24/01/17 11:59, Jan Beulich wrote:
> On 23.01.17 at 15:39, wrote:
>>> Intel reserves all of this information other than the L2 cache information,
>>> and the ITSC bit from the power management leaf.
>>>
>>> AMD passes all of the cache/TLB information thro
On 24/01/17 14:16, Dario Faggioli wrote:
On Tue, 2017-01-24 at 13:49 +, Julien Grall wrote:
On 24/01/17 13:40, Dario Faggioli wrote:
Ah, wow... And how --forgive my naiveness-- do you measure / check
that?
I added a print in the interrupt path (gic_interrupt for ARM) to
dump
the interru
On Tue, Jan 24, 2017 at 02:35:17PM +0100, Simon Horman wrote:
> On Fri, Jan 20, 2017 at 11:03:54AM -0600, Eric DeVolder wrote:
> > Instead of the scripts having to poke at various fields we can
> > provide that functionality via the -S parameter.
> >
> > Returns 0 if the payload is loaded. Can be
Hi
On Tue, Jan 24, 2017 at 09:45:46AM -0500, Zvclproject Zvclproject wrote:
> Dear All,
>
> Acutely I'm working to install the xenserver from source code but I'm still
> stuck in the booting phase of the xen hypervisor I can't modify the grub of
Note that XenServer != upstream Xen.
> the CENTOS
...as a set of hypercalls to be used by a device model.
As stated in the new docs/designs/dm_op.markdown:
"The aim of DMOP is to prevent a compromised device model from
compromising domains other then the one it is associated with. (And is
therefore likely already compromised)."
See that file fo
This patch removes the need for handling HVMOP restarts, so that
infrastructure is removed.
NOTE: This patch also modifies the type of the 'nr' argument of
xc_hvm_set_mem_type() from uint64_t to uint32_t. In practice the
value passed was always truncated to 32 bits.
Suggested-by: Jan
Following on from the design submitted by Jennifer Herbert to the list [1]
this series provides an implementation of __HYPERCALL_dm_op followed by
patches based on Jan Beulich's previous HVMCTL series [2] to convert
tools-only HVMOPs used by device models to DMOPs.
[1] https://lists.xenproject.org
This patch introduces code to handle DMOP continuations.
NOTE: This patch also modifies the type of the 'nr' argument of
xc_hvm_modified_memory() from uint64_t to uint32_t. In practice the
value passed was always truncated to 32 bits.
Suggested-by: Jan Beulich
Signed-off-by: Paul Dur
... HVMOP_set_pci_link_route
These HVMOPs were exposed to guests so their definitions need to be
preserved for compatibility. This patch therefore updates
__XEN_LATEST_INTERFACE_VERSION__ to 0x00040900 and makes the HVMOP
defintions conditional on __XEN_INTERFACE_VERSION__ less than that value.
N
Since injection works on a remote vCPU, and since there's no
enforcement of the subject vCPU being paused, there's a potential race
between the producing and consuming sides. Fix this by leveraging the
vector field as synchronization variable.
Signed-off-by: Jan Beulich
[re-based]
Signed-off-by:
The definitions of HVM_IOREQSRV_BUFIOREQ_* have to persist as they are
already in use by callers of the libxc interface.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
Acked-by: Wei Liu
Acked-by: Daniel De Graaf
Reviewed-by: Andrew Cooper
--
Cc: Ian Jackson
The handle type passed to the underlying shadow and hap functions is
changed for compatibility with the new hypercall buffer.
NOTE: This patch also modifies the type of the 'nr' parameter of
xc_hvm_track_dirty_vram() from uint64_t to uint32_t. In practice
the value passed was always tr
NOTE: This patch also modifies the types of the 'vector', 'type' and
'insn_len' arguments of xc_hvm_inject_trap() from uint32_t to
uint8_t. In practice the values passed were always truncated to
8 bits.
Suggested-by: Jan Beulich
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beul
On 24/01/17 12:16, Jan Beulich wrote:
On 23.01.17 at 15:39, wrote:
>> AMD uses 24 bits in eax, although nothing thus far has ever exposed a
>> non-zero
>> guest maxphysaddr to HVM guests.
> I think exposing bits 16...23 should be limited to guests with nested
> virt enabled, and should also
On 24/01/17 15:05, Jan Beulich wrote:
On 24.01.17 at 15:48, wrote:
>> On 24/01/17 11:59, Jan Beulich wrote:
>> On 23.01.17 at 15:39, wrote:
Intel reserves all of this information other than the L2 cache information,
and the ITSC bit from the power management leaf.
AMD
On Tue, Jan 24, 2017 at 01:46:44AM -0700, Jan Beulich wrote:
> >>> On 23.01.17 at 19:20, wrote:
> > +overlap = false;
> > +list_for_each_entry(rmrru, &acpi_rmrr_units, list)
> > +{
> > +if ( pfn_to_paddr(base) <= rmrru->end_address &&
> > + rmrru
On Tue, Jan 24, 2017 at 08:10:56AM -0700, Jan Beulich wrote:
> >>> On 24.01.17 at 15:38, wrote:
> > On Wed, Jan 18, 2017 at 07:40:53PM +, Andrew Cooper wrote:
> >> The VT-x/SVM features are hidden from PV dom0 by the pv_featureset[] upper
> >> mask, but nothing thusfar has prevented the featur
Hi
Please don't top-post and please don't send screenshot to mailing list
because it consumes a lot of bandwidth (every subscriber receives a
copy). ;-)
On Tue, Jan 24, 2017 at 10:38:57AM -0500, Zvclproject Zvclproject wrote:
> Hi Wei,
>
> I have compile xen hypervisor from source code following
1 - 100 of 234 matches
Mail list logo
