Hi Guys, lately, I have been trying to play with Xen Driver Domain. I
have been able to make it work where both the Driver Domain OS and
the guest OS are run on paravirtualized (PV) machine. However, it
doesn't work when any of them are hardware virtualized machine (HVM).
Therefore, I have the fo
Hi Guys,
Lately, I have been trying to play with Xen Driver Domain. I have been able to
make it work where both the Driver Domain OS and the guest OS are run on
paravirtualized (PV) machine. However, it doesn't work when any of them are
hardware virtualized machine (HVM). Therefore, I have the
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, February 23, 2019 3:13 AM
>
> The sole remaining member of struct intel_iommu is the drhd backpointer.
> Move
> this into struct vtd_iommu, replacing the the 'intel' pointer.
>
> This removes one dynamic memory allocation
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, February 23, 2019 3:13 AM
>
> It is unclear why this abstraction exists, but iommu_get_flush() returns
> possibly NULL and every user unconditionally dereferences the result. In
> practice, I can't spot a path where iommu
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, February 25, 2019 7:01 PM
>
> >>> On 25.02.19 at 11:09, wrote:
> >> -Original Message-
> > [snip]
> >> struct iommu_flush {
> >> int __must_check (*context)(void *iommu, u16 did, u16 source_id,
> >>
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, February 23, 2019 3:13 AM
>
> It is unclear why this abstraction exists, but iommu_qi_ctrl() returns
> possibly NULL and every user unconditionally dereferences the result. In
> practice, I can't spot a path where iommu is
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, February 23, 2019 3:13 AM
>
> VT-d's local struct iommu is an overly-generic name, for a structure which in
> practice maps 1-to-1 with the real IOMMUs in the system.
>
> Additionally, address style issues on impacted line
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Saturday, February 23, 2019 3:13 AM
>
> iremap_maddr and qinval_maddr point to the base of a block of contiguous
> RAM,
> allocated by the driver, holding the Interrupt Remapping table, and the
> Queued
> Invalidation ring.
>
> Desp
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, February 20, 2019 6:19 AM
>
> Modificaitons to an altp2m mark the p2m as needing flushing, but this was
Modifications
> never wired up in the return-to-guest path. As a result, stale TLB entries
> can remain after resum
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, February 22, 2019 4:19 AM
>
> The logic in altp2m_vcpu_{en,dis}able_ve() and
> vmx_vcpu_update_vmfunc_ve() is
> dangerous. After #VE has been set up, the guest can balloon out and free the
> nominated GFN, after which the pr
flight 133435 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133435/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev broken
build-amd64-xsm
flight 133459 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133459/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8b8d6f8a3beea391b1ec39ac347ef69501b44019
baseline version:
ovmf c417c1b33d06ef6ae96ad
flight 133433 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133433/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-arm64
Zero-copy callback flag is not yet set on frag list skb at the moment
xenvif_handle_frag_list() returns -ENOMEM. This eventually results in
leaking grant ref mappings since xenvif_zerocopy_callback() is never
called for these fragments. Those eventually build up and cause Xen
to kill Dom0 as the sl
flight 133431 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133431/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops broken
test-arm64-arm64-xl-credit1
flight 133429 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133429/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win10-i386 broken
test-amd64-amd64-xl
On Wed, 27 Feb 2019, Jan Beulich wrote:
> >>> On 26.02.19 at 19:43, wrote:
> > On Tue, 26 Feb 2019, Ian Jackson wrote:
> >> Jan Beulich writes ("Re: [PATCH v10 2/6] xen: introduce DEFINE_SYMBOL"):
> >> > On 26.02.19 at 17:46, wrote:
> >> > > I am not aware of a standard C type which could be used
On Wed, 27 Feb 2019, Lars Kurth wrote:
> > On 27 Feb 2019, at 10:16, Jan Beulich wrote:
> >
> On 27.02.19 at 10:23, wrote:
> >>
> >> I recall that I read in an earlier thread that Julien and Stefano have
> >> access to the document, which would leave Jan and a few members of Citrix
> >>
flight 133418 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133418/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-3 broken
test-amd64-amd64-xl-qemut-ws16-amd64
Hi Stefano,
On 2/26/19 11:07 PM, Stefano Stabellini wrote:
struct xen_domctl_memory_mapping {
uint64_aligned_t first_gfn; /* first page (hvm guest phys page) in range
*/
uint64_aligned_t first_mfn; /* first page (machine page) in range */
uint64_aligned_t nr_mfns; /* numbe
flight 133428 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133428/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf-pvops
Hi, Amit
BTW, we use mkimage tool to create Xen image to be loaded:
mkimage -A arm64 -C none -T kernel -a 0x7808 -e 0x7808 -n
"XEN" xen/xen xen-uImage
I am sorry, I had missed "-d" key before xen image.
The proper command is:
mkimage -A arm64 -C none -T kernel -a 0x7808 -e
Hi Stefano,
On 2/26/19 11:07 PM, Stefano Stabellini wrote:
Parse a new cacheability option for the iomem parameter, it can be
"devmem" for device memory mappings, which is the default, or "memory"
for normal memory mappings.
Store the parameter in a new field in libxl_iomem_range.
Pass the cac
Hi Stefano,
On 2/26/19 11:07 PM, Stefano Stabellini wrote:
Reuse the existing padding field to pass cacheability information about
the memory mapping, specifically, whether the memory should be mapped as
normal memory or as device memory (this is what we have today).
Add a cacheability paramete
.snip..
> > -u64 drm_get_max_iomem(void)
> > +bool drm_need_swiotlb(int dma_bits)
> > {
> > struct resource *tmp;
> > resource_size_t max_iomem = 0;
> >
> > + /*
> > +* Xen paravirtual hosts require swiotlb regardless of requested dma
> > +* transfer size.
> > +*
> > +*
On Tue, Feb 19, 2019 at 09:30:33PM -0800, 'Ira Weiny' wrote:
> From: Ira Weiny
>
> Resending these as I had only 1 minor comment which I believe we have covered
> in this series. I was anticipating these going through the mm tree as they
> depend on a cleanup patch there and the IB changes are v
Hi Wei,
On 2/27/19 12:55 PM, Wei Liu wrote:
On Tue, Feb 26, 2019 at 11:03:51PM +, Julien Grall wrote:
After upgrading Debian to Buster, I started noticing console mangling
when using zsh. This is happenning because output sent by zsh to the
console may contain NUL character in the middle of
flight 133445 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133445/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvopsbroken
build-i386-pvops
flight 133420 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133420/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd broken
test-amd64-amd64-xl-pvhv2-amd
On 2/27/19 7:47 AM, Wei Liu wrote:
> On Mon, Feb 25, 2019 at 08:23:58PM +, Woods, Brian wrote:
>> Some AMD processors can use a mixture of mwait and halt for accessing
>> various c-states. In preparation for adding support for AMD processors,
>> update the mwait-idle driver to optionally use h
Hi all,
looking through the list of GSoC orgs, the following orgs that sometimes have
Xen related projects have been accepted into GSoC this year:
* https://wiki.freebsd.org/SummerOfCodeIdeas
* https://gsoc.honeynet.org/
* https://elinux.org/BeagleBoard/GSoC/Ideas [there is a Xen specific proposa
> On 27 Feb 2019, at 10:16, Jan Beulich wrote:
>
On 27.02.19 at 10:23, wrote:
>>
>> I recall that I read in an earlier thread that Julien and Stefano have
>> access to the document, which would leave Jan and a few members of Citrix
>> staff. Can those committers who need access raise t
On 2/27/19 12:46 PM, Ian Jackson wrote:
The Release file is out of date on our mirror, due to jessie's
retirement into LTS.
CC: Juergen Gross
Signed-off-by: Ian Jackson
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-deve
On 2/27/19 11:46 AM, Andrew Cooper wrote:
On 27/02/2019 10:33, Christian Lindig wrote:
Don't close stdin in daemonize() but dup2 /dev/null instead. This avoids
fd 0 being reused and potentially written to.
Signed-off-by: Christian Lindig
Possibly worth noting that this fixes a bug whereby /d
On 2/27/19 2:51 AM, Jan Beulich wrote:
On 26.02.19 at 17:54, wrote:
>> On 2/26/19 10:37 AM, Jan Beulich wrote:
>> On 26.02.19 at 17:25, wrote:
Correct me if I'm wrong, but the Xen's acpi-idle implementation is
dependent on dom0 using a AML interpreter and then giving that data
flight 133457 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133457/
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
The params array in hvm can be accessed with get and set functions.
As the index is guest controlled, make sure no out-of-bound accesses
can be performed.
As we cannot influence how future compilers might modify the
instructions that enforce the bounds, we furthermore block speculation,
so that th
The get_page_from_gfn method returns a pointer to a page that belongs
to a gfn. Before returning the pointer, the gfn is checked for being
valid. Under speculation, these checks can be bypassed, so that
the function get_page is still executed partially. Consequently, the
function page_get_owner_and
Guests can issue grant table operations and provide guest controlled
data to them. This data is also used for memory loads. To avoid
speculative out-of-bound accesses, we use the array_index_nospec macro
where applicable. However, there are also memory accesses that cannot
be protected by a single
When checking for being an hvm domain, or PV domain, we have to make
sure that speculation cannot bypass that check, and eventually access
data that should not end up in cache for the current domain type.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Acked-by:
Checks of domain properties, such as is_hardware_domain or is_hvm_domain,
might be bypassed by speculatively executing these instructions. A reason
for bypassing these checks is that these macros access the domain
structure via a pointer, and check a certain field. Since this memory
access is slow,
Since the L1TF vulnerability of Intel CPUs, loading hypervisor data into
L1 cache is problematic, because when hyperthreading is used as well, a
guest running on the sibling core can leak this potentially secret data.
To prevent these speculative accesses, we block speculation after
accessing the
To control the runtime behavior on L1TF vulnerable platforms better, the
command line option l1tf-barrier is introduced. This option controls
whether on vulnerable x86 platforms the lfence instruction is used to
prevent speculative execution from bypassing the evaluation of
conditionals that are pr
This patch series attempts to mitigate the issue that have been raised in the
XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
execution on Intel hardware, an lfence instruction is required to make sure
that selected checks are not bypassed. Speculative out-of-bound acc
On Wed, Feb 27, 2019 at 04:07:54AM -0700, Jan Beulich wrote:
> >>> On 08.02.19 at 11:17, wrote:
> > There is one code path where I haven't managed to properly extract
> > possible stubdomain in use:
> > pci_remove_device()
> > -> pci_cleanup_msi()
> >-> msi_free_irqs()
> > -> msi_free_ir
On Wed, Feb 27, 2019 at 04:41:37AM -0700, Jan Beulich wrote:
> >>> On 07.02.19 at 01:07, wrote:
> > --- a/xen/arch/x86/msi.c
> > +++ b/xen/arch/x86/msi.c
> > @@ -1474,6 +1474,30 @@ int pci_restore_msi_state(struct pci_dev *pdev)
> > return 0;
> > }
> >
> > +int msi_msix_set_enable(struct p
On Wed, Feb 27, 2019 at 12:09:05PM +0100, Roger Pau Monne wrote:
> Current npt and shadow code to get an entry will always return
> INVALID_MFN for foreign entries. Allow to return the entry mfn for
> foreign entries, like it's done for grant table entries.
>
> Signed-off-by: Roger Pau Monné
> Re
On Wed, Feb 27, 2019 at 12:09:04PM +0100, Roger Pau Monne wrote:
> So that the specific handling can be removed from
> atomic_write_ept_entry and be shared with npt and shadow code.
>
> This commit also removes the check that prevent non-ept PVH dom0 from
> mapping foreign pages.
>
> Signed-off-b
On Wed, Feb 27, 2019 at 12:30:31PM +0100, Roger Pau Monne wrote:
> This is in preparation for also changing p2m_entry_modify to return an
> error code.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Wei Liu
___
Xe
On Mon, Feb 25, 2019 at 08:23:58PM +, Woods, Brian wrote:
> Some AMD processors can use a mixture of mwait and halt for accessing
> various c-states. In preparation for adding support for AMD processors,
> update the mwait-idle driver to optionally use halt.
>
> Signed-off-by: Brian Woods
>
flight 133455 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133455/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 001b002f2baadcb1f78e1e2c74716f976ed6b6ed
baseline version:
freebsd 559f0dfc7a5
flight 133452 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133452/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-arm64-xs
On 2/25/19 17:46, Jan Beulich wrote:
On 25.02.19 at 14:34, wrote:
>> @@ -634,14 +649,24 @@ static unsigned int nr_grant_entries(struct
>> grant_table *gt)
>> case 1:
>> BUILD_BUG_ON(f2e(INITIAL_NR_GRANT_FRAMES, 1) <
>> GNTTAB_NR_RESERVED_ENTRIES);
>> +
>>
On Wed, Feb 27, 2019 at 03:25:22AM -0700, Jan Beulich wrote:
> >>> On 27.02.19 at 00:03, wrote:
> > After upgrading Debian to Buster, I started noticing console mangling
> > when using zsh. This is happenning because output sent by zsh to the
> > console may contain NUL character in the middle of
On Tue, Feb 26, 2019 at 11:03:51PM +, Julien Grall wrote:
> After upgrading Debian to Buster, I started noticing console mangling
> when using zsh. This is happenning because output sent by zsh to the
> console may contain NUL character in the middle of the buffer.
>
> Linux is sending the buf
flight 133419 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/133419/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win10-i386 broken
test-amd64-amd64-libvirt-qemu
On Mon, Feb 25, 2019 at 03:47:15PM +, Andrew Cooper wrote:
> These will be extended with further libx86 work.
>
> Fix the sorting of the CPUID_GUEST_NR_* constants, noticed while writing the
> unit tests.
>
> Signed-off-by: Andrew Cooper
Looks good to me. But I will let you and Jan figure o
On Mon, Feb 25, 2019 at 03:47:14PM +, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
> Signed-off-by: Sergey Dyasli
> Signed-off-by: Roger Pau Monné
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://list
On Mon, Feb 25, 2019 at 03:47:13PM +, Andrew Cooper wrote:
> +
> +switch ( data.idx )
> +{
> +/*
> + * Assign data.val to 'field', checking for truncation if the
> + * backing storage for 'field' is smaller than uint64_t
> + */
> +
On Mon, Feb 25, 2019 at 01:16:19PM +, Andrew Cooper wrote:
> The regression/ directory was identified as already broken in 2012 (c/s
> 953953cc5). The logic is intended to test *.py files in the Xen tree against
> different versions of python, but every identified version is now obsolete.
>
>
On 27/02/2019 10:02, Jan Beulich wrote:
>
> Reviewed-by: Jan Beulich
> albeit ...
>
>> @@ -323,6 +326,15 @@ static void setup_p6_watchdog(unsigned counter)
>> unsigned int evntsel;
>>
>> nmi_perfctr_msr = MSR_P6_PERFCTR(0);
>> +if ( !nmi_p6_event_width )
>> +nmi_p6_ev
On Wed, Feb 27, 2019 at 10:33:42AM +, Christian Lindig wrote:
> Don't close stdin in daemonize() but dup2 /dev/null instead. This avoids
> fd 0 being reused and potentially written to.
>
> Signed-off-by: Christian Lindig
Acked-by: Wei Liu
___
Xen
Ian Jackson writes ("[OSSTEST PATCH] jessie: Drop use of jessie-updates"):
> The Release file is out of date on our mirror, due to jessie's
> retirement into LTS.
This is causing everything to break. The self-test flight is `sort
of OK' although it does show what I think are hardware problems.
I
Current check for MSI EIO is missing a special case for PVH Dom0,
which doesn't have a hvm_irq_dpci struct but requires EIOs to be
forwarded to the physical lapic for passed-through devices.
Add a short-circuit to allow EOIs from PVH Dom0 to be propagated.
Signed-off-by: Roger Pau Monné
---
Cc:
The Release file is out of date on our mirror, due to jessie's
retirement into LTS.
CC: Juergen Gross
Signed-off-by: Ian Jackson
---
Osstest/Debian.pm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c5dc0e61..59c60d40 100644
---
>>> On 07.02.19 at 01:07, wrote:
> --- a/xen/arch/x86/msi.c
> +++ b/xen/arch/x86/msi.c
> @@ -1474,6 +1474,30 @@ int pci_restore_msi_state(struct pci_dev *pdev)
> return 0;
> }
>
> +int msi_msix_set_enable(struct pci_dev *pdev, int mode, int enable)
unsigned int mode, bool enable
I'm also
flight 83674 distros-debian-squeeze real [real]
http://osstest.xensource.com/osstest/logs/83674/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
This is in preparation for also changing p2m_entry_modify to return an
error code.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Tim Deegan
---
Changes since v6:
- Fix line wrapping in p2m_next_level.
Hi Andrew,
On 2/21/19 12:22 PM, Andrew Cooper wrote:
pci_release_devices() takes the global PCI lock. Once pci_release_devices()
has completed, it will be called redundantly each time paging_teardown() and
vcpu_destroy_pagetables() continue.
This is liable to be millions of times for a reasona
Hi,
On 2/26/19 11:02 AM, Roger Pau Monné wrote:
On Tue, Feb 26, 2019 at 10:26:21AM +, Julien Grall wrote:
On 26/02/2019 10:17, Roger Pau Monné wrote:
On Tue, Feb 26, 2019 at 10:03:38AM +, Julien Grall wrote:
Hi Roger,
On 26/02/2019 09:44, Roger Pau Monné wrote:
On Tue, Feb 26, 2019
So that it can be shared by both ept, npt and shadow code, instead of
duplicating it.
No change in functionality intended.
Signed-off-by: Roger Pau Monné
Reviewed-by: Paul Durrant
Reviewed-by: George Dunlap
Reviewed-by: Kevin Tian
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Cc:
Current callers pass the p2m to paging_write_p2m_entry, but the
implementation specific handlers of the write_p2m_entry hook instead
of a p2m get a domain struct due to the handling done in
paging_write_p2m_entry.
Change the code so that the implementations of write_p2m_entry take a
p2m instead of
Current npt and shadow code to get an entry will always return
INVALID_MFN for foreign entries. Allow to return the entry mfn for
foreign entries, like it's done for grant table entries.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Co
So that the specific handling can be removed from
atomic_write_ept_entry and be shared with npt and shadow code.
This commit also removes the check that prevent non-ept PVH dom0 from
mapping foreign pages.
Signed-off-by: Roger Pau Monné
Reviewed-by: Kevin Tian
---
Cc: George Dunlap
Cc: Jan Beu
The remaining set of patches contain changes to the p2m code that could
affect HVM guests. Note that without those changes a PVH dom0 running on
AMD hardware will be unable to create guests. Overall the patches are a
nice cleanup to the handling of p2m_ioreq_server and p2m_map_foreign
types IMO.
T
This is in preparation for also changing p2m_entry_modify to return an
error code.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Cc: George Dunlap
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: Tim Deegan
---
Changes since v5:
- Return -EOPNOTSUPP from _write_p2m_ent
>>> On 08.02.19 at 11:17, wrote:
> There is one code path where I haven't managed to properly extract
> possible stubdomain in use:
> pci_remove_device()
> -> pci_cleanup_msi()
>-> msi_free_irqs()
> -> msi_free_irq()
>-> destroy_irq()
>
> For now I've hardcoded hardware_domain t
Hi Amit,
On 2/21/19 6:15 PM, Amit Tomer wrote:
Hi,
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d9836779d1..08b9cd2c44 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1805,6 +1805,8 @@ static void __init dtb_load(struct kernel_info
On 27/02/2019 10:33, Christian Lindig wrote:
> Don't close stdin in daemonize() but dup2 /dev/null instead. This avoids
> fd 0 being reused and potentially written to.
>
> Signed-off-by: Christian Lindig
Possibly worth noting that this fixes a bug whereby /dev/xen/evtchn
reliably gets opened on f
(+ Juergen Gross as RM)
I forgot to CC Juergen for this.
On 2/26/19 11:03 PM, Julien Grall wrote:
After upgrading Debian to Buster, I started noticing console mangling
when using zsh. This is happenning because output sent by zsh to the
console may contain NUL character in the middle of the buf
Hi,
On 2/27/19 10:25 AM, Jan Beulich wrote:
On 27.02.19 at 00:03, wrote:
After upgrading Debian to Buster, I started noticing console mangling
when using zsh. This is happenning because output sent by zsh to the
console may contain NUL character in the middle of the buffer.
Linux is sending t
>>> On 27.02.19 at 00:07, wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -571,12 +571,14 @@ struct xen_domctl_bind_pt_irq {
> */
> #define DPCI_ADD_MAPPING 1
> #define DPCI_REMOVE_MAPPING 0
> +#define CACHEABILITY_DEVMEM 0 /* device memory,
Don't close stdin in daemonize() but dup2 /dev/null instead. This avoids
fd 0 being reused and potentially written to.
Signed-off-by: Christian Lindig
---
tools/ocaml/xenstored/stdext.ml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/ocaml/xenstored/stdext.ml b/too
>>> On 27.02.19 at 00:03, wrote:
> After upgrading Debian to Buster, I started noticing console mangling
> when using zsh. This is happenning because output sent by zsh to the
> console may contain NUL character in the middle of the buffer.
>
> Linux is sending the buffer as it is to Xen console
>>> On 27.02.19 at 10:23, wrote:
>
>> On 26 Feb 2019, at 18:27, Stefano Stabellini wrote:
>>
>> On Tue, 26 Feb 2019, Jan Beulich wrote:
So, we'll end up having lots of macros then which is obviously
not good. That said, I hope we can work out some common approach
not only to thi
>>> On 26.02.19 at 18:44, wrote:
> The logic currently tries to work out if a recent overflow (that indicates
> that NMI comes from the watchdog) happened by checking MSB of performance
> counter MSR that is initially sign extended from a negative value
> that we program it to. A possibly incorrec
>>> On 26.02.19 at 20:20, wrote:
> On Tue, 26 Feb 2019, Ian Jackson wrote:
>> Having written all that down (what a palaver), we can see that your
>> cast, above, is a breach of the rules. Instead you can just pass the
>> struct abstract_alt_instr*, and all is well. Then you don't need a
>> comme
>>> On 26.02.19 at 19:43, wrote:
> On Tue, 26 Feb 2019, Ian Jackson wrote:
>> Jan Beulich writes ("Re: [PATCH v10 2/6] xen: introduce DEFINE_SYMBOL"):
>> > On 26.02.19 at 17:46, wrote:
>> > > I am not aware of a standard C type which could be used instead of
>> > > this struct. But I think you c
>>> On 26.02.19 at 20:23, wrote:
> On Tue, 26 Feb 2019, Ian Jackson wrote:
>> Stefano Stabellini writes ("[PATCH v10 4/6] xen/x86: use DEFINE_SYMBOL as
>> required"):
>> > Use SYMBOLS_SUBTRACT and SYMBOLS_COMPARE in cases of comparisons and
>> > subtractions of:
>> ...
>> > Use explicit casts to
> On 26 Feb 2019, at 18:27, Stefano Stabellini wrote:
>
> On Tue, 26 Feb 2019, Jan Beulich wrote:
>>> So, we'll end up having lots of macros then which is obviously
>>> not good. That said, I hope we can work out some common approach
>>> not only to this issue, but how we deal with such in gene
>>> On 26.02.19 at 17:54, wrote:
> On 2/26/19 10:37 AM, Jan Beulich wrote:
> On 26.02.19 at 17:25, wrote:
>>> Correct me if I'm wrong, but the Xen's acpi-idle implementation is
>>> dependent on dom0 using a AML interpreter and then giving that data back
>>> to Xen. I've heard that this doesn
>>> On 26.02.19 at 22:22, wrote:
> On Tue, 26 Feb 2019, Jan Beulich wrote:
>> >>> On 25.02.19 at 21:50, wrote:
>> > @@ -210,7 +210,8 @@ static int __apply_alternatives_multi_stop(void
>> > *unused)
>> > region.begin = __alt_instructions;
>> > region.end = (struct alt_instr *)__
>>> On 26.02.19 at 22:14, wrote:
> On Tue, 26 Feb 2019, Jan Beulich wrote:
>> >>> On 25.02.19 at 21:50, wrote:
>> > --- a/xen/common/lib.c
>> > +++ b/xen/common/lib.c
>> > @@ -492,12 +492,15 @@ unsigned long long parse_size_and_unit(const char
>> > *s,
>> > const char **ps)
>> > }
>> >
>> >
>>> On 26.02.19 at 19:54, wrote:
> On Tue, 26 Feb 2019, Jan Beulich wrote:
>> >>> On 25.02.19 at 21:50, wrote:
>> > --- a/xen/include/xen/compiler.h
>> > +++ b/xen/include/xen/compiler.h
>> > @@ -99,6 +99,38 @@
>> > __asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
>> > (typeof(ptr)) (__ptr
>>> On 26.02.19 at 18:32, wrote:
> Jan Beulich writes ("Re: [PATCH v10 2/6] xen: introduce DEFINE_SYMBOL"):
>> On 26.02.19 at 17:46, wrote:
>> > I am not aware of a standard C type which could be used instead of
>> > this struct. But I think you can use the `packed' attribute to get
>> > the rig
95 matches
Mail list logo
