flight 81092 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/81092/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR.
vs. 80121
test-amd64-i386-l
On 02/04/2016 02:52 PM, Razvan Cojocaru wrote:
> On 02/04/2016 02:36 PM, Andrew Cooper wrote:
>> On 04/02/16 12:27, Razvan Cojocaru wrote:
>>> Currently, after receiving a vm_event reply requesting emulation,
>>> the actual emulation is triggered in p2m_mem_access_check(),
>>> which means that we'r
On Fri, 2016-02-05 at 14:20 -0700, Tamas K Lengyel wrote:
> When xc_map_foreign_batch got deprecated reinitializing vm_event on a domain
> where an event listener was previously active broke as it relied on the flag
> XEN_DOMCTL_PFINFO_XTAB to indicate that the magic page is not in the physmap.
> M
On Fri, 2016-02-05 at 17:48 -0800, Luis R. Rodriguez wrote:
> What's up folks? How can this process be made smoother, did I do
> something wrong, what can I do to help better?
When you first sent this series to Jan + me not copying the list you were
asked to send to the list _and_ to CC the approp
On 06/02/16 02:00, Dario Faggioli wrote:
> in schedulers' command handlers.
>
> No functional change intended.
>
> Signed-off-by: Dario Faggioli
Acked-by: George Dunlap
> ---
> Cc: Ian Jackson
> Cc: Ian Campbell
> Cc: Wei Liu
> Cc: George Dunlap
> ---
> tools/libxl/xl_cmdimpl.c | 27 ++
flight 38732 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38732/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-amd64-sid-netboot-pygrub 9 debian-di-install fail REGR. vs.
38718
test-a
On Sat, 6 Feb 2016, Rafael J. Wysocki wrote:
> On Fri, Feb 5, 2016 at 4:05 AM, Shannon Zhao wrote:
> > From: Shannon Zhao
> >
> > ACPI 6.0 introduces a new table STAO to list the devices which are used
> > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> > UART is used b
On Fri, Feb 05, 2016 at 06:10:33PM -0600, Chong Li wrote:
> I'll fix these coding style issues.
>
Thank you. :-)
[...]
> >> +num_vcpus = max_vcpuid + 1;
> >> +GCNEW_ARRAY(vcpus, num_vcpus);
> >> +if (sched_rtds_validate_params(gc, scinfo->vcpus[0].period,
> >> +
Hi,
I used to be able to boot a guest with 64MB, but now the minimum required
to boot it seams to be 85MB. It's a PV guest used and lauched by OpenStack
with there test suite. You can find the image at [1].
The guest failed to boot with this error message:
xc: error: panic: xc_dom_x86.c:147: coun
On Thu, 4 Feb 2016, Michael S. Tsirkin wrote:
> On Thu, Feb 04, 2016 at 05:05:46PM +, Stefano Stabellini wrote:
> > Hi Michael,
> >
> > do you have any comments on this?
>
> I dislike how it spreads xen specific stuff around,
> but I don't have a better idea at the moment, so
> I applied this
On Fri, 2016-02-05 at 23:27 -0500, Tianyang Chen wrote:
>
> On 2/5/2016 9:39 AM, Dario Faggioli wrote:
> > On Wed, 2016-02-03 at 21:23 -0500, Tianyang Chen wrote:
> > >
> I see. So I'm just curious what can cause spurious wakeup? Does it
> only
> happen to a running vcpu (currently on pcpu), and
Lorenzo,
On Fri, Feb 5, 2016 at 3:17 PM, Lorenzo Pieralisi
wrote:
> On Fri, Feb 05, 2016 at 02:05:37PM +0530, Jayachandran Chandrashekaran Nair
> wrote:
>
> [...]
>
>> pci_host_acpi.c is a generic implementation of these using a sysdata
>> pointing to acpi_pci_root_info, and using a pointer to t
On Fri, 5 Feb 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
> scan this to get the UEFI information.
>
> Signed-off-by: Shannon Zhao
> Acked-by: Rob Herring
Reviewed-by: Stefano Stabellini
> CC: Rob Herring
> --
On 05/02/16 16:12, Wei Liu wrote:
> On Fri, Feb 05, 2016 at 01:42:17PM +, Andrew Cooper wrote:
>> The type of the pointer to a bitmap is not interesting; it does not affect
>> the
>> representation of the block of bits being pointed to.
>>
>> Make the libxc functions consistent with those in X
On Fri, 5 Feb 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Add a new type of Xen map space for Dom0 to map device's MMIO region.
>
> Signed-off-by: Shannon Zhao
> ---
> include/xen/interface/memory.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/xen/interface/memory.h
On Fri, Feb 05, Olaf Hering wrote:
> +int xlu_vscsi_detach(XLU_Config *cfg, libxl_ctx *ctx, uint32_t domid, char
> *str)
> +{
> +if (vc->num_vscsidevs > 1) {
> +/* Remove single vscsidev connected to this vscsictrl */;
> +ctrl.devid = vc->d
flight 81132 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/81132/
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
On 08/02/16 12:18, Anthony PERARD wrote:
> Hi,
>
> I used to be able to boot a guest with 64MB, but now the minimum required
> to boot it seams to be 85MB. It's a PV guest used and lauched by OpenStack
> with there test suite. You can find the image at [1].
>
> The guest failed to boot with this
On Mon, Feb 08, 2016 at 12:50:43PM +0100, Juergen Gross wrote:
> On 08/02/16 12:18, Anthony PERARD wrote:
> > Hi,
> >
> > I used to be able to boot a guest with 64MB, but now the minimum required
> > to boot it seams to be 85MB. It's a PV guest used and lauched by OpenStack
> > with there test sui
On Fri, 5 Feb 2016, Andrew Cooper wrote:
> The current pci-front/back and Qemu-based methods have substantial
> architectural deficiencies, and are incredibly fragile to change. When
> was the last XSA to PCI Passthrough which didn't end up requiring
> further bugfixes to undo the collateral damag
On 05/02/16 18:24, Boris Ostrovsky wrote:
>
>
> On 02/05/2016 11:59 AM, Juergen Gross wrote:
>> On 05/02/16 16:50, Boris Ostrovsky wrote:
>>>
>>> On 02/05/2016 08:21 AM, Juergen Gross wrote:
When adding more than one LUN to a frontend a warning for a failed
assignment is issued in dom0
On 08/02/16 13:06, Anthony PERARD wrote:
> On Mon, Feb 08, 2016 at 12:50:43PM +0100, Juergen Gross wrote:
>> On 08/02/16 12:18, Anthony PERARD wrote:
>>> Hi,
>>>
>>> I used to be able to boot a guest with 64MB, but now the minimum required
>>> to boot it seams to be 85MB. It's a PV guest used and l
In fact, they look rather useless: they are never
referenced neither directly, nor via the sched_data
pointer, as a dynamic copy that overrides them is
allocated as the very first step of a scheduler's
initialization.
While there, take the chance to also reset the sched_data
pointer to NULL, upon
On 08/02/16 12:10, Stefano Stabellini wrote:
> On Fri, 5 Feb 2016, Andrew Cooper wrote:
>> The current pci-front/back and Qemu-based methods have substantial
>> architectural deficiencies, and are incredibly fragile to change. When
>> was the last XSA to PCI Passthrough which didn't end up requiri
On 06/02/16 21:38, Doug Goldstein wrote:
> Hi all,
>
> Given that pvgrub2 has been available for a while now and Ian did a good
> write up on the Xen blog of how to use it and a few downstream distros
> are starting to pick it up as the way to boot Xen images. Plus most
> downstreams switching exc
Currently xen_dma_map_page concludes that DMA to anything other than
the head page of a compound page must be foreign, since the PFN of the
page is that of the head.
Fix the check to instead consider the whole of a compound page to be
local if the PFN of the head passes the 1:1 check.
We can neve
On 05/02/16 07:37, Jan Beulich wrote:
> When intercepting (or emulating) L1 guest INVLPG, the nested P2M
> pointer may be (is?) NULL, and hence there's no point in calling
> p2m_flush(). In fact doing so would cause a dereference of that NULL
> pointer at least in the ASSERT() right at the beginnin
On 04/02/16 14:39, Juergen Gross wrote:
> On 04/02/16 02:53, Chun Yan Liu wrote:
>>
>>
> On 2/3/2016 at 10:33 PM, in message <56b20fcc.3010...@citrix.com>, George
>> Dunlap wrote:
>>> On 02/02/16 18:11, Ian Jackson wrote:
George Dunlap writes ("Re: [Xen-devel] [PATCH V13 3/5] libxl: add
On 2/8/16 7:26 AM, David Vrabel wrote:
> On 06/02/16 21:38, Doug Goldstein wrote:
>> Hi all,
>>
>> Given that pvgrub2 has been available for a while now and Ian did a good
>> write up on the Xen blog of how to use it and a few downstream distros
>> are starting to pick it up as the way to boot Xen
Commit 81a76e4b12961a9f54f5021809074196dfe6dbba ("libxc: rework of
domain builder's page table handler") introduced a regression with
checking the required memory size of the domain. The needed maximum pfn
of the initial kernel mapping was added to the currently last used pfn
resulting in doubling
When adding a new frontend to xen-scsiback don't decrement the number
of active frontends in case of no error. Doing so results in a failure
when trying to remove the xen-pvscsi nexus even if no domain is using
it.
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
Cc: sta...@vger.kernel.
Correct two issues in the Xen pvscsi backend.
Changes in V2:
- Patch 2: scsiback_del_translation_entry() returns error code instead of 1
(Boris Ostrovsky)
Juergen Gross (2):
xen/scsiback: correct frontend counting
xen/scsiback: avoid warnings when adding multiple LUNs to a domain
driver
When adding more than one LUN to a frontend a warning for a failed
assignment is issued in dom0 for each already existing LUN. Avoid this
warning by checking for a LUN already existing when existence is
allowed (scsiback_do_add_lun() called with try == 1).
As the LUN existence check is needed now
George Dunlap writes ("Re: [Xen-devel] [PATCH V13 3/5] libxl: add pvusb API"):
> There's a difference between "making it intelligent" and "not making it
> broken". :-) Given that users can potentially cause a number of these
> things to fail just by pressing Ctrl-C, we need to at least make sure
>
flight 81161 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/81161/
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. 59254
build-i386-rumpuserxe
On Fri, 2016-02-05 at 14:22 -0700, Tamas K Lengyel wrote:
> The altp2m subsystem in its current form duplicates much of the existing
> code present in p2m for setting mem_access permissions. In this patch we
> consolidate the two versions but keep the separate MEMOP and HVMOP
> interfaces.
>
> Sig
On Mon, Feb 08, 2016 at 03:23:52PM +0100, Juergen Gross wrote:
> Commit 81a76e4b12961a9f54f5021809074196dfe6dbba ("libxc: rework of
> domain builder's page table handler") introduced a regression with
> checking the required memory size of the domain. The needed maximum pfn
> of the initial kernel
On Sun, 2016-02-07 at 09:44 -0800, Suriyan Ramasami wrote:
> The Odroid-XU3/XU4 from hardkernel is an Exynos 5422 based board.
> Code from mcpm-exynos.c and mcpm-platsmp.c from the Linux kernel
> has been used to get all the 8 cores from the 2 clusters powered
> on.
> The Linux DTS for these odroid
On 02/06/2016 03:05 PM, Andy Lutomirski wrote:
Anyway, this is all ridiculous. I propose that rather than trying to
clean up paravirt_enabled, you just delete it. Here are its users:
static inline bool is_hypervisor_range(int idx)
{
/*
* 8000 - 87ff is res
On Fri, 2016-02-05 at 14:22 -0700, Tamas K Lengyel wrote:
> Extend the existing get_mem_access memop to allow querying permissions in
> altp2m views as well.
>
> Signed-off-by: Tamas K Lengyel
> Cc: Ian Jackson
> Cc: Stefano Stabellini
> Cc: Ian Campbell
> Cc: Wei Liu
> Cc: Razvan Cojocaru
>
On 02/06/2016 05:04 PM, Borislav Petkov wrote:
On Sat, Feb 06, 2016 at 12:05:32PM -0800, Andy Lutomirski wrote:
int __init microcode_init(void)
{
[...]
if (paravirt_enabled() || dis_ucode_ldr)
return -EINVAL;
This is also asking "are we the natively booted k
On 2/5/16 2:10 PM, Andy Lutomirski wrote:
> On Feb 4, 2016 7:11 PM, "Fengguang Wu" wrote:
>>
>> Hi Andy,
>>
>> CC more people on Xen testing -- in case OSStest already (or plans to)
>> cover such test case.
>>
>> On Tue, Feb 02, 2016 at 07:31:30PM -0800, Andy Lutomirski wrote:
>>> Hi all-
>>>
>>>
On Mon, 2016-02-08 at 10:21 +, George Dunlap wrote:
> On 06/02/16 02:00, Dario Faggioli wrote:
> > in schedulers' command handlers.
> >
> > No functional change intended.
> >
> > Signed-off-by: Dario Faggioli
>
> Acked-by: George Dunlap
acked + applied.
__
On 02/08/2016 09:30 AM, Juergen Gross wrote:
When adding more than one LUN to a frontend a warning for a failed
assignment is issued in dom0 for each already existing LUN. Avoid this
warning by checking for a LUN already existing when existence is
allowed (scsiback_do_add_lun() called with try
On Mon, 2016-02-08 at 09:39 +, Ian Campbell wrote:
> On Fri, 2016-02-05 at 14:20 -0700, Tamas K Lengyel wrote:
> > When xc_map_foreign_batch got deprecated reinitializing vm_event on a
> > domain
> > where an event listener was previously active broke as it relied on the
> > flag
> > XEN_DOMCTL
On Mon, 2016-02-08 at 15:20 +, Anthony PERARD wrote:
> On Mon, Feb 08, 2016 at 03:23:52PM +0100, Juergen Gross wrote:
> > Commit 81a76e4b12961a9f54f5021809074196dfe6dbba ("libxc: rework of
> > domain builder's page table handler") introduced a regression with
> > checking the required memory si
On Sat, 2016-02-06 at 13:13 +0200, Razvan Cojocaru wrote:
> On 02/05/2016 11:22 PM, Tamas K Lengyel wrote:
> > Only copy the VCPU_PAUSED flag to the response. Copy the entire
> > mem_access
> > struct which is useful and easily forgotten when also testing the
> > emulate
> > response flags. Turn of
On Mon, Feb 08, 2016 at 10:31:36AM -0500, Boris Ostrovsky wrote:
> This range is reserved for hypervisors but the only hypervisor that uses it
> is Xen PV (lguest doesn't run in 64-bit mode).
Yeah, this is mentioned in arch/x86/include/asm/page_64_types.h:
/*
* Set __PAGE_OFFSET to the most nega
On Mon, 8 Feb 2016, Ian Campbell wrote:
> Currently xen_dma_map_page concludes that DMA to anything other than
> the head page of a compound page must be foreign, since the PFN of the
> page is that of the head.
>
> Fix the check to instead consider the whole of a compound page to be
> local if th
On Mon, Feb 08, 2016 at 10:39:43AM -0500, Boris Ostrovsky wrote:
> It does. Very much IIRC, the problem was not caused by an access to MSR but
> rather some sort of address not being available somewhere.
See below.
> >- microcode application on Xen: we've had this before. The hypervisor
> >should
On Mon, 2016-02-08 at 15:46 +, Stefano Stabellini wrote:
> On Mon, 8 Feb 2016, Ian Campbell wrote:
> > Currently xen_dma_map_page concludes that DMA to anything other than
> > the head page of a compound page must be foreign, since the PFN of the
> > page is that of the head.
> >
> > Fix the c
Currently xen_dma_map_page concludes that DMA to anything other than
the head page of a compound page must be foreign, since the PFN of the
page is that of the head.
Fix the check to instead consider the whole of a compound page to be
local if the PFN of the head passes the 1:1 check.
We can neve
Convert the xenoprof x86 build time option to Kconfig.
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Doug Goldstein
---
xen/arch/x86/Makefile | 2 +-
xen/arch/x86/Rules.mk | 3 ---
xen/common/Kconfig| 13 +
xen/common/Makefile | 2 +-
4 files changed, 1
Allow Xenoprof to be fully disabled when toggling the option off.
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
CC: Aravind Gopalakrishnan
CC: Jun Nakajima
CC: Kevin Tian
Signed-off-by: Doug Goldstein
---
xen/arch/x86/Makefile
On 08/02/16 15:55, Borislav Petkov wrote:
> On Mon, Feb 08, 2016 at 10:39:43AM -0500, Boris Ostrovsky wrote:
>> It does. Very much IIRC, the problem was not caused by an access to MSR but
>> rather some sort of address not being available somewhere.
> See below.
>
>>> - microcode application on Xen
Ian Campbell writes ("[PATCH OSSTEST 5/5 v3] 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.
>
> The output is resorted by runvar name which is the desired default
> beh
On 02/08/2016 11:05 AM, Andrew Cooper wrote:
For compatibility with other virtualisation specs, Xen's cpuid leaves
shift depending on configuration.
Spec at
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/arch-x86/cpuid.h;h=d709340f18d089560b959835eabb7b6609542c7e;hb=HEAD
On 08/02/16 16:04, Doug Goldstein wrote:
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 6f404b4..fbb64a7 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -84,6 +84,19 @@ config LATE_HWDOM
>
> If unsure, say N.
>
> +# Adds support for Xenoprof
> +config X
Ian Campbell writes ("[PATCH OSSTEST v3 2/2] Add a weekly coverity flight"):
> This primarily consists of ts-coverity-{build,upload} and
> make-coverity-flight which constructs the sole job.
Acked-by: Ian Jackson
Thanks!
Ian.
___
Xen-devel mailing li
At 13:42 + on 05 Feb (1454679737), Andrew Cooper wrote:
> The type of the pointer to a bitmap is not interesting; it does not affect the
> representation of the block of bits being pointed to.
It does affect the alignment, though. Is this safe on ARM?
Tim.
__
On 02/08/2016 11:04 AM, Doug Goldstein wrote:
Allow Xenoprof to be fully disabled when toggling the option off.
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
CC: Aravind Gopalakrishnan
CC: Jun Nakajima
CC: Kevin Tian
Signed-off-by: Doug
On 08/02/16 16:04, Doug Goldstein wrote:
> diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c
> index 990e6f3..c7b5bd5 100644
> --- a/xen/arch/x86/cpu/vpmu_amd.c
> +++ b/xen/arch/x86/cpu/vpmu_amd.c
> @@ -22,6 +22,7 @@
> */
>
> #include
> +#include
> #include
> #include
On 08/02/16 16:12, Boris Ostrovsky wrote:
>
>
> On 02/08/2016 11:05 AM, Andrew Cooper wrote:
>>
>> For compatibility with other virtualisation specs, Xen's cpuid leaves
>> shift depending on configuration.
>>
>> Spec at
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/arch-x8
On 02/08/2016 11:26 AM, Andrew Cooper wrote:
On 08/02/16 16:12, Boris Ostrovsky wrote:
On 02/08/2016 11:05 AM, Andrew Cooper wrote:
For compatibility with other virtualisation specs, Xen's cpuid leaves
shift depending on configuration.
Spec at
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob
On 08/02/16 16:31, Boris Ostrovsky wrote:
>
>
> On 02/08/2016 11:26 AM, Andrew Cooper wrote:
>> On 08/02/16 16:12, Boris Ostrovsky wrote:
>>>
>>> On 02/08/2016 11:05 AM, Andrew Cooper wrote:
For compatibility with other virtualisation specs, Xen's cpuid leaves
shift depending on configura
On Mon, Feb 08, 2016 at 11:31:04AM -0500, Boris Ostrovsky wrote:
> I think we are OK for PV because this code will be executed after pvops are
> set and so we will be calling xen_cpuid().
Not for the early loader - it is too early for pvops then. So you're
saying something like that won't work?
-
On Mon, 2016-02-08 at 16:23 +, Tim Deegan wrote:
> At 13:42 + on 05 Feb (1454679737), Andrew Cooper wrote:
> > The type of the pointer to a bitmap is not interesting; it does not
> > affect the
> > representation of the block of bits being pointed to.
>
> It does affect the alignment, thou
On 08/02/16 16:35, Borislav Petkov wrote:
> On Mon, Feb 08, 2016 at 11:31:04AM -0500, Boris Ostrovsky wrote:
>> I think we are OK for PV because this code will be executed after pvops are
>> set and so we will be calling xen_cpuid().
> Not for the early loader - it is too early for pvops then. So y
On Mon, Feb 08, 2016 at 04:38:40PM +, Andrew Cooper wrote:
> Does the early loader have extable support? If so, this is fairly easy
> to fix. If not, we have a problem.
It doesn't and regardless, you want to have this CPUID querying as
simple as possible. No special handling, no special pref
On 08/02/16 14:30, Juergen Gross wrote:
> When adding more than one LUN to a frontend a warning for a failed
> assignment is issued in dom0 for each already existing LUN. Avoid this
> warning by checking for a LUN already existing when existence is
> allowed (scsiback_do_add_lun() called with try =
On 02/08/2016 11:35 AM, Borislav Petkov wrote:
On Mon, Feb 08, 2016 at 11:31:04AM -0500, Boris Ostrovsky wrote:
I think we are OK for PV because this code will be executed after pvops are
set and so we will be calling xen_cpuid().
Not for the early loader - it is too early for pvops then. So
On 08/02/16 17:46, David Vrabel wrote:
> On 08/02/16 14:30, Juergen Gross wrote:
>> When adding more than one LUN to a frontend a warning for a failed
>> assignment is issued in dom0 for each already existing LUN. Avoid this
>> warning by checking for a LUN already existing when existence is
>> all
On 08/02/16 16:50, Juergen Gross wrote:
> On 08/02/16 17:46, David Vrabel wrote:
>> On 08/02/16 14:30, Juergen Gross wrote:
>>> When adding more than one LUN to a frontend a warning for a failed
>>> assignment is issued in dom0 for each already existing LUN. Avoid this
>>> warning by checking for a
On 08/02/16 16:45, Borislav Petkov wrote:
> On Mon, Feb 08, 2016 at 04:38:40PM +, Andrew Cooper wrote:
>> Does the early loader have extable support? If so, this is fairly easy
>> to fix. If not, we have a problem.
> It doesn't and regardless, you want to have this CPUID querying as
> simple
On Mon, Feb 08, 2016 at 11:41:16AM -0500, Boris Ostrovsky wrote:
> Keep in mind that Xen PV doesn't go through startup_32|64(). It starts at
> xen_start_kernel (save for a small stub before that), which sets pvops. It
> "joins" regular/baremetal code in
> i386_start_kernel/x86_64_start_reservation
On 02/08/2016 11:45 AM, Borislav Petkov wrote:
On Mon, Feb 08, 2016 at 04:38:40PM +, Andrew Cooper wrote:
Does the early loader have extable support? If so, this is fairly easy
to fix. If not, we have a problem.
It doesn't and regardless, you want to have this CPUID querying as
simple a
On Mon, Feb 8, 2016 at 7:27 AM, Ian Campbell
wrote:
> On Sun, 2016-02-07 at 09:44 -0800, Suriyan Ramasami wrote:
> > The Odroid-XU3/XU4 from hardkernel is an Exynos 5422 based board.
> > Code from mcpm-exynos.c and mcpm-platsmp.c from the Linux kernel
> > has been used to get all the 8 cores from
This patch merges almost identical functions hvm_event_int3
and hvm_event_single_step into a single function called
hvm_event_software_breakpoint.
Signed-off-by: Corneliu ZUZU
---
xen/arch/x86/hvm/event.c| 52 ++---
xen/arch/x86/hvm/vmx/vmx.c | 11
X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry,
also move arch/arm/hvm.c to arch/arm/hvm/hvm.c.
Signed-off-by: Corneliu ZUZU
---
xen/arch/arm/Makefile | 2 +-
xen/arch/arm/hvm.c| 67 ---
xen/arch/arm/hvm/Makefile |
This patch moves bitfield members for single-step, software-breakpoint and
guest-request monitor vm-events from the arch-side (struct arch_domain) to
the common-side (struct domain). Ctrl-reg bits (i.e. write_ctrlreg_* members)
are left on the arch-side, because control-registers number can vary ac
This patch series is an attempt to move (most) of the monitor vm-events code to
the common-side.
Patches summary:
1. Move xen/arch/arm/hvm.c to xen/arch/arm/hvm/hvm.c
2. Merge almost identical functions hvm_event_int3 + This patch series is an
attempt to move (most) of the monitor vm-events co
* rename arch/x86/hvm/event_x86.c to arch/x86/hvm/event.c and
asm-{x86,arm}/hvm/event_arch.h to asm-{x86/arm}/hvm/event.h (last commit
before this one explains why this was necessary)
Minor fixes:
* ARM fix: xen/common/hvm/event.c was not actually compiled
(see file-changes
(last commit before this one explains why this was necessary)
Signed-off-by: Corneliu ZUZU
---
xen/arch/x86/Makefile | 2 +-
xen/arch/x86/monitor.c | 72 +
xen/arch/x86/monitor_x86.c | 72 -
1. Kconfig:
* Added Kconfigs for common monitor vm-events:
# see files: common/Kconfig, x86/Kconfig
HAS_VM_EVENT_WRITE_CTRLREG
HAS_VM_EVENT_SINGLESTEP
HAS_VM_EVENT_SOFTWARE_BREAKPOINT
HAS_VM_EVENT_GUEST_REQUEST
2. Moved monitor_domctl from arch-side to common-side
2.1. Moved
1. Moved hvm_event_traps, hvm_event_cr, hvm_event_guest_request,
hvm_event_software_breakpoint from arch-side to common-side
1.1. Moved arch/x86/hvm/event.c to common/hvm/event.c
# see files: arch/x86/hvm/Makefile, xen/common/hvm/Makefile,
xen/com
On Mon, 8 Feb 2016, Ian Campbell wrote:
> Currently xen_dma_map_page concludes that DMA to anything other than
> the head page of a compound page must be foreign, since the PFN of the
> page is that of the head.
>
> Fix the check to instead consider the whole of a compound page to be
> local if th
> >> The logic makes sense, so Acked-by: Andrew Cooper
> >> for the x86-related nature, but it would be
> >> nice to have a review from Tamas for the vm_event side of things.
> >
> > Thanks! Of course. Hopefully Tamas will like this, based on a
> > conversation we've had a few days ago here.
>
Ye
On 08/02/16 16:57, Corneliu ZUZU wrote:
> X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry,
> also move arch/arm/hvm.c to arch/arm/hvm/hvm.c.
>
> Signed-off-by: Corneliu ZUZU
For future reference, constructing your patches with -M (detect renames)
makes reviews of patches li
On 2/8/2016 6:57 PM, Corneliu ZUZU wrote:
This patch series is an attempt to move (most) of the monitor vm-events code to
the common-side.
Patches summary:
1. Move xen/arch/arm/hvm.c to xen/arch/arm/hvm/hvm.c
2. Merge almost identical functions hvm_event_int3 + hvm_event_single_step ->
hvm_eve
There are only four users, and invbool_param() is an unnecessary cognitive
overhead to use.
Convert the four users to boolean_param(), and consistency use opt_* for the
variable name.
No change to the behaviour of the command line arguments.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
There is no reason for any of it to be modified. Additionally, link
.init.setup beside the other constant .init data.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: Ian Campbell
CC: Stefano Stabellini
---
xen/arch/arm/xen.lds.S | 11 ++-
x
There are now no users. No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: Ian Campbell
---
xen/common/kernel.c| 3 +--
xen/include/xen/init.h | 5 -
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/xen/common/kernel.c b/xen/common/
On 2/8/2016 7:04 PM, Andrew Cooper wrote:
On 08/02/16 16:57, Corneliu ZUZU wrote:
X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry,
also move arch/arm/hvm.c to arch/arm/hvm/hvm.c.
Signed-off-by: Corneliu ZUZU
For future reference, constructing your patches with -M (detec
On Mon, Feb 08, 2016 at 04:53:00PM +, Andrew Cooper wrote:
> As an alternative check which should be doable this early on, peeking in
> the head of hypercall_page should work. If Linux was booted as a PV
> guest, the hypercall_page will have been constructed by the domain
> builder, and won't
On 08/02/16 17:12, Corneliu ZUZU wrote:
> On 2/8/2016 7:04 PM, Andrew Cooper wrote:
>> On 08/02/16 16:57, Corneliu ZUZU wrote:
>>> X86-side hvm.c is @ arch/x86/hvm/hvm.c. To maintain arm<->x86 symmetry,
>>> also move arch/arm/hvm.c to arch/arm/hvm/hvm.c.
>>>
>>> Signed-off-by: Corneliu ZUZU
>> For
On 08/02/16 16:57, Corneliu ZUZU wrote:
> diff --git a/xen/include/asm-x86/hvm/event.h b/xen/include/asm-x86/hvm/event.h
> index 11eb1fe..7c2252b 100644
> --- a/xen/include/asm-x86/hvm/event.h
> +++ b/xen/include/asm-x86/hvm/event.h
> @@ -27,9 +27,8 @@ bool_t hvm_event_cr(unsigned int index, unsign
On Thu, Feb 4, 2016 at 5:27 AM, Razvan Cojocaru
wrote:
> Currently, after receiving a vm_event reply requesting emulation,
> the actual emulation is triggered in p2m_mem_access_check(),
> which means that we're waiting for the page fault to occur again
> before emulating. Aside from the performan
Will be folded into appropriate patches in v3.
---
xen/arch/x86/cpu/amd.c | 15 +--
xen/arch/x86/domctl.c | 15 +++
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index deb98ea..3e345fe 100644
--- a/xen/arch/
On Mon, Feb 8, 2016 at 10:15 AM, Andrew Cooper
wrote:
> On 08/02/16 16:57, Corneliu ZUZU wrote:
> > diff --git a/xen/include/asm-x86/hvm/event.h
> b/xen/include/asm-x86/hvm/event.h
> > index 11eb1fe..7c2252b 100644
> > --- a/xen/include/asm-x86/hvm/event.h
> > +++ b/xen/include/asm-x86/hvm/event.
On Wed, Feb 03, 2016 at 10:26:58AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Feb 03, 2016 at 03:22:30PM +0100, Marek Marczykowski-Górecki wrote:
> > On Mon, Feb 01, 2016 at 09:50:53AM -0500, Konrad Rzeszutek Wilk wrote:
> > > > The second bullet looks at first pretty interesting from this PoV,
1 - 100 of 138 matches
Mail list logo
