On 02/27/18 16:41 +, Anthony PERARD wrote:
> On Thu, Dec 07, 2017 at 06:18:05PM +0800, Haozhong Zhang wrote:
> > diff --git a/backends/hostmem.c b/backends/hostmem.c
> > index ee2c2d5bfd..ba13a52994 100644
> > --- a/backends/hostmem.c
> > +++ b/backends/hostmem.c
> > @@ -12,6 +12,7 @@
> > #inc
On 02/27/18 16:37 +, Anthony PERARD wrote:
> On Thu, Dec 07, 2017 at 06:18:04PM +0800, Haozhong Zhang wrote:
> > The guest physical address of vNVDIMM is allocated from the hotplug
> > memory region, which is not created when QEMU is used as Xen device
> > model. In order to use vNVDIMM for Xen
>>> On 27.02.18 at 18:27, wrote:
> Having finally got back to some CPUID work, I've come back to a naming
> problem I've been unable to resolve in the intervening time.
>
> Originally, the plan was to introduce XEN_SYSCTL_get_cpuid_policy and
> XEN_DOMCTL_{get,set}_cpuid_policy, which was shortly
flight 120053 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120053/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 120004
test-armhf-armhf-libvirt-raw 13 saveresto
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Tuesday, February 27, 2018 5:33 PM
>
> > -Original Message-
> [snip]
> > > I'll define some terms to try to avoid confusing...
> > >
> > > - where the IOMMU code in Xen maintains a map such that BFN == MFN,
> > > let’s call this
flight 120047 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120047/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 119891
test-amd64-amd64-xl-qemut-win7-amd64 17
On Tue, Feb 27, 2018 at 8:25 PM, Minjun Hong wrote:
>
> Ah! Now I understand what you said.
> Thank you so much, Andrew.
>
> BTW, isn't it possible to use PERFEVTSELx MSR in Xen directly? I eagerly want
> to achieve the number of cache-misses.
If you just want to monitor the number of cache mis
Ah! Now I understand what you said.
Thank you so much, Andrew.
BTW, isn't it possible to use PERFEVTSELx MSR in Xen directly? I eagerly
want to achieve the number of cache-misses.
On Tue, Feb 27, 2018 at 11:03 PM, Andrew Cooper
wrote:
> On 27/02/18 12:35, Minjun Hong wrote:
>
> On Tue, Feb 27,
Regards, Peter
http://ri.mu Startups start here. Hosting. DNS. Offsite backups.
Monitoring. Email.
On 27/02/18 12:42 AM, Juergen Gross wrote:
On 22/02/18 21:38, x...@randomwebstuff.com wrote:
On 22/02/18 6:35 PM, Juergen Gross wrote:
On 22/02/18 05:37, x...@randomwebstuff.com wrote:
Hi
flight 120078 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120078/
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
flight 120043 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120043/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a
test-arm64-arm64-libvirt-xsm 1 build-check
On Tue, 27 Feb 2018, Boris Ostrovsky wrote:
> On 02/27/2018 04:32 PM, Stefano Stabellini wrote:
> > On Tue, 27 Feb 2018, Boris Ostrovsky wrote:
> >> On 02/27/2018 02:54 PM, Stefano Stabellini wrote:
> >>> We are using test_and_* operations on the status and flag fields of
> >>> struct sock_mapping.
On 02/27/2018 04:32 PM, Stefano Stabellini wrote:
> On Tue, 27 Feb 2018, Boris Ostrovsky wrote:
>> On 02/27/2018 02:54 PM, Stefano Stabellini wrote:
>>> We are using test_and_* operations on the status and flag fields of
>>> struct sock_mapping. However, these functions require the operand to be
>>
On Tue, 27 Feb 2018, Boris Ostrovsky wrote:
> On 02/27/2018 02:54 PM, Stefano Stabellini wrote:
> > We are using test_and_* operations on the status and flag fields of
> > struct sock_mapping. However, these functions require the operand to be
> > 64-bit aligned on arm64. Currently, only status is
Add pvcalls support to libxl and xl. Create the appropriate pvcalls
entries in xenstore.
Signed-off-by: Stefano Stabellini
diff --git a/docs/misc/xenstore-paths.markdown
b/docs/misc/xenstore-paths.markdown
index 7be2592..77d1a36 100644
--- a/docs/misc/xenstore-paths.markdown
+++ b/docs/misc/xen
On 02/27/2018 02:54 PM, Stefano Stabellini wrote:
> We are using test_and_* operations on the status and flag fields of
> struct sock_mapping. However, these functions require the operand to be
> 64-bit aligned on arm64. Currently, only status is 64-bit aligned.
>
> Make flags 64-bit aligned by int
flight 120038 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120038/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail in 120002 REGR. vs.
115539
Tests which are fa
flight 120037 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120037/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail pass in
120001
Tests which did not succeed
Hi,
On 27/02/2018 20:03, Stefano Stabellini wrote:
On Tue, 27 Feb 2018, Julien Grall wrote:
Hi,
On 26/02/18 12:32, Juergen Gross wrote:
On 26/02/18 13:06, Andrii Anisov wrote:
Hello Juergen,
On 26.02.18 13:08, Juergen Gross wrote:
Today the hvc console is added as a preferred console for
On Tue, 27 Feb 2018, Julien Grall wrote:
> Hi,
>
> On 26/02/18 12:32, Juergen Gross wrote:
> > On 26/02/18 13:06, Andrii Anisov wrote:
> > > Hello Juergen,
> > >
> > >
> > > On 26.02.18 13:08, Juergen Gross wrote:
> > > > Today the hvc console is added as a preferred console for pv domUs
> > > >
On 27/02/18 19:18, Julien Grall wrote:
> Hi,
>
> On Arm, we made the (wrong?) assumption that the rwlock was recursive.
> We have a couple of places where the read lock can be nested (mostly
> the memaccess code).
>
> I found out today that it can actually deadlock in the following case:
> 1) C
We are using test_and_* operations on the status and flag fields of
struct sock_mapping. However, these functions require the operand to be
64-bit aligned on arm64. Currently, only status is 64-bit aligned.
Make flags 64-bit aligned by introducing an explicit padding field.
Signed-off-by: Stefano
Hi,
On Arm, we made the (wrong?) assumption that the rwlock was recursive.
We have a couple of places where the read lock can be nested (mostly the
memaccess code).
I found out today that it can actually deadlock in the following case:
1) CPU A -> Ask for the read lock
flight 120071 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120071/
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, Dec 07, 2017 at 06:10:22PM +0800, Haozhong Zhang wrote:
> diff --git a/tools/libacpi/qemu_fw_cfg.c b/tools/libacpi/qemu_fw_cfg.c
> new file mode 100644
> index 00..254d2f575d
> --- /dev/null
> +++ b/tools/libacpi/qemu_fw_cfg.c
> @@ -0,0 +1,66 @@
> +/*
> + * libacpi/qemu_fw_cfg.c
> +
On Thu, Dec 07, 2017 at 06:10:23PM +0800, Haozhong Zhang wrote:
> Probe following QEMU ACPI ROMs:
> * etc/acpi/rsdp: QEMU RSDP, which is used to iterate other
> QEMU ACPI tables in etc/acpi/tables
>
> * etc/acpi/tables: other QEMU ACPI tables
>
> * etc/table-l
On 02/23/2018 04:41 PM, Dario Faggioli wrote:
> Basically, instead of converting integers to s_time_t
> at usage time (hot paths), do the convertion when the
> values are set (cold paths).
>
> This applies to the timeslice and the ratelimit
> parameters of Credit1.
>
> Note that, when changing th
On Thu, Dec 07, 2017 at 06:10:22PM +0800, Haozhong Zhang wrote:
> Add a function in libacpi to detect QEMU fw_cfg interface. Limit the
> usage of fw_cfg interface to hvmloader now, so use stub functions for
> others.
I think libacpi is not the right place for a driver. The fw_cfg driver
would be b
On Di, 2018-02-27 at 17:07 +, Roger Pau Monné wrote:
> On Tue, Feb 27, 2018 at 03:55:58PM +, Amit Shah wrote:
> >
> > In case of errors in irq setup for MSI, free up the allocated irqs.
> >
> > Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups")
> > Reported-by: Hooman Mirh
All,
Having finally got back to some CPUID work, I've come back to a naming
problem I've been unable to resolve in the intervening time.
Originally, the plan was to introduce XEN_SYSCTL_get_cpuid_policy and
XEN_DOMCTL_{get,set}_cpuid_policy, which was shortly followed by similar
MSR policy calls.
On Thu, Dec 07, 2017 at 06:18:02PM +0800, Haozhong Zhang wrote:
> This is the QEMU part patches that works with the associated Xen
> patches to enable vNVDIMM support for Xen HVM domains. Xen relies on
> QEMU to build guest NFIT and NVDIMM namespace devices, and allocate
> guest address space for v
On Tue, Feb 27, 2018 at 03:55:58PM +, Amit Shah wrote:
> In case of errors in irq setup for MSI, free up the allocated irqs.
>
> Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups")
> Reported-by: Hooman Mirhadi
> CC:
> CC: Roger Pau Monné
> CC: Boris Ostrovsky
> CC: Eduardo V
Boris Ostrovsky:
> On 02/07/2018 06:49 PM, Prarit Bhargava wrote:
>> The kernel panics on PV domains because native_smp_cpus_done() is
>> only called for HVM domains.
>>
>> Calculate __max_logical_packages for PV domains.
>>
>> Fixes: b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages estimate"
Hi,
On 19/02/18 12:34, Julien Grall wrote:
> Hi,
>
> On 09/02/18 14:39, Andre Przywara wrote:
>> The Xen core code requires an interrupt controller emulation to implement
>> arch_move_irqs(), to move the affinity of an hardware mapped virtual IRQ
>> to another core. In the moment we don't impleme
On 02/27/2018 06:26 PM, George Dunlap wrote:
>>> As an aside -- are you sure clearing the NOFLUSH from reported CR3
>>> values during introspection is the right thing to do? You don't think
>>> your introspection engine will ever want to know if the guest OS is
>>> setting this bit?
>>
>> We can't
On Tue, Feb 27, 2018 at 03:55:57PM +, Amit Shah wrote:
> When an MSI descriptor was not available, the error path would try to
> unbind an irq that was never acquired - potentially unbinding an
> unrelated irq.
Those IRQs have been allocated in the xen_allocate_irqs_dynamic call,
so I think th
On Thu, Dec 07, 2017 at 06:18:07PM +0800, Haozhong Zhang wrote:
> Xen is going to reuse QEMU to build ACPI of some devices (e.g., NFIT
> and SSDT for NVDIMM) for HVM domains. The existing QEMU ACPI build
> code requires a fw_cfg interface which will also be used to pass QEMU
> built ACPI to Xen. Th
On 27/02/18 16:38, Jan Beulich wrote:
On 27.02.18 at 17:28, wrote:
>> Instead of printing REZ, use NULL pointers to indicate missing information,
>> and have dump_leaf() print out the bit which is unknown.
>>
>> E.g.
>>
>>
>> Dynamic sets:
>> Raw
>> 178bfbff:fed832
On Thu, Dec 07, 2017 at 06:18:05PM +0800, Haozhong Zhang wrote:
> diff --git a/backends/hostmem.c b/backends/hostmem.c
> index ee2c2d5bfd..ba13a52994 100644
> --- a/backends/hostmem.c
> +++ b/backends/hostmem.c
> @@ -12,6 +12,7 @@
> #include "qemu/osdep.h"
> #include "sysemu/hostmem.h"
> #includ
>>> On 27.02.18 at 17:28, wrote:
> Instead of printing REZ, use NULL pointers to indicate missing information,
> and have dump_leaf() print out the bit which is unknown.
>
> E.g.
>
>
> Dynamic sets:
> Raw
> 178bfbff:fed8320b:2fd3fbff:35c233ff:000f:209c01a9:000
On Thu, Dec 07, 2017 at 06:18:04PM +0800, Haozhong Zhang wrote:
> The guest physical address of vNVDIMM is allocated from the hotplug
> memory region, which is not created when QEMU is used as Xen device
> model. In order to use vNVDIMM for Xen HVM domains, this commit reuses
> the code for pc mach
flight 120066 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120066/
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
Instead of printing REZ, use NULL pointers to indicate missing information,
and have dump_leaf() print out the bit which is unknown.
E.g.
Dynamic sets:
Raw
178bfbff:fed8320b:2fd3fbff:35c233ff:000f:209c01a9::6799:1007:
[00] 0x0001.edx
On 02/27/2018 04:19 PM, Razvan Cojocaru wrote:
> On 02/27/2018 05:53 PM, George Dunlap wrote:
>> On 02/23/2018 07:29 AM, Razvan Cojocaru wrote:
>>> On 02/23/2018 06:53 AM, Tian, Kevin wrote:
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Friday, February 16, 2018 6:22 PM
flight 120040 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120040/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f068aa038d09053c5dddea93c5f9576c51993546
baseline version:
ovmf ebfca258f5d7ab59cd1b7
On 02/27/2018 05:53 PM, George Dunlap wrote:
> On 02/23/2018 07:29 AM, Razvan Cojocaru wrote:
>> On 02/23/2018 06:53 AM, Tian, Kevin wrote:
From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
Sent: Friday, February 16, 2018 6:22 PM
The emulation layers of Xen lack PCID supp
Jan Beulich writes ("libxc backport request"):
> in the context of the migration related changes for Spectre v2 I think
> it becomes necessary to backport
>
> 72efb1df62 tools/libxc: Avoid generating inappropriate zero-content records
> f1a0a8c3fe tools/libxc: Fix restoration of PV MSRs after migr
Hello,
These bugs were found during code review. Details in the commits.
Please review and apply.
v2:
- fix up patch 2 properly (Roger Pau Monné)
CC: Roger Pau Monné
CC: Boris Ostrovsky
CC: Eduardo Valentin
CC: Juergen Gross
CC: Thomas Gleixner
CC: "K. Y. Srinivasan"
CC: Liu Shuo
CC: A
When an MSI descriptor was not available, the error path would try to
unbind an irq that was never acquired - potentially unbinding an
unrelated irq.
Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups")
Reported-by: Hooman Mirhadi
CC:
CC: Roger Pau Monné
CC: Boris Ostrovsky
CC: Ed
In case of errors in irq setup for MSI, free up the allocated irqs.
Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups")
Reported-by: Hooman Mirhadi
CC:
CC: Roger Pau Monné
CC: Boris Ostrovsky
CC: Eduardo Valentin
CC: Juergen Gross
CC: Thomas Gleixner
CC: "K. Y. Srinivasan"
CC
On 02/23/2018 07:29 AM, Razvan Cojocaru wrote:
> On 02/23/2018 06:53 AM, Tian, Kevin wrote:
>>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
>>> Sent: Friday, February 16, 2018 6:22 PM
>>>
>>> The emulation layers of Xen lack PCID support, and as we only offer
>>> PCID to HAP guests, al
On Di, 2018-02-27 at 08:14 +, Roger Pau Monné wrote:
> On Mon, Feb 26, 2018 at 06:57:03PM +, Shah, Amit wrote:
> >
> >
> > On Mo, 2018-02-26 at 18:14 +, Roger Pau Monné wrote:
> > >
> > > On Mon, Feb 26, 2018 at 05:36:35PM +, Amit Shah wrote:
> > > >
> > > >
> > > > In case o
Ian,
in the context of the migration related changes for Spectre v2 I think
it becomes necessary to backport
72efb1df62 tools/libxc: Avoid generating inappropriate zero-content records
f1a0a8c3fe tools/libxc: Fix restoration of PV MSRs after migrate
to applicable trees. The lack of the former is
From: Stewart Hildebrand
Since commit "xen/arm: domain_build: Rework the way to allocate the
event channel interrupt", it is not possible for an irq to be both below 16
and greater/equal than 32.
Also fix the reference to linux documentation while we're at it.
Signed-off-by: Stewart Hildebrand
From: Julien Grall
At the moment, a placeholder will be created in the device-tree for the
event channel information. Later in the domain construction, the
interrupt for the event channel upcall will be allocated the device-tree
fixed up.
Looking at the code, the current split is not necessary b
On Mon, Feb 26, 2018 at 05:35:19PM +, Andrew Cooper wrote:
> The main purpose is to blacklist the Intel Resource Director Technology MSRs.
> We do not yet virtualise support for guests, but Linux has been observed to
> probe for these MSRs without checking CPUID first.
>
> The architecturally
From: Julien Grall
A follow-up patch will require to have all interrupts routed to the
hardware registered before calling prepare_dtb/prepare_acpi.
At the moment, it is not necessary to call platform specific mappings
(gic and platform) after, so it is fine to move them.
Signed-off-by: Julien G
From: Julien Grall
Hi all,
This patch series was triggered by commit 11e7dd958d "xen/arm: domain_builder:
irq sanity check logic fix" that is valid but break some assumption in the
current Xen. Rather than removing a useful BUG_ON(), this series rework
the event channel IRQ allocation for the ha
On 27/02/18 15:00, Andrew Cooper wrote:
> On 27/02/18 14:51, Jan Beulich wrote:
>> ---
>> This is what is currently breaking save/restore on the 4.8 branch; I
>> haven't checked yet why the sending side produces an empty record there.
>> I wonder whether that's related to f1a0a8c3fe ("tools/libxc:
On 02/27/2018 05:19 AM, Juergen Gross wrote:
> Today the tty0 and hvc0 consoles are added as a preferred consoles for
> pv domUs only. As this requires a boot parameter for getting dom0
> messages per default, add them for dom0, too.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On Mon, Feb 26, 2018 at 05:35:18PM +, Andrew Cooper wrote:
> Dispatch from the guest_{rd,wr}msr() functions. The read side should be safe
> outside of current context, but the write side is definitely not. As the
> toolstack has plausible reason to access the APIC registers via this interface
On 27/02/18 14:51, Jan Beulich wrote:
> Commit 119ee4d773 ("tools/libxc: Tolerate specific zero-content records
> in migration v2 streams") meant tolerate those, but failed to set rc
> accordingly.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
> ---
> This is what is currently break
On 02/26/2018 01:11 PM, Chao Gao wrote:
> On Mon, Feb 26, 2018 at 01:26:42AM -0700, Jan Beulich wrote:
> On 23.02.18 at 19:11, wrote:
>>> On Wed, Dec 06, 2017 at 03:50:14PM +0800, Chao Gao wrote:
Signed-off-by: Chao Gao
---
xen/include/public/hvm/hvm_info_table.h | 2 +-
The correct way to check a boolean is `cmpb $0` or `testb $0xff`, whereas a
lot of our entry code uses `testb $1`. This will work in principle for values
which are really C _Bool types, but won't work for other integer types which
are intended to have boolean properties.
cmp is the more logical w
The clobbering of TRAPBOUNCE_flags in .L{compat_}bounce_exception is subsumed
by the logic at the end of pv_create_bounce_frame().
This cleanup removes all callers of asm_domain_crash_synchronous(), which is
therefore dropped as well.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
Commit 119ee4d773 ("tools/libxc: Tolerate specific zero-content records
in migration v2 streams") meant tolerate those, but failed to set rc
accordingly.
Signed-off-by: Jan Beulich
---
This is what is currently breaking save/restore on the 4.8 branch; I
haven't checked yet why the sending side pr
This has finally undergone performance testing. No measureable difference in
any lmbench test on either 32 or 64bit PV guests.
Andrew Cooper (5):
x86/entry: Correct comparisons against boolean variables
x86/pv: Drop int80_bounce from struct pv_vcpu
x86/pv: Introduce pv_create_exception_fram
Reintroduce TBF_FAILSAFE and update pv_create_exception_frame() to cope with
the additional data segment registers.
load_segments() now fills in trap_bounce, and lets the general return-to-guest
path inject the exception.
Bloat-o-meter reports:
add/remove: 0/0 grow/shrink: 1/1 up/down: 123/-252
This is a C implementation of {compat_,}create_bounce_frame(), based loosely
on the existing failsafe implementation in load_segments(). It picks up all
injection information from the trap_bounce structure.
One minor improvement is that at no point is regs->cs left with an rpl of 0 on
the root st
The int80_bounce field of struct pv_vcpu is a bit of an odd special case,
because it is a simple derivation of trap_ctxt[0x80], which is also stored.
It is also the only use of {compat_,}create_bounce_frame() which isn't
referencing the plain trap_bounce field of struct pv_vcpu. (And altering thi
On Wednesday, 28 February 2018 1:36:14 AM AEDT George Dunlap wrote:
> On 02/27/2018 02:22 PM, Jan Beulich wrote:
> On 27.02.18 at 13:37, wrote:
> >> On Tuesday, 27 February 2018 11:00:08 PM AEDT Xen. org security team
wrote:
> >>> RESOLUTION
> >>> ==
> >>>
> >>> Applying the appropr
flight 120030 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120030/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386broken in 119953
test-amd64-i386-migrupgrade
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 26 February 2018 17:35
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Jun Nakajima ; Paul
> Durrant ; Kevin Tian ; Boris
> Ostrovsky ; Suravee Suthikulpanit
> ; Wei Liu ; Roger
> Pau Monne ; Sergey
On 02/27/2018 02:22 PM, Jan Beulich wrote:
On 27.02.18 at 13:37, wrote:
>> On Tuesday, 27 February 2018 11:00:08 PM AEDT Xen. org security team wrote:
>>> RESOLUTION
>>> ==
>>>
>>> Applying the appropriate attached patch resolves this issue.
>>>
>>> xsa255-?.patch xen-unstable
On Mon, Feb 26, 2018 at 05:35:17PM +, Andrew Cooper wrote:
> This is in preparation to make hvm_x2apic_msr_read() take a const vcpu
> pointer. One modification is to alter vlapic_get_tmcct() to not use current.
>
> This in turn needs an alteration to hvm_get_guest_time_fixed(), which is safe
On 27/02/18 13:54, Andre Przywara wrote:
Hi,
On 19/02/18 14:13, Julien Grall wrote:
On 19/02/18 12:41, Andre Przywara wrote:
Hi,
Hi,
On 16/02/18 16:57, Julien Grall wrote:
On 09/02/18 14:39, Andre Przywara wrote:
+ spin_lock_irqsave(&desc->lock, flags);
+ if ( enable )
+ {
+
On Mon, Feb 26, 2018 at 05:35:16PM +, Andrew Cooper wrote:
> Dispatch from the guest_{rd,wr}msr() functions, after falling through from the
> !is_viridian_domain() case.
>
> Rename {rd,wr}msr_hypervisor_regs() to guest_{rd,wr}msr_xen() for consistency,
> and because the _regs suffix isn't very
>>> On 27.02.18 at 12:38, wrote:
> This patch was originally released as part of XSA-226. It retains the same
> command line syntax (as various downstreams are mitigating XSA-226 using this
> mechanism) but the defaults have been updated due to the revised XSA-226
> patched, after which transitiv
>>> On 27.02.18 at 13:37, wrote:
> On Tuesday, 27 February 2018 11:00:08 PM AEDT Xen. org security team wrote:
>> RESOLUTION
>> ==
>>
>> Applying the appropriate attached patch resolves this issue.
>>
>> xsa255-?.patch xen-unstable, Xen 4.10.x
>> xsa255-4.9-?.patch Xen 4.9.x,
On 12/06/2017 07:50 AM, Chao Gao wrote:
> Each vcpu of hvm guest consumes at least one shadow page. Currently, only 256
> (for hap case) pages are pre-allocated as shadow memory at beginning. It would
> run out if guest has more than 256 vcpus and guest creation fails. Bump the
> number of shadow p
On Mon, Feb 26, 2018 at 05:35:15PM +, Andrew Cooper wrote:
> Dispatch from the guest_{rd,wr}msr() functions, after confirming that the
> domain is configured to use viridian. This allows for simplifiction of the
> viridian helpers as they don't need to cope with the "not a viridian MSR"
> case
>>> On 27.02.18 at 12:57, wrote:
> On Tue, Feb 27, 2018 at 03:01:44AM -0700, Jan Beulich wrote:
>> >>> On 27.02.18 at 10:21, wrote:
>> > With the current approach in the unmap case there will be stale
>> > mappings left behind.
>> >
>> > I guess it's better then to not modify the memory decoding
On 02/27/2018 03:39 AM, Jan Beulich wrote:
On 23.02.18 at 08:55, wrote:
> On 22.02.18 at 23:16, wrote:
>>> On 02/22/2018 10:44 AM, Jan Beulich wrote:
>>> On 22.02.18 at 15:53, wrote:
> On 22/02/18 13:44, Jan Beulich wrote:
>> ... for unknown MSRs: wrmsr_hypervisor_regs()'s c
On 27/02/18 12:35, Minjun Hong wrote:
> On Tue, Feb 27, 2018 at 7:00 PM, Andrew Cooper
> mailto:andrew.coop...@citrix.com>> wrote:
>
> On 27/02/2018 09:37, Minjun Hong wrote:
>> Hello, I've tried to read msr in hypervisor code:
>>
>> uint64_t reg;
>>
>> rdmsr_safe(0x412e,
flight 120058 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120058/
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
Hi,
On 19/02/18 14:13, Julien Grall wrote:
>
>
> On 19/02/18 12:41, Andre Przywara wrote:
>> Hi,
>
> Hi,
>
>> On 16/02/18 16:57, Julien Grall wrote:
>>> On 09/02/18 14:39, Andre Przywara wrote:
+ spin_lock_irqsave(&desc->lock, flags);
+ if ( enable )
+ {
+ g
On Tue, Feb 27, 2018 at 12:43:21PM +, Roger Pau Monné wrote:
> On Mon, Feb 26, 2018 at 05:35:14PM +, Andrew Cooper wrote:
> > The default case of vmx_msr_write_intercept() in particular is very tangled.
> >
> > First of all, fold long_mode_do_msr_{read,write}() into their callers.
> > Th
On 27/02/18 12:43, Roger Pau Monné wrote:
> On Mon, Feb 26, 2018 at 05:35:14PM +, Andrew Cooper wrote:
>> The default case of vmx_msr_write_intercept() in particular is very tangled.
>>
>> First of all, fold long_mode_do_msr_{read,write}() into their callers. These
>> functions were split out
flight 120035 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120035/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
test-amd64-amd64-qemuu-nested-intel 17
On Tuesday, 27 February 2018 11:00:08 PM AEDT Xen. org security team wrote:
> Xen Security Advisory XSA-255
> version 3
>
> grant table v2 -> v1 transition may crash Xen
>
> RESOLUTION
> ==
>
> Applying the appropriate attac
On Mon, Feb 26, 2018 at 05:35:14PM +, Andrew Cooper wrote:
> The default case of vmx_msr_write_intercept() in particular is very tangled.
>
> First of all, fold long_mode_do_msr_{read,write}() into their callers. These
> functions were split out in the past because of the 32bit build of Xen,
Please find some more clarifications on VirtIO use with Xen
(I would like to thank Xen community for helping with this)
1. Possible security issues - VirtIO devices are PCI bus masters, thus
allowing real device (running, for example, in untrusted driver domain)
to get control over guest's memory
On Tue, Feb 27, 2018 at 7:00 PM, Andrew Cooper
wrote:
> On 27/02/2018 09:37, Minjun Hong wrote:
>
> Hello, I've tried to read msr in hypervisor code:
>
> uint64_t reg;
>
> rdmsr_safe(0x412e, ret);
>
>
> But, I all failed to read it because the hypervisor is running in ring-1
> CPL as I did googli
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-255
version 3
grant table v2 -> v1 transition may crash Xen
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
Gr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-252
version 2
DoS via non-preemptable L3/L4 pagetable freeing
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-256
version 2
x86 PVH guest without LAPIC may DoS the host
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
=
So
On Tue, Feb 27, 2018 at 03:01:44AM -0700, Jan Beulich wrote:
> >>> On 27.02.18 at 10:21, wrote:
> > On Tue, Feb 27, 2018 at 01:32:24AM -0700, Jan Beulich wrote:
> >> >>> On 26.02.18 at 19:00, wrote:
> >> > On Mon, Feb 26, 2018 at 04:20:17AM -0700, Jan Beulich wrote:
> >> >> >>> On 23.01.18 at 16:
This patch was originally released as part of XSA-226. It retains the same
command line syntax (as various downstreams are mitigating XSA-226 using this
mechanism) but the defaults have been updated due to the revised XSA-226
patched, after which transitive grants are believed to functioning
prope
We don't know what is the state of the TLBs when booting Xen. To avoid
stale entries, it is necessary to flush the TLBs before turning on the
MMU.
Reported-by: Iain Hunter
Signed-off-by: Julien Grall
---
xen/arch/arm/arm32/head.S | 7 +++
xen/arch/arm/arm64/head.S | 7 +++
2 files chang
Hi,
On 26/02/18 12:32, Juergen Gross wrote:
On 26/02/18 13:06, Andrii Anisov wrote:
Hello Juergen,
On 26.02.18 13:08, Juergen Gross wrote:
Today the hvc console is added as a preferred console for pv domUs
only. As this requires a boot parameter for getting dom0 messages per
default add it f
1 - 100 of 119 matches
Mail list logo
