flight 122862 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122862/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 120365
test-armhf-armhf-libvirt-x
This run is configured for baseline tests only.
flight 74723 xen-4.10-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74723/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 15
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 122909 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122909/
Failures :
flight 122855 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122855/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail
REGR. vs. 118324
test
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 122908 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122908/
Failures :
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 122906 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122906/
Regression
flight 122847 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122847/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 122357
test-amd64-amd64-
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 122903 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122903/
Failures :
Hi all,
Following up from previous conversations with the committers, I am
appending a proposal for a new Xen Project sub-project aimed at embedded
and IoT. Let me know if you have questions or suggestions. Also,
sponsors are very welcome! :-)
FYI, I also have a presentation on ViryaOS at Xen Dev
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 122901 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122901/
Failures :
flight 122840 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122840/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken in 122727
build-arm64-xsm4 hos
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 122900 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122900/
Failures :
When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
but Dom Heap is increased by the same size. Tracing raidconfig we found
that the related ioctl() in megaraid_sas will call dma_alloc_coherent()
to apply memory. If the memory allocated by Dom0 is not in the DMA area,
it will e
On 5/17/18 12:10 PM, Greg KH wrote:
> On Thu, May 17, 2018 at 11:45:57AM -0700, Joe Jin wrote:
>> When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
>> but Dom Heap is increased by the same size. Tracing raidconfig we found
>> that the related ioctl() in megaraid_sas will call
On Thu, May 17, 2018 at 11:45:57AM -0700, Joe Jin wrote:
> When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
> but Dom Heap is increased by the same size. Tracing raidconfig we found
> that the related ioctl() in megaraid_sas will call dma_alloc_coherent()
> to apply memory.
When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
but Dom Heap is increased by the same size. Tracing raidconfig we found
that the related ioctl() in megaraid_sas will call dma_alloc_coherent()
to apply memory. If the memory allocated by Dom0 is not in the DMA area,
it will e
On 05/17/2018 05:09 PM, Konrad Rzeszutek Wilk wrote:
On Thu, May 17, 2018 at 08:51:38AM +0300, Oleksandr Andrushchenko wrote:
On 05/17/2018 08:50 AM, Juergen Gross wrote:
On 17/05/18 07:45, Oleksandr Andrushchenko wrote:
Hi, Juergen!
This patch should go into 4.11 as it is needed for a relate
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 122899 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122899/
Failures :
Marek / Ian,
Nice to see PCI-passthrough getting some attention again.
On 17/05/18 17:12, Ian Jackson wrote:
> Marek Marczykowski-Górecki writes ("Re: Test for osstest, features used in
> Qubes OS"):
>> On Thu, May 17, 2018 at 01:26:30PM +0100, Ian Jackson wrote:
>>> Is it likely that this will
On Mon, May 14, 2018 at 10:57:46AM +0100, Ross Lagerwall wrote:
> The full size of the BAR is stored in the lower PCIIORegion.size. The
> upper PCIIORegion.size is 0. Calculate the size of the upper half
> correctly from the lower half otherwise the size read by the guest will
> be incorrect.
>
>
On 05/17/2018 11:02 AM, Jan Beulich wrote:
On 17.05.18 at 16:47, wrote:
>> @@ -64,6 +67,9 @@ ENTRY(pvh_start_xen)
>> mov %eax,%es
>> mov %eax,%ss
>>
>> +mov $PVH_CANARY_SEL,%eax
>> +mov %eax,%gs
> I doubt this is needed for 64-bit (you could equally well load zero or leave
On Thu, May 17, 2018 at 2:03 AM, Jan Beulich wrote:
On 07.02.18 at 17:00, wrote:
>> This patch as-is correctly tells the two possible formats apart. I
>> tested and Xen boots correctly both from the Shell and from the
>> firmware boot menu. I would not like to start addressing hypothetical
>
flight 122837 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122837/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
test-amd64-amd64-xl-pvhv2-amd 12
flight 74722 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74722/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 74702
jobs:
build-amd64 pass
build-armh
On Sat, 2018-05-12 at 16:27 +0800, Weiwei Jia wrote:
> We already have a prototype implementation based on KVM (Linux Kernel
> 3.19.8). Our patch for Linux Kernel 3.19.8 and the paper describing
> our idea are available in Github repository [1][2][3]. We are pleased
> to revise our patch in order t
flight 122898 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122898/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Thu, May 03, 2018 at 12:18:40PM +0100, Paul Durrant wrote:
> This patch removes the current hackery where IOREQ_TYPE_PCI_CONFIG
> reqyests are handled by faking PIO to 0xcf8 and 0xcfc and replaces it
^ requests
> with direct calls to pci_host_config_read/write_common().
> Doing so necessitat
>>> On 07.05.18 at 10:24, wrote:
> --- a/xen/arch/x86/cpu/mcheck/vmce.c
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c
> @@ -357,20 +357,14 @@ void vmce_save_vcpu_ctxt_one(struct vcpu *v, struct
> hvm_vmce_vcpu *ctxt)
> ctxt->mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl;
> }
>
> -static int vmce_save_v
If a domU has a qemu-xen instance attached, it is required to call qemus
"xen-save-devices-state" method. Without it, the receiving side of a PV
migration may be unable to lock the image:
xen be: qdisk-51712: xen be: qdisk-51712: error: Failed to get "write" lock
error: Failed to get "write" lock
>>> On 07.05.18 at 10:24, wrote:
> This patch introduces save_one() functions. They will be called in the
> *save() so we can extract data for a single instance.
Mostly fine, but please split up into one patch per save type.
> --- a/xen/arch/x86/cpu/mcheck/vmce.c
> +++ b/xen/arch/x86/cpu/mcheck/
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 17 May 2018 16:36
> To: xen-devel@lists.xenproject.org; qemu-bl...@nongnu.org; qemu-
> de...@nongnu.org
> Cc: Paul Durrant ; Stefano Stabellini
> ; Anthony Perard ;
> Kevin Wolf ; Max Reitz
> Subject: [PATCH
Now that helpers are present in xen_backend, this patch removes open-coded
calls to libxengnttab from the xen_disk code.
This patch also fixes one whitspace error in the assignment of the
XenDevOps initialise method.
Signed-off-by: Paul Durrant
Acked-by: Anthony Perard
---
Cc: Stefano Stabellin
This patch adds grant table helper functions to the xen_backend code to
localize error reporting and use of xen_domid.
The patch also defers the call to xengnttab_open() until just before the
initialise method in XenDevOps is invoked. This method is responsible for
mapping the shared ring. No prio
Certain functions in xen_disk are called with a pointer to xendev
(struct XenDevice *). They then use container_of() to acces the surrounding
blkdev (struct XenBlkDev) but then in various places use &blkdev->xendev
when use of the original xendev pointer is shorter to express and clearly
equivalent
Now that helpers are available in xen_backend, use them throughout all
Xen PV backends.
Signed-off-by: Paul Durrant
Acked-by: Anthony Perard
---
Cc: Stefano Stabellini
Cc: Greg Kurz
Cc: Paolo Bonzini
Cc: Jason Wang
Cc: Gerd Hoffmann
v2:
- New in v2
---
hw/9pfs/xen-9p-backend.c | 32 +
There is no longer any use of this flag outside of the xen_backend code.
Signed-off-by: Paul Durrant
Acked-by: Anthony Perard
---
Cc: Stefano Stabellini
v2:
- New in v2
---
hw/xen/xen_backend.c | 2 +-
include/hw/xen/xen_backend.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-
Since xen_disk now always copies data to and from a guest there is no need
to maintain a vector entry corresponding to every page of a request.
This means there is less per-request state to maintain so the ioreq
structure can shrink significantly.
Signed-off-by: Paul Durrant
Acked-by: Anthony Per
The grant copy operation was added to libxengnttab in Xen 4.8.0 (released
nearly 18 months ago) but the xen_disk PV backend QEMU is still carrying
a significant amount of code purely to remain compatible with older
versions of Xen.
As can be inferred from the diff stats below, removing this suppor
Currently the xen_disk source has to carry #ifdef exclusions to compile
against Xen older then 4.8. This is a bit messy so this patch lifts the
definition of struct xengnttab_grant_copy_segment and adds it into the
pre-4.8 compat area in xen_common.h, which allows xen_disk to be cleaned
up.
Signed
Now that the (native or emulated) xen_be_copy_grant_refs() helper is
always available, the xen_disk code can be significantly simplified by
removing direct use of grant map and unmap operations.
Signed-off-by: Paul Durrant
Acked-by: Anthony Perard
---
Cc: Stefano Stabellini
Cc: Kevin Wolf
Cc:
Not all Xen environments support the xengnttab_grant_copy() operation.
E.g. where the OS is FreeBSD or Xen is older than 4.8.0.
This patch introduces an emulation of that operation using
xengnttab_map_domain_grant_refs() and memcpy() for those environments.
Signed-off-by: Paul Durrant
---
Cc: St
Am Thu, 17 May 2018 16:54:00 +0200
schrieb Olaf Hering :
> Am Thu, 17 May 2018 14:55:10 +0200
> schrieb Juergen Gross :
> > libxl__need_xenpv_qemu() is used to determine whether a pv domain needs
> > a qemu process for at least one backend.
> Thanks. Too bad, d_config is not available in that c
Marek Marczykowski-Górecki writes ("Re: Test for osstest, features used in
Qubes OS"):
> On Thu, May 17, 2018 at 01:26:30PM +0100, Ian Jackson wrote:
> > Is it likely that this will depend on non-buggy host firmware ? If so
> > then we need to make arrangements to test it and only do it on hosts
Am Thu, 17 May 2018 16:54:00 +0200
schrieb Olaf Hering :
> Thanks. Too bad, d_config is not available in that context. It is probably
> known somewhere by the callers. I guess such caller needs to pass a bool down
> to suspend/resume.
It seems nothing inside libxl knows about libxl_domain_confi
Hi, I'm emailing you because I know you have an interest in XSM
(and therefore in its testing in osstest).
osstest manages the booting of its test hosts using the
distro-supplied bootloader arrangements for its dom0s. For Debian
that is update-grub. Currently, osstest has a hacked-up local copy
>>> On 17.05.18 at 16:47, wrote:
> @@ -64,6 +67,9 @@ ENTRY(pvh_start_xen)
> mov %eax,%es
> mov %eax,%ss
>
> + mov $PVH_CANARY_SEL,%eax
> + mov %eax,%gs
I doubt this is needed for 64-bit (you could equally well load zero or leave
in place what's there in that case), and loadi
On Thu, May 17, 2018 at 01:26:30PM +0100, Ian Jackson wrote:
> Marek Marczykowski-Górecki writes ("Test for osstest, features used in Qubes
> OS"):
> > As discussed some time ago, I'd like to help with adding tests for some
> > features we use in Qubes OS.
> >
> > IMO the easiest thing to test is
>>> On 07.05.18 at 23:07, wrote:
> @@ -2351,6 +2352,7 @@ static void dump_irqs(unsigned char key)
> printk(" %#02x -> %ps()\n", i, direct_apic_vector[i]);
>
> dump_ioapic_irq_info();
> +dump_avic_info();
> }
While this is better than a separate key, I still don't like i
Am Thu, 17 May 2018 14:55:10 +0200
schrieb Juergen Gross :
> libxl__need_xenpv_qemu() is used to determine whether a pv domain needs
> a qemu process for at least one backend.
Thanks. Too bad, d_config is not available in that context. It is probably
known somewhere by the callers. I guess such
>>> On 07.05.18 at 23:07, wrote:
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -64,6 +64,16 @@
> #include
> #include
>
> +static int parse_svm_param(const char *s);
This is unnecessary if you move ...
> +/*
> + * The 'svm' parameter en/dis-ables various SVM fea
On 05/15/2018 07:06 PM, Dan Williams wrote:
> On Tue, May 15, 2018 at 7:19 AM, George Dunlap
> wrote:
>> So, who decides what this SPA range and interleave set is? Can the
>> operating system change these interleave sets and mappings, or change
>> data from PMEM to BLK, and is so, how?
>
> The
>>> On 07.05.18 at 23:07, wrote:
> +void svm_avic_deliver_posted_intr(struct vcpu *v, u8 vec)
> +{
> +struct vlapic *vlapic = vcpu_vlapic(v);
> +
> +/* Fallback to use non-AVIC if vcpu is not enabled with AVIC. */
> +if ( !svm_avic_vcpu_enabled(v) )
> +{
> +if ( !vlapic_tes
We don't need to share PVH GDT layout with other GDTs, especially
since we now have a PVH-speciific entry (for stack canary segment).
Define PVH's own selectors.
(As a side effect of this change we are also fixing improper
reference to __KERNEL_CS)
Signed-off-by: Boris Ostrovsky
---
arch/x86/x
>>> On 07.05.18 at 23:07, wrote:
> @@ -65,6 +66,51 @@ avic_get_physical_id_entry(struct svm_domain *d, unsigned
> int index)
> return &d->avic_physical_id_table[index];
> }
>
> +static void avic_vcpu_load(struct vcpu *v)
> +{
> +struct arch_svm_struct *s = &v->arch.hvm_svm;
> +int
We are making calls to C code (e.g. xen_prepare_pvh()) which may use
stack canary (stored in GS segment).
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/xen-pvh.S | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/
Fix stack canary handling (in the first patch) and re-index PVH GDT to
make it explicit that the GDT PVH-specific
v3:
- Use GS base MSR for 64-bit mode
Boris Ostrovsky (2):
xen/PVH: Set up GS segment for stack canary
xen/PVH: Make GDT selectors PVH-specific
arch/x86/xen/xen-pvh.S | 46 +
On Thu, May 17, 2018 at 04:25:58PM +0200, Olaf Hering wrote:
> Am Tue, 3 Apr 2018 13:14:11 +0200
> schrieb Olaf Hering :
>
> > The exact value of cpu_khz can only be obtained via 'xl dmesg', and
> > therefore can be lost after some time. 'xl info' truncates the value to
> > full MHz. Adjust the o
On Thu, May 17, 2018 at 12:16:59PM +0100, Ian Jackson wrote:
> Previously, `make-*-flight' would not work unless FREEBSD_*_BUILDJOB
> was set. Now we use the anointed values if we can find them.
>
> If we can't, mg-anoint retrieve will print a warning.
>
> Signed-off-by: Ian Jackson
LGTM
Revi
Use error code from libxl namespace, a plain -1 is not valid in this context.
Signed-off-by: Olaf Hering
---
tools/libxl/libxl_qmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index be1fda18ba..0fe42813bf 100644
--- a/too
On Thu, May 17, 2018 at 04:09:04PM +0300, Oleksandr Andrushchenko wrote:
> On 05/17/2018 04:08 PM, Boris Ostrovsky wrote:
> > On 05/17/2018 01:31 AM, Oleksandr Andrushchenko wrote:
> > > I will go with the change you suggested and
> > > I'll send v4 tomorrow then.
> >
> >
> > Please make sure you
On Thu, May 17, 2018 at 12:16:58PM +0100, Ian Jackson wrote:
> Logically, the final branch of the if should be qualified with a check
> for the emptiness of FreeBSDDist. This is awkward in the current
> structure, since we really want to do the distpath lookup only if
> needed. (This is not very
Am Tue, 3 Apr 2018 13:14:11 +0200
schrieb Olaf Hering :
> The exact value of cpu_khz can only be obtained via 'xl dmesg', and
> therefore can be lost after some time. 'xl info' truncates the value to
> full MHz. Adjust the output to show the full khz value.
> This helps the host admin to track ho
On Thu, May 17, 2018 at 12:16:57PM +0100, Ian Jackson wrote:
> make-*-flight is going to want this.
>
> Signed-off-by: Ian Jackson
Reviewed-by: Roger Pau Monné
Just a style comment below.
> ---
> mg-anoint | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git
flight 122831 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/122831/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm broken in 122678
test-arm64-arm64-xl-xsm
On Thu, May 17, 2018 at 12:16:56PM +0100, Ian Jackson wrote:
> This makes `mg-anoint' in standalone mode a view onto an empty set of
> anointments. So now it becomes ok to call mg-anoint in make-*-flight.
>
> Signed-off-by: Ian Jackson
Reviewed-by: Roger Pau Monné
Thanks.
___
On Thu, May 17, 2018 at 08:51:38AM +0300, Oleksandr Andrushchenko wrote:
> On 05/17/2018 08:50 AM, Juergen Gross wrote:
> > On 17/05/18 07:45, Oleksandr Andrushchenko wrote:
> > > Hi, Juergen!
> > >
> > > This patch should go into 4.11 as it is needed for a related Linux
> > > kernel patch and the
On 17/05/18 14:38, Jan Beulich wrote:
On 17.05.18 at 15:26, wrote:
>> On 17/05/18 14:20, Jan Beulich wrote:
>>> Just like for HVM the feature set should be used for EBX output, while
>>> EAX should be restricted to the low 16 bits and ECX/EDX should be zero.
>>>
>>> Short of there being white
>>> On 17.05.18 at 15:26, wrote:
> On 17/05/18 14:20, Jan Beulich wrote:
>> Just like for HVM the feature set should be used for EBX output, while
>> EAX should be restricted to the low 16 bits and ECX/EDX should be zero.
>>
>> Short of there being white listing in place just like on the HVM side,
On 17/05/18 14:20, Jan Beulich wrote:
> Just like for HVM the feature set should be used for EBX output, while
> EAX should be restricted to the low 16 bits and ECX/EDX should be zero.
>
> Short of there being white listing in place just like on the HVM side,
> also zap leaves 6, 9, and 0x8007
Just like for HVM the feature set should be used for EBX output, while
EAX should be restricted to the low 16 bits and ECX/EDX should be zero.
Short of there being white listing in place just like on the HVM side,
also zap leaves 6, 9, and 0x8007 as well as unknown / reserved ones.
Signed-off
On 05/17/2018 04:08 PM, Boris Ostrovsky wrote:
On 05/17/2018 01:31 AM, Oleksandr Andrushchenko wrote:
I will go with the change you suggested and
I'll send v4 tomorrow then.
Please make sure your changes to kbdif.h are in Xen first. I believe you
submitted a patch there but I don't see it in
On 05/17/2018 01:31 AM, Oleksandr Andrushchenko wrote:
> I will go with the change you suggested and
> I'll send v4 tomorrow then.
Please make sure your changes to kbdif.h are in Xen first. I believe you
submitted a patch there but I don't see it in the staging tree yet.
-boris
___
On 17/05/18 14:33, Olaf Hering wrote:
> In the other thread about the unsolved migration bugs in qemu-xen it became
> clear that "xen-save-devices-state" must not only be called for HVM, but for
> every domU that has qemu-xen attached to it. I wonder how to check for that
> fact from the migrati
On Thu, May 17, 2018 at 12:16:55PM +0100, Ian Jackson wrote:
> Three more files which missed out on
> dea987c5ab11 "PERLLIB, @INC: Use BEGIN { }"
>
> Signed-off-by: Ian Jackson
Reviewed-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@lists
In the other thread about the unsolved migration bugs in qemu-xen it became
clear that "xen-save-devices-state" must not only be called for HVM, but for
every domU that has qemu-xen attached to it. I wonder how to check for that
fact from the migration code. While it can continue to rely on
LIB
Juergen Gross writes ("Re: [Xen-devel] [xen-unstable test] 122804: FAIL"):
> On 17/05/18 01:57, osstest service owner wrote:
> > Tests which are failing intermittently (not blocking):
> > test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail
> > pass in 122715
> > test-amd64-a
Marek Marczykowski-Górecki writes ("Test for osstest, features used in Qubes
OS"):
> As discussed some time ago, I'd like to help with adding tests for some
> features we use in Qubes OS.
>
> IMO the easiest thing to test is host suspend. You just need to execute
> "rtcwake -s 30 -m mem", and see
>>> On 16.05.18 at 19:27, wrote:
> c/s 62b187969 "x86: further CPUID handling adjustments" make some adjustments.
> However, it breaks levelling of guests, making it impossible for the toolstack
> to hide STIBP or IBPB from guests on hardware with up-to-date microcode.
>
> The dom0 issue referenc
>>> On 17.05.18 at 13:46, wrote:
> Nothing good will come of trying to formally support different MSR
> capabilities on different vcpus, because you won't find any hardware
> where you can do this in practice.
Thinking of it - allowing this would be a nice way to allow testing OS
code when meanin
>>> On 17.05.18 at 13:49, wrote:
> On 17/05/18 12:44, Jan Beulich wrote:
> On 17.05.18 at 11:48, wrote:
>>> The function is supposed to return whether the MTRR and PAT state of
>>> two CPUs match. Currently this is not properly done because the test
>>> for the deftype and the enable bits req
>>> On 17.05.18 at 13:46, wrote:
> Nothing good will come of trying to formally support different MSR
> capabilities on different vcpus, because you won't find any hardware
> where you can do this in practice.
I agree, but it's not really clear to me how you want to enforce identical
values yet a
On 17/05/18 12:44, Jan Beulich wrote:
On 17.05.18 at 11:48, wrote:
>> The function is supposed to return whether the MTRR and PAT state of
>> two CPUs match. Currently this is not properly done because the test
>> for the deftype and the enable bits required both the deftype and the
>> enable
On 17/05/18 12:33, Jan Beulich wrote:
On 17.05.18 at 13:10, wrote:
>> On Thu, May 17, 2018 at 04:44:04AM -0600, Jan Beulich wrote:
>> On 17.05.18 at 11:48, wrote:
The function is supposed to return whether the MTRR and PAT state of
two CPUs match. Currently this is not properly
>>> On 17.05.18 at 13:10, wrote:
> On Thu, May 17, 2018 at 04:44:04AM -0600, Jan Beulich wrote:
>> >>> On 17.05.18 at 11:48, wrote:
>> > The function is supposed to return whether the MTRR and PAT state of
>> > two CPUs match. Currently this is not properly done because the test
>> > for the deft
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 6d5e667..983bb17 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -2646,8 +2646,8 @@ menuentry 'lo
Three more files which missed out on
dea987c5ab11 "PERLLIB, @INC: Use BEGIN { }"
Signed-off-by: Ian Jackson
CC: Roger Pau Monné
---
mg-anoint | 2 +-
ts-examine-hostprops-save | 2 +-
ts-freebsd-host-install | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --gi
make-*-flight is going to want this.
Signed-off-by: Ian Jackson
CC: Roger Pau Monné
---
mg-anoint | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/mg-anoint b/mg-anoint
index 522cbdd..d09124b 100755
--- a/mg-anoint
+++ b/mg-anoint
@@ -15,10 +15,12 @@
#-
Logically, the final branch of the if should be qualified with a check
for the emptiness of FreeBSDDist. This is awkward in the current
structure, since we really want to do the distpath lookup only if
needed. (This is not very important right now, but we are about to
add another case which will
From: Ian Jackson
I am trying to commission some new hosts. These patches fix problems
I encountered. There are fixes to:
* Better support UEFI x86 hosts.
* Improve the commissioning instructions in README.dev.
* Handle the new FreeBSD anointments system in make-*-flight in
production (E
This makes them better for cutting-and-pasting.
Signed-off-by: Ian Jackson
---
README.dev | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/README.dev b/README.dev
index a2b93e0..441eee8 100644
--- a/README.dev
+++ b/README.dev
@@ -112,9 +112,10 @@ Firstly, a basic
This makes `mg-anoint' in standalone mode a view onto an empty set of
anointments. So now it becomes ok to call mg-anoint in make-*-flight.
Signed-off-by: Ian Jackson
CC: Roger Pau Monné
---
Osstest/JobDB/Executive.pm | 2 ++
Osstest/JobDB/Standalone.pm | 2 ++
mg-anoint |
This suppresses:
Partition disks
---
This machine's firmware has started the installer in UEFI mode but it looks
like there may be existing operating systems already installed using "BIOS
compatibility mode". If you continue to install Debian in UEFI mode, it might
b
Signed-off-by: Ian Jackson
---
README.dev | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/README.dev b/README.dev
index 95fc66c..0f7fccd 100644
--- a/README.dev
+++ b/README.dev
@@ -30,8 +30,8 @@ Keeps running for the duration, so run it in a screen on the
osstest VM.
This must occur before mknetbootdir, or mknetbootdir does not set
things up for UEFI booting.
Signed-off-by: Ian Jackson
---
README.dev | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/README.dev b/README.dev
index 0f7fccd..a2b93e0 100644
--- a/README.dev
+++ b/README.dev
Previously, `make-*-flight' would not work unless FREEBSD_*_BUILDJOB
was set. Now we use the anointed values if we can find them.
If we can't, mg-anoint retrieve will print a warning.
Signed-off-by: Ian Jackson
CC: Roger Pau Monné
---
mfi-common | 8
1 file changed, 8 insertions(+)
On Thu, May 17, 2018 at 04:44:04AM -0600, Jan Beulich wrote:
> >>> On 17.05.18 at 11:48, wrote:
> > The function is supposed to return whether the MTRR and PAT state of
> > two CPUs match. Currently this is not properly done because the test
> > for the deftype and the enable bits required both th
On Fri, May 04, 2018 at 08:26:07PM +0100, Paul Durrant wrote:
> Certain functions in xen_disk are called with a pointer to xendev
> (struct XenDevice *). They then use continer_of() to acces the surrounding
^ container_of
> blkdev (struct XenBlkDev) but then
On Fri, May 04, 2018 at 08:26:06PM +0100, Paul Durrant wrote:
> Since xen_disk now always copies data to and from a guest there is no need
> to maintain a vector entry corresponding to every page of a request.
> This means there is less per-request state to maintain so the ioreq
> structure can shr
>>> On 17.05.18 at 11:48, wrote:
> The function is supposed to return whether the MTRR and PAT state of
> two CPUs match. Currently this is not properly done because the test
> for the deftype and the enable bits required both the deftype and the
> enable bits to be different, while just one of th
On Fri, May 04, 2018 at 08:26:04PM +0100, Paul Durrant wrote:
> Now that the (native or emulated) xen_be_copy_grant_refs() helper is
> always available, the xen_disk code can be significantly simplified by
> removing direct use of grant map and unmap operations.
>
> Signed-off-by: Paul Durrant
A
1 - 100 of 112 matches
Mail list logo
