flight 105805 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105805/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 9 xen-boot/src_host fail REGR. vs. 105785
Regressions which are r
On 02/14/2017 10:27 PM, Konrad Rzeszutek Wilk wrote:
On Mon, Feb 13, 2017 at 10:50:49AM +0200, Oleksandr Andrushchenko wrote:
Hi, Konrad!
Thank you for reviewing this.
On 02/10/2017 11:27 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Feb 10, 2017 at 09:29:58AM +0200, Oleksandr Andrushchenko wrote:
Hi Konrad,
Thanks for the feedback.
On 7 February 2017 at 00:05, Konrad Rzeszutek Wilk
wrote:
> On Mon, Feb 06, 2017 at 11:39:08PM +0530, Bhupinder Thakur wrote:
>> As per "VM System Specification for ARM Processors", there is a requirement
>> for Xen to support guest console
>> over pl011 UAR
flight 105803 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105803/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 4 host-build-prep fail REGR. vs. 59254
test-armhf-armhf-xl
This run is configured for baseline tests only.
flight 68560 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68560/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 6 xen-boot
On Tue, Feb 14, 2017 at 11:42 AM, Thomas Garnier wrote:
> The KVM segment_base function is confusing. This patch replaces integers
> with appropriate flags, simplify constructs and add comments.
It could pay to put this first in the series, but last is probably fine, too.
>
> Signed-off-by: Thom
flight 105799 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105799/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-xsm 3 host-install(3)broken REGR. vs. 10575
On Mon, 30 Jan 2017, Andre Przywara wrote:
> The MAPD command maps a device by associating a memory region for
> storing ITTEs with a certain device ID.
> We just store the given guest physical address in the device table.
> We don't map the device tables permanently, as their alignment
> requireme
flight 105795 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105795/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15
guest-localmigrate/x10 fail REGR. vs. 592
On Mon, 30 Jan 2017, Andre Przywara wrote:
> This introduces the ITS command handler for the CLEAR command, which
> clears the pending state of an LPI.
> This removes a not-yet injected, but already queued IRQ from a VCPU.
>
> Signed-off-by: Andre Przywara
Please see alpine.DEB.2.10.161108160858
On Thu, 22 Dec 2016, Andre Przywara wrote:
> Create a new file to hold the emulation code for the ITS widget.
> For now we emulate the memory mapped ITS registers and provide a stub
> to introduce the ITS command handling framework (but without actually
> emulating any commands at this time).
>
>
On Mon, 30 Jan 2017, Andre Przywara wrote:
> Allow a guest to provide the address and size for the memory regions
> it has reserved for the GICv3 pending and property tables.
> We sanitise the various fields of the respective redistributor
> registers and map those pages into Xen's address space to
On Mon, 30 Jan 2017, Andre Przywara wrote:
> If a guest disables an LPI, we do not forward this to the associated
> host LPI to avoid queueing commands to the host ITS command queue.
> So it may happen that an LPI fires nevertheless on the host. In this
> case we can bail out early, but have to sav
On 14/02/2017 22:47, Tamas K Lengyel wrote:
> (XEN) Switched to APIC driver x2apic_cluster.
> (XEN) XSM Framework v1.0.0 initialized
> (XEN) Flask: 128 avtab hash slots, 394 rules.
> (XEN) Flask: 128 avtab hash slots, 394 rules.
> (XEN) Flask: 5 users, 3 roles, 43 types, 2 bools
> (XEN) Flask: 12
On Mon, 30 Jan 2017, Andre Przywara wrote:
> Now that the host part of the ITS code is in place, we can enable the
> ITS and also LPIs on each redistributor to get the show rolling.
> At this point there would be no LPIs mapped, as guests don't know about
> the ITS yet.
>
> Signed-off-by: Andre Pr
flight 105796 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105796/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105787
test-armhf-armhf-libvirt-x
Hi all,
I'm having some strange issues with Xen 4.8 when I try to boot with
iommu disabled.
(XEN) Xen version 4.8.0 (root@lan) (gcc (Debian 5.4.1-4) 5.4.1
20161202) debug=n Tue Feb 14 15:32:55 MST 2017
(XEN) Latest ChangeSet:
(XEN) Bootloader: GRUB 2.02~beta3-4
(XEN) Command line: placeholder dom
On 02/14/2017 05:29 AM, Jan Beulich wrote:
They're all solely dependent on guest type, so we don't need to repeat
all the same four pointers in every vCPU control structure. Instead use
static const structures, and store pointers to them in the domain
control structure.
Since touching it anywa
On Mon, 13 Feb 2017, Vijay Kilari wrote:
> Hi Andre,
>
> I tried your patch series on HW. Dom0 boots but no LPIs are coming to Dom0.
> So I made below patch to consider segment ID in generating devid,
> I see below panic from _xmalloc().
>
> Complete log is here
> http://pastebin.com/btythn2V
This run is configured for baseline tests only.
flight 68559 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68559/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 11 guest-start
On Tue, 14 Feb 2017, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 13, 2017 at 11:46:40AM -0800, Stefano Stabellini wrote:
> > Changes in v9:
> > - specify max-page-order must be >= 1
> > - clarifications
> > - add "Expanding the protocol"
> > - add padding after out_error
> > - add "Why ring.h is not
On Tue, 14 Feb 2017, Konrad Rzeszutek Wilk wrote:
> On Mon, Feb 13, 2017 at 11:47:26AM -0800, Stefano Stabellini wrote:
>
> Reviewed-by: Konrad Rzeszutek Wilk
Thank you! For your convenience:
---
docs: add Xen transport for 9pfs
Signed-off-by: Stefano Stabellini
Reviewed-by: Konrad Rzeszute
On Tue, 14 Feb 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 02/14/2017 12:59 AM, Stefano Stabellini wrote:
> > On Mon, 30 Jan 2017, Andre Przywara wrote:
> > > static int its_map_baser(void __iomem *basereg, uint64_t regc, int
> > > nr_items)
> > > @@ -150,6 +191,11 @@ int gicv3_its_init(struct
On Mon, 30 Jan 2017, Andre Przywara wrote:
> Upon receiving an LPI, we need to find the right VCPU and virtual IRQ
> number to get this IRQ injected.
> Iterate our two-level LPI table to find this information quickly when
> the host takes an LPI. Call the existing injection function to let the
> GI
Hi Stefano,
On 02/14/2017 12:59 AM, Stefano Stabellini wrote:
On Mon, 30 Jan 2017, Andre Przywara wrote:
static int its_map_baser(void __iomem *basereg, uint64_t regc, int nr_items)
@@ -150,6 +191,11 @@ int gicv3_its_init(struct host_its *hw_its)
}
}
+hw_its->cmd_buf = its_m
On Mon, 30 Jan 2017, Andre Przywara wrote:
> For the same reason that allocating a struct irq_desc for each
> possible LPI is not an option, having a struct pending_irq for each LPI
> is also not feasible. However we actually only need those when an
> interrupt is on a vCPU (or is about to be injec
On Mon, Feb 13, 2017 at 10:50:49AM +0200, Oleksandr Andrushchenko wrote:
> Hi, Konrad!
>
> Thank you for reviewing this.
>
> On 02/10/2017 11:27 PM, Konrad Rzeszutek Wilk wrote:
> > On Fri, Feb 10, 2017 at 09:29:58AM +0200, Oleksandr Andrushchenko wrote:
> > > From: Oleksandr Andrushchenko
> > >
On Tue, Feb 14, 2017 at 09:02:14PM +0100, Olaf Hering wrote:
> On Tue, Feb 14, Stefano Stabellini wrote:
>
> > Interestingly, my "git am" is unable to apply those patches. Does it
> > work for you? I cannot see anything wrong with them, but they don't
> > work. If the problem is that they are too
Hi Stefano,
On 02/14/2017 06:20 PM, Stefano Stabellini wrote:
On Tue, 14 Feb 2017, Julien Grall wrote:
Hi Stefano,
On 02/13/2017 07:59 PM, Stefano Stabellini wrote:
On Mon, 13 Feb 2017, Julien Grall wrote:
Hi Stefano,
On 10/02/17 01:01, Stefano Stabellini wrote:
On Fri, 3 Feb 2017, Edgar E
On Tue, Feb 14, 2017 at 12:11 PM, Stefano Stabellini
wrote:
> On Tue, 14 Feb 2017, Julien Grall wrote:
>> > > > 10. Domains on which the monitor privileged call feature is enabled
>> > > > (which is by default disabled for all domains) should not be able to
>> > > > issue firmware calls via
On Mon, 30 Jan 2017, Andre Przywara wrote:
> To get MSIs from devices forwarded to a CPU, we need to name the device
> and its MSIs by mapping them to an ITS.
> Since this involves queueing commands to the ITS command queue, we can't
> really afford to do this during the guest's runtime, as this wo
On Mon, 30 Jan 2017, Andre Przywara wrote:
> The number of LPIs on a host can be potentially huge (millions),
> although in practise will be mostly reasonable. So prematurely allocating
> an array of struct irq_desc's for each LPI is not an option.
> However Xen itself does not care about LPIs, as
On Tue, Feb 14, Stefano Stabellini wrote:
> Interestingly, my "git am" is unable to apply those patches. Does it
> work for you? I cannot see anything wrong with them, but they don't
> work. If the problem is that they are too large, please send the files
> as attachments.
Its the '\ No newline a
This patch makes the GDT remapped pages read-only to prevent corruption.
This change is done only on 64-bit.
The native_load_tr_desc function was adapted to correctly handle a
read-only GDT. The LTR instruction always writes to the GDT TSS entry.
This generates a page fault if the GDT is read-only
This patch aligns MODULES_END to the beginning of the Fixmap section.
It optimizes the space available for both sections. The address is
pre-computed based on the number of pages required by the Fixmap
section.
It will allow GDT remapping in the Fixmap section. The current
MODULES_END static addre
Each processor holds a GDT in its per-cpu structure. The sgdt
instruction gives the base address of the current GDT. This address can
be used to bypass KASLR memory randomization. With another bug, an
attacker could target other per-cpu structures or deduce the base of
the main memory section (PAGE
The KVM segment_base function is confusing. This patch replaces integers
with appropriate flags, simplify constructs and add comments.
Signed-off-by: Thomas Garnier
---
Based on next-20170213
---
arch/x86/kvm/vmx.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
On Mon, Feb 13, 2017 at 11:46:40AM -0800, Stefano Stabellini wrote:
> Changes in v9:
> - specify max-page-order must be >= 1
> - clarifications
> - add "Expanding the protocol"
> - add padding after out_error
> - add "Why ring.h is not needed"
Reviewed-by: Konrad Rzeszutek Wilk
_
On Mon, Feb 13, 2017 at 11:47:26AM -0800, Stefano Stabellini wrote:
Reviewed-by: Konrad Rzeszutek Wilk
> Changes in v5:
> - add padding after out_prod
> - add "Why ring.h is not needed"
> - specify max-ring-page-order >= 1
___
Xen-devel mailing list
X
On Tue, 14 Feb 2017, Julien Grall wrote:
> > > > 10. Domains on which the monitor privileged call feature is enabled
> > > > (which is by default disabled for all domains) should not be able to
> > > > issue firmware calls via SMCs/HVCs so that such calls reach the
> > > > firmware directly
On 14/02/17 18:33, Daniel Kiper wrote:
> init.data section is clearly writable, so, add "w" flag to its
> definition in xen/arch/x86/boot/x86_64.S.
>
> Signed-off-by: Daniel Kiper
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.x
On Tue, Feb 14, 2017 at 11:06 AM, Julien Grall wrote:
> Hi,
>
>
> On 02/13/2017 10:14 PM, Stefano Stabellini wrote:
>>
>> On Mon, 13 Feb 2017, Tamas K Lengyel wrote:
>>>
>>> On Mon, Feb 13, 2017 at 2:54 PM, Stefano Stabellini
>>> wrote:
On Mon, 13 Feb 2017, Tamas K Lengyel wrote:
>
flight 105797 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105797/
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 Tue, Feb 14, Stefano Stabellini wrote:
> Also, I tried to do the same conversion with my copy of Libreoffice and
> the FODT files produced are significantly different from yours, which
> means, even if we use FODT docs, we are probably going to be unable to
> send changes as meaningful text pat
On Tue, 14 Feb 2017, Boris Ostrovsky wrote:
> On 02/13/2017 12:03 PM, Paul Durrant wrote:
> > Recently a new dm_op[1] hypercall was added to Xen to provide a mechanism
> > for restricting device emulators (such as QEMU) to a limited set of
> > hypervisor operations, and being able to audit those op
On Tue, Feb 14, 2017 at 07:33:24PM +0100, Daniel Kiper wrote:
> This way Xen can be loaded on EFI platforms using GRUB2 and
> other boot loaders which support multiboot2 protocol.
>
> Signed-off-by: Daniel Kiper
I am posting diff between v14 and v15 for your convenience.
diff --git a/xen/arch/x8
flight 105790 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105790/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 105756
test-amd64-amd64-x
Add multiboot2 protocol support for relocatable images. Only GRUB2 with
"multiboot2: Add support for relocatable images" patch understands
that feature. Older multiboot protocol (regardless of version)
compatible loaders ignore it and everything works as usual.
Signed-off-by: Daniel Kiper
Acked-b
This way macro name better describes its function.
Currently it is used to calculate symbol offset in
relation to the beginning of Xen image mapping.
However, value returned by sym_offs() for a given
symbol is not always equal its physical address.
There is no functional change.
Suggested-by: Jan
..calculating its value during runtime.
Signed-off-by: Daniel Kiper
Acked-by: Jan Beulich
Reviewed-by: Doug Goldstein
---
xen/arch/x86/setup.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 525ce7a..a5ce926 100644
---
Every multiboot protocol (regardless of version) compatible image must
specify its load address (in ELF or multiboot header). Multiboot protocol
compatible loader have to load image at specified address. However, there
is no guarantee that the requested memory region (in case of Xen it starts
at 2
This way Xen can be loaded on EFI platforms using GRUB2 and
other boot loaders which support multiboot2 protocol.
Signed-off-by: Daniel Kiper
---
v15 - suggestions/fixes:
- rearrange inline assembly arguments in
xen/arch/x86/efi/stub.c:efi_multiboot2()
(suggested by Jan Beulich),
init.data section is clearly writable, so, add "w" flag to its
definition in xen/arch/x86/boot/x86_64.S.
Signed-off-by: Daniel Kiper
---
xen/arch/x86/boot/x86_64.S |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index
Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.
If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file con
Subsequent patches introducing relocatable early boot code play with
page tables using 2 MiB huge pages. If load address is not aligned at
2 MiB then code touching such page tables must have special cases for
start and end of Xen image memory region. So, let's make life easier
and move default load
There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on 1 MiB address and we should
not allocate a memory fro
Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.
This way we are laying the foundation for EFI + GRUB2 + Xen development.
Signed-off-by: Daniel Kiper
Reviewed-by: Jan Beulich
Reviewed-by: Doug Goldstein
Reviewe
Hi,
I am sending fifteenth version of multiboot2 protocol support for
legacy BIOS and EFI platforms. This patch series release contains
fixes for all known/confirmed issues.
The final goal is xen.efi binary file which could be loaded by EFI
loader, multiboot (v1) protocol (only on legacy BIOS pla
On Tue, 14 Feb 2017, Olaf Hering wrote:
> On Tue, Jan 17, Stefano Stabellini wrote:
>
> > On Tue, 17 Jan 2017, Olaf Hering wrote:
> > > On Fri, Jan 13, Julien Grall wrote:
> > >
> > > > Regarding the format. Does ODT will allow git to do proper diff?
> > >
> > > There is flat ODT, "Safe as ..."
On Tue, 14 Feb 2017, Julien Grall wrote:
> Hi Stefano,
>
> On 02/13/2017 07:59 PM, Stefano Stabellini wrote:
> > On Mon, 13 Feb 2017, Julien Grall wrote:
> >> Hi Stefano,
> >>
> >> On 10/02/17 01:01, Stefano Stabellini wrote:
> >>> On Fri, 3 Feb 2017, Edgar E. Iglesias wrote:
> A possible hac
Hi,
On 02/13/2017 10:14 PM, Stefano Stabellini wrote:
On Mon, 13 Feb 2017, Tamas K Lengyel wrote:
On Mon, Feb 13, 2017 at 2:54 PM, Stefano Stabellini
wrote:
On Mon, 13 Feb 2017, Tamas K Lengyel wrote:
On Mon, Feb 13, 2017 at 2:13 PM, Stefano Stabellini
wrote:
On Mon, 13 Feb 2017, Tamas K L
On 14/02/17 17:45, Andrew Cooper wrote:
> On 14/02/17 17:42, George Dunlap wrote:
>> On 13/02/17 11:00, Andrew Cooper wrote:
>>> XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might
>>> be
>>> lower than the real maxphysaddr, to avoid overflowing the superpage shadow
>>> bac
On 14/02/17 17:49, George Dunlap wrote:
> On 14/02/17 17:45, Andrew Cooper wrote:
>> On 14/02/17 17:42, George Dunlap wrote:
>>> On 13/02/17 11:00, Andrew Cooper wrote:
XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which
might be
lower than the real maxphysaddr, to
On 14/02/17 17:42, George Dunlap wrote:
> On 13/02/17 11:00, Andrew Cooper wrote:
>> XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might
>> be
>> lower than the real maxphysaddr, to avoid overflowing the superpage shadow
>> backpointer.
>>
>> However, plenty of hardware has
On Tue, Feb 14, 2017 at 02:57:42PM +, Julien Grall wrote:
> Hi,
>
> On 01/26/2017 09:11 PM, Julien Grall wrote:
> > Hi,
> >
> > On 26/01/2017 19:01, Boris Ostrovsky wrote:
> > > On 01/26/2017 12:18 PM, Ian Jackson wrote:
> > > > Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 1046
On 13/02/17 11:00, Andrew Cooper wrote:
> XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might be
> lower than the real maxphysaddr, to avoid overflowing the superpage shadow
> backpointer.
>
> However, plenty of hardware has a physical address width less that 44 bits,
> and
At 06:37 -0700 on 13 Feb (1486967832), Jan Beulich wrote:
> >>> On 13.02.17 at 14:19, wrote:
> > -tss = mem_alloc(128, 128);
> > -memset(tss, 0, 128);
> > +tss = mem_alloc(TSS_SIZE, TSS_SIZE);
>
> tss = mem_alloc(TSS_SIZE, 128);
>
> is sufficient here, as I've noticed (only) whil
Hi,
At 06:19 -0700 on 13 Feb (1486966797), Jan Beulich wrote:
> The present way of setting this up is flawed: Leaving the I/O bitmap
> pointer at zero means that the interrupt redirection bitmap lives
> outside (ahead of) the allocated space of the TSS. Similarly setting a
> TSS limit of 255 when
Here is version two, with minor revisions based on comments from version
1. Please give any feedback by 28 February. Thanks!
Issuing advisories has a cost: It costs the security team significant
amounts of time to craft and send the advisories; it costs many of our
downstreams time to apply, bui
On 02/13/2017 12:03 PM, Paul Durrant wrote:
> Recently a new dm_op[1] hypercall was added to Xen to provide a mechanism
> for restricting device emulators (such as QEMU) to a limited set of
> hypervisor operations, and being able to audit those operations in the
> kernel of the domain in which they
Hi Stefano,
On 02/13/2017 07:59 PM, Stefano Stabellini wrote:
> On Mon, 13 Feb 2017, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 10/02/17 01:01, Stefano Stabellini wrote:
>>> On Fri, 3 Feb 2017, Edgar E. Iglesias wrote:
A possible hack could be to allocate a chunk of DDR dedicated for PCI DMA
These two patches don't apply anymore. Please rebase.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Tue, Feb 14, 2017 at 12:30:55PM +, Roger Pau Monne wrote:
> The following incorrect format specifiers and incorrect number of parameters
> passed to printf like functions are reported by clang:
>
> mce.c:601:18: error: data argument not used by format string
> [-Werror,-Wformat-extra-args]
Hi,
Ping? As Ian mentioned earlier, without this series it is not possible
to build Xen tools for ARM64 in osstest.
Cheers,
On 02/08/2017 07:50 PM, Julien Grall wrote:
Hi,
On 24/01/17 22:19, David Scott wrote:
On 24 Jan 2017, at 11:35, Ian Jackson wrote:
Ian Jackson writes ("[PATCH 0/2
At 16:04 + on 14 Feb (1487088291), Andrew Cooper wrote:
> Hmm ok. With the other bugfix of not dropping the first line, this hunk
> is now simply:
>
> @@ -504,7 +505,7 @@ void recalculate_cpuid_policy(struct domain *d)
>
> p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphy
flight 105792 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105792/
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
Hello,
and ping.
Olaf
On Wed, Aug 17, Olaf Hering wrote:
> Starting with xen-4.7 cpuid() will return with the hypervisor bit set
> in a dom0 when running on an AMD system. As a result biosdevname
> thinks it runs in a guest and does nothing. Detect a dom0 by looking
> into xenfs. This works wi
On Tue, Jan 17, Stefano Stabellini wrote:
> On Tue, 17 Jan 2017, Olaf Hering wrote:
> > On Fri, Jan 13, Julien Grall wrote:
> >
> > > Regarding the format. Does ODT will allow git to do proper diff?
> >
> > There is flat ODT, "Safe as ..." and pick the better format from the
> > pulldown menu.
Fixes c33b5f013d ("Add XENV to docs/misc")
Signed-off-by: Olaf Hering
---
docs/misc/xen-env-table-spec.fodt | 852 ++
1 file changed, 852 insertions(+)
diff --git a/docs/misc/xen-env-table-spec.fodt
b/docs/misc/xen-env-table-spec.fodt
new file mode 100644
in
Fixes 140b31a8de ("Add STAO spec to docs/misc")
Signed-off-by: Olaf Hering
---
docs/misc/status-override-table-spec.fodt | 707 ++
1 file changed, 707 insertions(+)
diff --git a/docs/misc/status-override-table-spec.fodt
b/docs/misc/status-override-table-spec.fodt
ne
Signed-off-by: Olaf Hering
---
docs/misc/xen-env-table-spec.odt | Bin 19204 -> 0 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
diff --git a/docs/misc/xen-env-table-spec.odt b/docs/misc/xen-env-table-spec.odt
deleted file mode 100644
index
c8de7ca7d8e7d00dabe9d7bebef1e8117e47f95e..0
Signed-off-by: Olaf Hering
---
docs/misc/status-override-table-spec.odt | Bin 20206 -> 0 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
diff --git a/docs/misc/status-override-table-spec.odt
b/docs/misc/status-override-table-spec.odt
deleted file mode 100644
index
4ea576b2c248a70445a6a5
The odt files should have been saved as Flat XML via 'Save as ...'.
git send-email warns about lines longer than 998 chars. Hopefully all
involved mail services have no silly limits.
Olaf
Olaf Hering (4):
docs: convert STAO from odt to fodt
docs: convert XENV from odt to fodt
docs: remove
On 13/02/17 16:59, Tamas K Lengyel wrote:
On Mon, Feb 13, 2017 at 9:37 AM, Julien Grall wrote:
Hi Tamas,
On 13/02/17 16:20, Tamas K Lengyel wrote:
On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk
wrote:
Hello,
This e-mail is sort of follow-up to the two threads: [1] (my thread
about
On 14/02/17 14:46, Waiman Long wrote:
> On 02/14/2017 04:39 AM, Peter Zijlstra wrote:
>> On Mon, Feb 13, 2017 at 05:34:01PM -0500, Waiman Long wrote:
>>> It is the address of &steal_time that will exceed the 32-bit limit.
>> That seems extremely unlikely. That would mean we have more than 4G
>> wor
On 13/02/17 12:36, Jan Beulich wrote:
On 13.02.17 at 12:00, wrote:
>> @@ -502,11 +503,9 @@ void recalculate_cpuid_policy(struct domain *d)
>>
>> cpuid_featureset_to_policy(fs, p);
>>
>> -p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
>> p->extd.maxphy
Hi Tamas,
On 13/02/17 16:20, Tamas K Lengyel wrote:
On Fri, Feb 10, 2017 at 5:14 PM, Volodymyr Babchuk
wrote:
Hello,
This e-mail is sort of follow-up to the two threads: [1] (my thread
about TEE interaction) and [2] (Edgar's thread regarding handling SMC
calls in platform_hvc). I want to disc
On Tue, Feb 14, 2017 at 09:46:17AM -0500, Waiman Long wrote:
> On 02/14/2017 04:39 AM, Peter Zijlstra wrote:
> > On Mon, Feb 13, 2017 at 05:34:01PM -0500, Waiman Long wrote:
> >> It is the address of &steal_time that will exceed the 32-bit limit.
> > That seems extremely unlikely. That would mean w
> -Original Message-
[snip]
> > Thank you. Keep in mind that it will likely break against
> > older Xen versions (Xen 4.4?) as there is no xenctrl_compat.h
>
> I'm not sure you actually need to include that directly. I was going to try
> just
> adding the 'want compat' defines and seeing
On Mon, Feb 13, 2017 at 02:32:16PM +0800, Yi Sun wrote:
> This patch implements the CPU init and free flow including L3 CAT
> initialization and feature list free.
>
> Signed-off-by: Yi Sun
> ---
> v7:
> - initialize 'l3_cat'.
> - fix typo.
> - correct criteria to call 'free_feature'
Hi Andrew,
On 02/07/2017 06:57 PM, Andrew Cooper wrote:
The predicate is common between x86 and ARM, and is unlikley to be different/
NIT: s/unlikley/unlikely/
on other architectures. Drop the arch declarations and introduce a common
static inline in xen/mm.h instead.
Signed-off-by: Andrew
On Mon, Feb 13, 2017 at 02:32:13PM +0800, Yi Sun wrote:
> This patch creates CAT and CDP feature document in doc/features/. It describes
> key points to implement L3 CAT/CDP and L2 CAT which is described in details in
> Intel SDM "INTEL® RESOURCE DIRECTOR TECHNOLOGY (INTEL® RDT) ALLOCATION
> FEATU
On 14/02/17 08:55, Jan Beulich wrote:
On 13.02.17 at 19:26, wrote:
>> On 13/02/17 13:19, Jan Beulich wrote:
>>> ---
>>> TBD: Do we really want to re-init the TSS every time we are about to
>>> use it? This can happen quite often during boot, especially while
>>> grub is running.
>>
Hi Jan,
On 02/14/2017 10:51 AM, Jan Beulich wrote:
On 07.02.17 at 00:32, wrote:
Commit c7bdecae42 ("x86/apicv: fix RTC periodic timer and apicv issue") has
added a assertion that intack.vector is the highest priority vector. But
according to the osstest, the assertion failed sometimes. More di
flight 105786 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105786/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15
guest-localmigrate/x10 fail REGR. vs. 592
On Tue, Feb 14, 2017 at 03:39:00PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > Sent: 14 February 2017 15:32
> > To: Paul Durrant
> > Cc: xen-de...@lists.xenproject.org
> > Subject: Re: [PATCH v1] Make demu.git compil
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: 14 February 2017 15:32
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org
> Subject: Re: [PATCH v1] Make demu.git compiler under Xen 4.7 (and later)
>
> On Tue, Feb 14, 2017 at 03:26:34PM +
flight 105787 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105787/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105781
test-armhf-armhf-libvirt-x
On Tue, Feb 14, 2017 at 03:26:34PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > Sent: 14 February 2017 15:16
> > To: Paul Durrant
> > Cc: xen-de...@lists.xenproject.org
> > Subject: Re: [PATCH v1] Make demu.git compil
On 14/02/17 10:29, Jan Beulich wrote:
> They're all solely dependent on guest type, so we don't need to repeat
> all the same four pointers in every vCPU control structure. Instead use
> static const structures, and store pointers to them in the domain
> control structure.
>
> Since touching it any
1 - 100 of 170 matches
Mail list logo
